Подтвердить что ты не робот

Основные данные на клиенте (iOS) для кэширования данных с сервера Стратегия

Я написал много приложений iOS, которые общались с бэкэнд. Почти каждый раз я использовал HTTP-кеш для кэширования запросов и анализа данных ответа (JSON) в объекты objective-C. Для этого нового проекта мне интересно, будет ли подход Core Data иметь смысл.

Вот что я подумал:

Клиент iOS делает запрос на сервер и анализирует объекты с моделей JSON на CoreData.

Каждый раз, когда мне нужен новый объект, вместо того, чтобы напрямую загружать сервер, я разбираю CoreData, чтобы узнать, сделал ли я этот запрос уже. Если этот объект существует и не истек, я использую извлеченный объект.

Однако, если объект не существует или истек (для этого будет применяться некоторая логика кэширования), я бы взял объект с сервера и обновил CoreData соответственно.

Я думаю, что такая архитектура может помочь в следующем: 1. Избегайте ненужных запросов к серверу 2. Разрешить полную поддержку автономного просмотра (вы все равно можете создавать реляционные запросы с помощью DataCore RDBMS)

Теперь вот мой вопрос к SO Gods:

  • Я знаю, что этот вид требует вторичного кодирования бэкэнд-логики (Server + CoreData), но является ли это излишним?
  • Любое ограничение, которое у меня есть под оценкой?
  • Любая другая идея?
4b9b3361

ОТВЕТЫ

Ответ 1

Прежде всего, если вы зарегистрированный iOS Dev, вы должны иметь доступ к сессиям WWDC 2010. В одной из этих сессий рассказывается немного о том, о чем вы говорите: "Сессия 117, построение пользовательского опыта, основанного на сервере". Вы должны найти его в iTunes.

Интеллектуальная комбинация REST/JSON/Core Data работает как очарование и является огромной экономией времени, если вы планируете повторно использовать свой код, но потребуете знания об HTTP (и знаниях о Core Data, если вы хотите, чтобы ваши приложения чтобы хорошо и безопасно работать).

Итак, ключ должен понимать REST и Core Data.

  • Понимание REST означает Общие сведения о методах HTTP (GET, POST, PUT, DELETE,... HEAD?) и Response-Codes (2xx, 3xx, 4xx, 5xx) и заголовки (Last-Modified, If-Modified-Since, Etag,...)

  • Понимание основных данных означает знание того, как разрабатывать вашу модель, настраивать отношения, обрабатывать трудоемкие операции (удалять, вставлять, обновлять) и как делать вещи в фоновом режиме, чтобы ваш пользовательский интерфейс сохранял отзывчивость. И, конечно, как запросить локально на sqlite (например, для предварительной выборки id, чтобы вы могли обновлять объекты вместо создания новых, как только вы получите их эквиваленты на стороне сервера).

