Ответ 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 (что очень помогает), или вам придется исправить ситуацию на стороне клиента (что часто бывает больно).