Храните Только Существенные Данные в iCloud

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

Функция конфигурации модели управляемого объекта базовых Данных упрощает работу с данными, это разделяется между двумя местами хранения. С конфигурациями модели можно установить, где сохранены определенные объекты — или даже отдельные атрибуты —. Используйте конфигурацию модели управляемого объекта для разделения атрибутов и объектов, которые должны только быть сохраненными локально от тех, которые должны быть сохранены к iCloud. Посмотрите Модели Управляемого объекта в Базовом Руководстве по программированию Данных для дальнейшей дискуссии о конфигурациях модели. Кроме того, Базовые Данные эффективно сохраняют внешние данные к iCloud. Используйте внешнюю установку данных на атрибутах, которые, вероятно, будут содержать больше чем 4 КБ данных.

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

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

Разработайте свой базовый стек данных, чтобы быть эффективными

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

Например, Вы традиционно используете политики слияния, когда Вы хотите объединить изменения, внесенные в отдельных контекстах управляемого объекта и персистентных координаторах хранилища. С iCloud, напротив, Вы используете политики слияния объединить изменения, внесенные в запись на многократных коллегах. Для дальнейшего обсуждения политик слияния посмотрите Управление изменениями в Базовом Руководстве по программированию Данных.

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

Знайте, когда сохранить Ваш контекст

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

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

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

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