Если вы планируете внедрять API многократного использования для упомянутых вами задач, вы должны убедиться, что вы понимаете REST и Core Data, потому что там, где вы, вероятно, будете делать больше всего кода. (Существующий API - ASIHttpRequest для сетевого уровня (или любого другого) и любой хороший JSON lib (например SBJSON) для синтаксического анализа будет выполнять задание.

Ключом, который упрощает такой простой API, является предоставление сервером службы RESTful и ваших объектов, обладающих необходимыми атрибутами (dateCreated, dateLastModified и т.д.), чтобы вы могли создавать запросы (это легко сделать с помощью ASIHttpRequest, будь то GET, PUT, POST, DELETE) и добавьте соответствующие Http-заголовки, например для условного GET: If-Modified-Since.

Если вы уже чувствуете себя комфортно с Core Data и можете обрабатывать JSON и можете легко выполнять HTTP-запрос и обрабатывать ответы (опять же, ASIHttpRequest помогает здесь много, но есть и другие, или вы можете придерживаться более низкого уровня Apple NS- Классы и сделайте это сами), тогда вам нужно только установить правильные заголовки HTTP для ваших запросов и соответствующим образом обработать Http-Response-Codes (при условии, что ваш сервер REST-ful).

Если ваша основная цель состоит в том, чтобы избежать повторного обновления объекта Core-Data из эквивалента на стороне сервера, просто убедитесь, что у вас есть атрибут "последний-измененный" в вашей сущности и выполняйте условное GET на сервере (установка "Http-Header" с исправлением "с" последним измененным "сущностью. Сервер ответит кодом состояния 304 (не измененный), если этот ресурс не изменился (предполагается, что сервер REST -ful).Если он изменился, сервер установит" Last-Modified" Http-Header на дату последнего изменения, ответит Status-Code 200 и доставит ресурс в теле (например, в формате JSON).

Итак, как всегда, ответ на ваш вопрос, как всегда, вероятно, "это зависит". В основном это зависит от того, что вы хотели бы добавить в свой многоразовый слой do-it-all core-data/rest.

Чтобы рассказать вам номера: мне понадобилось 6 месяцев (в свободное время, в темпе 3-10 часов в неделю), чтобы иметь мое место, где я хотел, и, честно говоря, я все еще рефакторинг, переименование, позволяя обрабатывать специальные прецеденты (отмену запросов, откаты и т.д.) и предоставлять мелкозернистые обратные вызовы (достижимость, сетевой уровень, сериализация, сохранение основных данных...). Но он довольно чистый, продуманный и оптимизированный и, надеюсь, соответствует моим потребностям работодателя (онлайн-рынок для объявлений с несколькими приложениями для iOS). Это время включало в себя обучение, тестирование, оптимизацию, отладку и постоянное изменение моего API (сначала добавляя функциональность, затем улучшая ее, затем радикально упрощая ее и отлаживая ее снова).

Если время выхода на рынок является вашим приоритетом, вам будет проще с простым и прагматичным подходом: Nevermind reusability, просто сохраните знания в памяти и рефакторинг в следующем проекте, повторное использование и исправление кода здесь и там. В конце концов, сумма всех переживаний может возникнуть в ясном видении того, КАК ваш API работает и ЧТО он предоставляет. Если вас еще нет, держите руки в попытке сделать это частью бюджета проекта и просто попробуйте повторно использовать как можно больше стабильного 3'rd-Party API.

Извините за длинный ответ, я чувствовал, что вы вступаете во что-то вроде создания универсального API или даже фреймворка. Эти вещи требуют времени, знаний, ведения домашнего хозяйства и долгосрочных обязательств, и большую часть времени это пустая трата времени, потому что вы никогда не заканчиваете их.

Если вы просто хотите обрабатывать конкретные сценарии кеширования, чтобы разрешить автономное использование вашего приложения и минимизировать сетевой трафик, вы можете, конечно, просто реализовать эти функции. Просто установите if-modified-since с заголовками в вашем запросе, проверьте последние измененные заголовки или etags и сохраните эту информацию в ваших суставах persistet, чтобы вы могли повторно отправить эту информацию в последующих запросах. Конечно, я также рекомендовал бы кэшировать (настойчиво) ресурсы, такие как изображения, локально, используя те же заголовки HTTP.

Если у вас есть роскошь модификации (с помощью REST-ful) серверной службы, тогда вы в порядке, если вы хорошо ее реализуете (по опыту вы можете сэкономить до 3/4 сети /parsing code iOS-side, если служба ведет себя хорошо (возвращает соответствующие коды состояния HTTP, избегает проверок на nil, числовые преобразования из строк, дат, предоставляют идентификатор lookup вместо неявных строк и т.д.).

Если у вас нет такой роскоши, то либо эта служба, по крайней мере, REST-ful (что очень помогает), или вам придется исправить ситуацию на стороне клиента (что часто бывает больно).

Ответ 2

Есть решение, которое я не мог попробовать, потому что я слишком далеко в своем проекте, чтобы реорганизовать аспект кеширования моего приложения, но он должен быть полезен для людей, которые все еще ищут ответ:

http://restkit.org/

Он делает именно то, что я сделал, но это гораздо более абстрактно, чем то, что я сделал. Очень проницательный материал. Надеюсь, это поможет кому-то!

Ответ 3

Я думаю, что это правильный подход. Я делал это несколько раз. Трудная часть заключается в том, когда вам нужно иметь дело с синхронизацией: если клиент и сервер могут одновременно изменять ситуацию. Для этого вам почти всегда нужна логика слияния приложений.