Статьи

Работа с iCloud: интеграция основных данных

Синхронизация данных приложения между устройствами является сложной и сложной задачей. К счастью, именно поэтому Apple создала iCloud. Из этой серии Tuts + Premium вы узнаете, как работает iCloud и как ваши приложения могут беспрепятственно обмениваться данными между несколькими устройствами.


  1. Работа с iCloud: Введение
  2. Работа с iCloud: хранилище ключей-значений
  3. Работа с iCloud: Хранение документов
  4. Работа с iCloud: интеграция основных данных

В предыдущих выпусках этой серии мы провели рефакторинг нашего примера приложения для переключения с хранилища ключей-значений iCloud на хранилище документов iCloud. Хранилище документов iCloud гораздо более гибкое, чем хранилище ключей и, следовательно, лучше подходит для приложений с большими объемами данных. Core Data — это постоянная структура, созданная для приложений, которые управляют большими объемами данных и сложными моделями данных. За прошедшие годы Core Data заработала свои полосы и известна как надежная и гибкая структура для сохранения данных. Эта серия не будет полной без обсуждения Core Data и его интеграции с iCloud.


Что касается базовых данных, существует два типа приложений: (1) приложения на основе документов и (2) приложения в стиле библиотеки. Приложения на основе документов, такие как приложение Apple Pages, управляют документами, поддерживаемыми хранилищем базовых данных. Приложения в стиле библиотеки, такие как встроенное музыкальное приложение iPhone, используют одно постоянное хранилище, которое используется в приложении.

В этом руководстве я расскажу как о типах приложений, так и обрисую общий обзор того, как каждый тип приложений может интегрироваться с iCloud. Базовые данные — это очень широкая тема и один из наиболее продвинутых аспектов разработки на Mac и iOS. Из этого туториала вы узнаете только о возможностях и возможностях интеграции, доступных в iCloud.


UIManagedDocument является конкретным подклассом UIDocument и предназначен для удовлетворения потребностей приложений Core Data на основе документов. Для приложений на основе документов UIManagedDocument предлагает лучшее из двух миров: (1) простота использования UIDocument и (2) встроенная поддержка Core Data. Стоит отметить, что UIManagedDocument можно использовать, даже если в интеграции с iCloud нет необходимости. Несмотря на то, что UIManagedDocument часто упоминается в контексте iCloud, полезно уделить UIManagedDocument времени и подчеркнуть преимущества самого класса UIManagedDocument .

Как и его суперкласс, UIDocument , UIManagedDocument делает управление документами простым и UIManagedDocument . Основное различие с UIDocument заключается в том, что UIManagedDocument предназначен специально для Core Data. И UIDocument и UIManagedDocument могут многое предложить из коробки. Помните из предыдущего урока, что UIDocument поддерживает автоматическое сохранение, а операции загрузки и сохранения обрабатываются в фоновой очереди, абстрагируясь от мельчайших деталей. Если вы решили использовать базовые данные в приложении на основе документов, рекомендуется использовать UIManagedDocument даже если iCloud отсутствует в списке функций вашего приложения.

До введения UIManagedDocument стек основных данных традиционно настраивался и настраивался в UIManagedDocument приложения. Это больше не требуется при использовании UIManagedDocument . Одним из UIManagedDocument класса UIManagedDocument является его встроенный стек Core Data. После инициализации экземпляра UIManagedDocument вам будет доступен полный стек основных данных. UIManagedDocument предоставляет контекст управляемого объекта, а также координатор постоянного хранилища и модель управляемого объекта. Настроить координатор постоянного хранилища так же просто, как задать словарь опциями, как вы делаете это при ручной инициализации координатора постоянного хранилища.

Как следует из его названия, UIManagedDocument является конкретным подклассом UIDocument , что означает, что его можно использовать как есть, без необходимости UIDocument подкласс UIDocument . За кулисами UIManagedDocument автоматически объединяет модели управляемых объектов, которые он находит в вашем комплекте приложений, и подготавливает стек основных данных для работы с вами. Если ваше приложение предъявляет более сложные требования, то вам нужно UIManagedDocument подкласс UIManagedDocument для удовлетворения этих требований.

Любой, кто знаком с Базовыми данными, знает, что эти изменения фиксируются в постоянном хранилище, отправляя контексту управляемого объекта сообщение save : . Это больше не требуется при использовании UIManagedDocument . Мало того, что это не является необходимым, его следует избегать. Причина в том, что UIManagedDocument управляет закрытым контекстом управляемого объекта. Этот частный контекст управляемого объекта управляет дочерним контекстом управляемого объекта, который является контекстом управляемого объекта, предоставляемым через открытый интерфейс UIManagedDocument . Посылая дочернему контексту управляемого объекта сообщение save:, изменения фиксируются только в контексте родительского управляемого объекта, а не в постоянном хранилище, управляемом контекстом родительского управляемого объекта.

Короче говоря, вы должны использовать знакомые методы UIDocument для сохранения изменений в постоянном хранилище, об остальном позаботятся за кулисами. Существует причина, по которой UIManagedDocument наследуется от UIDocument !


Библиотечные приложения, такие как встроенные приложения iPhone для музыки и фотографий, обычно управляют одним стеком Core Data с одним постоянным координатором хранилища и одним постоянным хранилищем.


Вы можете быть удивлены, как Core Data работает с iCloud. Это зависит от типа используемого вами хранилища, то есть (1) SQLite или (2) двоичного (атомарного) хранилища. В большинстве случаев рекомендуется выбирать SQLite. Однако, если вы имеете дело с небольшими объемами данных, то вариант с двоичным хранилищем также подходит. В свете iCloud основным недостатком бинарного хранилища является то, что каждое изменение приводит к замене всего хранилища. Это не только неэффективно, но и может привести к значительному снижению производительности при увеличении размера магазина. В оставшейся части этого обсуждения я остановлюсь на SQLite в качестве резервного хранилища.

С SQLite в качестве резервного хранилища главное преимущество заключается в том, что изменения распространяются постепенно, а не заменяют все хранилище каждым подтвержденным изменением. Чтобы понять, как Core Data и iCloud работают вместе, важно знать, что база данных SQLite не хранится в iCloud. Вместо этого каждое изменение регистрируется в так называемых журналах транзакций, и эти журналы используются для распространения изменений между устройствами. Журналы транзакций являются легкими и приводят к детальному, быстрому и эффективному процессу синхронизации. Журналы транзакций хранятся в каталоге в контейнере iCloud. Точное местоположение можно указать, задав ключ NSPersistentStoreUbiquitousContentURLKey в словаре параметров, передаваемом координатору постоянного хранения.

Другим важным аспектом синхронизации является обновление пользовательского интерфейса. При использовании Базовых данных это может быть достигнуто путем регистрации соответствующих контроллеров в качестве наблюдателя для уведомлений NSPersistentStoreDidImportUbiquitousContentChangesNotification , которые отправляются при распространении удаленного изменения. На основании изменений ваше приложение может обновить пользовательский интерфейс, чтобы отразить изменения, внесенные в его локальное постоянное хранилище.


Еще одним ключевым преимуществом Core Data является детальный контроль над вашими данными, и это особенно верно в отношении слияния данных, важной части работы с iCloud. Благодаря этой детализации, которая возможна только благодаря использованию журналов транзакций, большая часть слияния выполняется автоматически с помощью Core Data.


Общим в этой серии статей было то, как ваши приложения могут извлечь выгоду из iCloud и как интегрироваться с iCloud. Я хочу закончить эту серию, представив несколько предостережений, на которые вы можете обратить внимание при добавлении поддержки iCloud в приложение. Во второй и третьей частях этой серии я показал вам, как использовать NSFileManager URLForUbiquityContainerIdentifier: метод, чтобы получить ссылку на конкретный контейнер iCloud для хранения данных в iCloud. В наших примерах мы всегда предполагали, что iCloud был включен на устройствах, с которыми мы работали, но
это не всегда будет так. Поэтому важно иметь запасное решение для ситуаций, когда iCloud не включен. Ниже приведены два примера, чтобы лучше проиллюстрировать эти предостережения.

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

Второй пример фокусируется на постоянстве данных. Что происходит, когда пользователь включил iCloud на своем устройстве, но через несколько недель решает войти в систему с другой учетной записью iCloud? Данные, хранящиеся в контейнере iCloud, больше не доступны пользователю, так как используется другая учетная запись iCloud. Это мера безопасности, введенная Apple. Данные связаны с учетной записью iCloud, а не с устройством. Поэтому данные недоступны, когда используется другая учетная запись iCloud. Редко, когда один пользователь имеет несколько учетных записей iCloud, но важно знать об этой возможности и ее последствиях.


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