Основные принципы iCloud

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

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

Эта глава запустила Вас с фундаментальных элементов iCloud, который должны знать все разработчики.

Во-первых, настройте свои устройства разработки

Чтобы начать разрабатывать приложение iCloud, у Вас должны быть надлежащий профиль настройки устройства и приложение ID. Если Вы уже не имеете в распоряжении их, узнаете об устанавливании профиля настройки и приложения ID в Добавляющих Возможностях в Руководстве по Распределению приложений.

Доходы Передачи данных iCloud Автоматически и Надежно

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

  1. Сконфигурируйте доступ к контейнерам iCloud своего приложения. Конфигурация включает запрос прав и программно инициализацию тех контейнеров перед использованием их.

  2. Разработайте свое приложение для надлежащего ответа на изменения в доступности iCloud (такой, как будто пользователь подписывается из iCloud), и к изменениям в расположениях файлов (потому что экземпляры приложения на других устройствах могут переименовать, переместите, копируйте или удалите файлы).

  3. Считайте и запишите использование APIs технологии, которую Вы используете.

  4. Операционная система координирует передачу данных к и от iCloud по мере необходимости.

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

Контейнер iCloud, Хранение iCloud и Права

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

Рисунок 1-1  основной iCloud Вашего приложения (повсеместность) контейнер в контексте

Для включения доступа к любым контейнерам iCloud Вы запрашиваете надлежащие права.

Запросите Доступ к iCloud Используя Возможности XCode

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

При включении Документов iCloud или возможности CloudKit XCode конфигурирует приложение для доступа к контейнеру iCloud, имя которого основывается на пакете приложения ID. Для большинства приложений должен только быть нужным доступ к контейнеру по умолчанию. Если Ваши приложения совместно используют данные друг среди друга, включают опцию «Specify custom container identifiers» и добавляют один или несколько контейнерных IDs, который Вы используете для совместного использования данных. Когда приложение имеет доступ к многократному контейнерному IDs, первый ID в списке доступа является особенным, потому что это - основной контейнер iCloud приложения. В OS X это - также контейнер, содержание которого выведено на экран в NSDocument откройте и сохраните диалоговые окна.

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

Конфигурирование Общего Контейнера iCloud для Многократных Приложений

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

bullet
Сконфигурировать общий контейнер iCloud
  1. Определяйте одно из своих поддерживающих iCloud приложений как первичное приложение. Контейнер iCloud того приложения становится общим контейнером.

    Например, в случае бесплатного и платного приложения, Вы могли бы определять платное приложение как первичное приложение.

  2. Включите возможность iCloud каждого приложения.

  3. Сконфигурируйте первичное приложение с только контейнерным идентификатором по умолчанию.

  4. Для каждого вторичного приложения включите опцию «Specify custom container identifiers» и добавьте контейнерный идентификатор первичного приложения к списку контейнеров.

При чтении и записи файлов и в основных и во вторичных приложениях, создайте URLs и ищите файлы только в общем контейнере хранения. Для получения URL для общего контейнера хранения передайте контейнерный идентификатор первичного приложения к URLForUbiquityContainerIdentifier: метод NSFileManager. Не передавать nil к тому методу, потому что выполнение так возвращает контейнер приложения по умолчанию, отличающийся для каждого приложения. Явно указание контейнерного идентификатора всегда приводит к корректному контейнерному каталогу.

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

Конфигурирование общего хранения значения ключа для многократных приложений

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

bullet
Сконфигурировать общее хранение значения ключа для многократных приложений
  1. Определяйте одно из своих поддерживающих iCloud приложений как первичное приложение.

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

  2. Включите возможность iCloud каждого приложения.

  3. Включите возможность хранения значения ключа для обоих приложений.

    XCode автоматически добавляет права на каждое приложение и присваивает контейнер iCloud на основе пакета приложения ID.

  4. Для всех кроме первичного приложения измените контейнер iCloud ID вручную в приложении .entitlements файл.

    Установите значение com.apple.developer.ubiquity-kvstore-identifier ключ к ID Вашего первичного приложения.

Контейнеры iCloud Имеют Минимальную Структуру

Структура недавно создаваемого контейнера iCloud минимальна — наличие только a Documents подкаталог. Для хранения документов можно расположить файлы в контейнере любым способом, которым Вы выбираете. Это позволяет Вам определять структуру по мере необходимости для Вашего приложения, такой как путем добавления пользовательских каталогов и пользовательских файлов на верхнем уровне контейнера, как обозначено на рисунке 1-2. Приложения CloudKit не взаимодействуют явно с файловой системой и не должны касаться структуры каталога контейнера iCloud.

Рисунок 1-2  структура каталога контейнера iCloud

Можно записать файлы и создать подкаталоги в Documents подкаталог. Можно создать файлы или дополнительные подкаталоги в любом каталоге, который Вы создаете. Выполните все такие операции с помощью NSFileManager объект с помощью координации файла. Посмотрите Роль Координаторов Файла и Предъявителей в Руководстве по программированию Файловой системы.

Documents подкаталог является общедоступной поверхностью контейнера iCloud. Когда пользователь исследует хранение iCloud на Ваше приложение (использующий Настройки в iOS или Установки системы в OS X), файлы или пакеты файла в Documents подкаталог перечислен и может быть удален индивидуально. Файлы за пределами Documents подкаталог обрабатывается как частный к Вашему приложению. Если пользователи хотят удалить что-нибудь за пределами Documents подкаталоги Ваших контейнеров iCloud, они должны удалить все за пределами тех подкаталогов.

Для наблюдения представления пользователем хранения iCloud сделайте следующее, первое обеспечение, чтобы у Вас было по крайней мере одно поддерживающее iCloud установленное приложение:

ICloud Storage Is Limited Пользователя

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

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

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

Система Управляет Локальным Хранением iCloud

жизни данных iCloud на серверах iCloud Apple, но система поддерживает локальный кэш данных по каждому из устройств пользователя, как показано на рисунке 1-3. Локальное кэширование данных iCloud позволяет пользователям продолжать работать, даже когда сеть недоступна, такой как тогда, когда они включают авиарежим.

Рисунок 1-3  файлы iCloud кэшируется на локальных устройствах и сохранен в iCloud

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

Ваше приложение может помочь управлять локальным хранением в некоторых случаях

Основанные на документе приложения обычно не должны управлять локальной доступностью файлов iCloud и должны позволить системе обработать замещение файлов. Существует два исключения:

  • Если пользовательский файл не в настоящее время необходим и вряд ли скоро быть необходимым, можно помочь системе путем явного выселения того файла из контейнера iCloud путем вызова NSFileManager метод evictUbiquitousItemAtURL:error:.

  • С другой стороны, если Вы явно хотите гарантировать, что файл доступен локально, можно инициировать загрузку к контейнеру iCloud путем вызова NSFileManager метод startDownloadingUbiquitousItemAtURL:error:. Для получения дополнительной информации об этом процессе, посмотрите Обязанности за Приложение по Использованию Документов iCloud.

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

Подготовьте Свое Приложение для Использования iCloud

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

Рано в Вашем приложении запускают процесс — в application:didFinishLaunchingWithOptions: метод (iOS) или applicationDidFinishLaunching: метод (OS X) — проверяет на доступность iCloud путем получения значения ubiquityIdentityToken свойство NSFileManager, как показано в Перечислении 1-1.

Перечисление 1-1  Получая маркер iCloud

NSFileManager* fileManager = [NSFileManager defaultManager];
id currentiCloudToken = fileManager.ubiquityIdentityToken;

Получите доступ к этому свойству от основного потока своего приложения. Значение свойства является уникальным маркером, представляющим в настоящее время активную учетную запись iCloud. Если текущий счет отличается от ранее используемого, как объяснено в Изменениях Дескриптора в Доступности iCloud, можно сравнить маркеры, чтобы обнаружить. Для включения сравнений заархивируйте недавно полученный маркер в пользовательской базе данных значений по умолчанию, с помощью кода как показанный в Перечислении 1-2. Этот код использует в своих интересах факт что ubiquityIdentityToken свойство соответствует NSCoding протокол.

Перечисление 1-2  Архивируя доступность iCloud в пользовательской базе данных значений по умолчанию

 if (currentiCloudToken) {
    NSData *newTokenData =
            [NSKeyedArchiver archivedDataWithRootObject: currentiCloudToken];
    [[NSUserDefaults standardUserDefaults]
            setObject: newTokenData
               forKey: @"com.apple.MyAppName.UbiquityIdentityToken"];
} else {
    [[NSUserDefaults standardUserDefaults]
            removeObjectForKey: @"com.apple.MyAppName.UbiquityIdentityToken"];
}

Если пользователь включает авиарежим на устройстве, сам iCloud становится недоступным, но текущая учетная запись iCloud остается, регистрировался. Даже в авиарежиме, ubiquityIdentityToken свойство содержит маркер для текущей учетной записи iCloud.

Если пользователь подписывается из iCloud, такой как путем выключения Документов и Данных в Настройках, значении ubiquityIdentityToken свойство изменяется на nil. Обнаружить, когда пользователь регистрируется или из iCloud, регистр как наблюдатель NSUbiquityIdentityDidChangeNotification уведомление, с помощью кода, такого как показанный в Перечислении 1-3. Выполните этот код во время запуска или в любой точке перед активным использованием iCloud.

Перечисление 1-3  , Регистрирующееся для доступности iCloud, изменяет уведомления

[[NSNotificationCenter defaultCenter]
    addObserver: self
       selector: @selector (iCloudAccountAvailabilityChanged:)
           name: NSUbiquityIdentityDidChangeNotification
         object: nil];

После получения и архивации маркера iCloud и регистрации для уведомления iCloud, Ваше приложение готово пригласить пользователя использовать iCloud. Если это - первый запуск пользователя Вашего приложения с доступной учетной записью iCloud, выведите на экран предупреждение при помощи кода как показанный в Перечислении 1-4. Сохраните выбор пользователя к пользовательской базе данных значений по умолчанию и использование, оценивающие для инициализации firstLaunchWithiCloudAvailable переменная во время последующих запусков. Этот код в перечислении упрощен для фокусирований на виде языка, который Вы вывели бы на экран. В приложении Вы намереваетесь обеспечить для клиентов, Вы интернационализировали бы этот код при помощи NSLocalizedString (или подобный) макрос, вместо того, чтобы использовать строки непосредственно.

Перечисление 1-4  , Приглашающее пользователя использовать iCloud

if (currentiCloudToken && firstLaunchWithiCloudAvailable) {
    UIAlertView *alert = [[UIAlertView alloc]
                            initWithTitle: @"Choose Storage Option"
                                  message: @"Should documents be stored in iCloud and
                                                available on all your devices?"
                                 delegate: self
                        cancelButtonTitle: @"Local Only"
                        otherButtonTitles: @"Use iCloud", nil];
    [alert show];
}

Несмотря на то, что ubiquityIdentityToken свойство сообщает, регистрируется ли пользователь в учетную запись iCloud, оно не подготавливает iCloud к использованию Вашим приложением. В iOS приложения, использующие хранение документов, должны вызвать URLForUbiquityContainerIdentifier: метод NSFileManager метод для каждого поддерживал контейнер iCloud. Всегда вызывайте URLForUbiquityContainerIdentifier: метод от фонового потока — не от основного потока Вашего приложения. Этот метод зависит от локальных и удаленных служб и, поэтому, не всегда сразу возвращается. Перечисление 1-5 показывает пример того, как инициализировать контейнер Вашего приложения по умолчанию на фоновом потоке.

Перечисление 1-5  Получая URL к Вашему контейнеру iCloud

dispatch_async (dispatch_get_global_queue (DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
    myContainer = [[NSFileManager defaultManager]
            URLForUbiquityContainerIdentifier: nil];
    if (myContainer != nil) {
        // Your app can write to the iCloud container
 
    dispatch_async (dispatch_get_main_queue (), ^(void) {
        // On the main thread, update UI and state as appropriate
    });
    }
});

Этот пример предполагает, что Вы ранее определили myContainer как переменная экземпляра типа NSURL до выполнения этого кода.

Изменения дескриптора в Доступности iCloud

Существуют времена, когда iCloud может не быть доступен Вашему приложению, такой как тогда, когда пользователь отключает опцию Documents & Data или знаки из iCloud. Если текущая учетная запись iCloud становится недоступной, в то время как Ваше приложение работает или в фоновом режиме, Ваше приложение должно удалить ссылки на специфичные для пользователя файлы iCloud и данные и сбросить или обновить элементы пользовательского интерфейса, показывающие что данные, как изображено на рисунке 1-4.

  Временная шкала рисунка 1-4 для реакции на изменения в доступности iCloud

Обработать изменения в доступности iCloud, регистр для получения NSUbiquityIdentityDidChangeNotification уведомление. Метод обработчиков, который Вы регистрируете, должен сделать следующее:

  1. Получите новое значение от ubiquityIdentityToken свойство.

  2. Сравните новое значение с предыдущим значением, чтобы узнать, подписался ли пользователь из учетной записи или регистрировался в различную учетную запись.

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

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

Выберите Надлежащее Хранение iCloud API

Apple обеспечивает следующее хранение iCloud APIs, каждый с различной целью:

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

Если Ваше использование приложения Базовые Данные, или для документов или для приложения стиля обувной коробки как iPhoto, использует хранение документов iCloud. Чтобы изучить, как принять iCloud в Вашем Базовом приложении Данных, посмотрите Разработку для Базовых Данных в iCloud.

Если Ваше приложение должно сохранить пароли, не используйте хранение iCloud APIs для этого. Корректным API для того, чтобы сохранить и управлять паролями является Keychain Services, как описано в Ссылке Keychain Services.

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

Табличные 1-1  Различия между документом и хранением значения ключа

Элемент

хранение документов iCloud

Хранение значения ключа

CloudKit

Цель

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

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

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

Дающие право ключи

com.apple.developer.icloud-services, com.apple.developer.icloud-container-identifiers

com.apple.developer.ubiquity-kvstore-identifier

com.apple.developer.icloud-services, com.apple.developer.icloud-container-identifiers

Формат данных

Файлы и пакеты файла

Типы данных списка свойств только (числа, строки, даты, и т.д.)

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

Способность

Ограниченный только пространством, доступным в учетной записи iCloud пользователя.

Ограниченный в общей сложности 1 МБ на приложение, с пределом на ключ 1 МБ.

Ограниченный только пространством, доступным в учетной записи iCloud пользователя (частная база данных) и выделенная квота хранилища приложения (общедоступная база данных).

Обнаружение доступности

Вызовите URLForUbiquityContainerIdentifier: метод для одного из Ваших контейнеров повсеместности. Если возвращается метод nil, хранение документов не доступно.

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

Общедоступная база данных всегда доступна. Частная база данных доступна только когда значение в ubiquityIdentityToken свойство не nil.

Определение местоположения данных

Используйте NSMetadataQuery объект получить живо обновленную информацию о доступных файлах iCloud.

Используйте совместно используемое NSUbiquitousKeyValueStore объект получить значения.

Используйте a CKQuery объект с a CKQueryOperation для поиска записей, соответствующих предикат, Вы указываете. Используйте другие объекты операции для выборки записей ID.

Управление данными

Используйте NSFileManager класс для работы непосредственно с файлами и каталогами.

Используйте значение по умолчанию NSUbiquitousKeyValueStore объект управлять значениями.

Используйте классы платформы CloudKit для управления данными.

Разрешение конфликтов

Документы, как предъявители файла, автоматически конфликты дескриптора; в OS X, NSDocument версии подарков пользователю при необходимости. Для файлов Вы вручную разрешаете конфликты с помощью предъявителей файла.

Новый набор значений для ключа побеждает и продвинут ко всем устройствам, присоединенным к той же учетной записи iCloud. Метки времени, предоставленные каждым устройством, используются для сравнения времени изменения.

При сохранении записей присвойте надлежащее значение savePolicy свойство a CKModifyRecordsOperation объект указать, как Вы хотите обработать конфликты.

Передача данных

В iOS выполните скоординированное чтение для получения локальной копии файла iCloud; данные тогда автоматически продвинуты к iCloud в ответ на изменения локальной файловой системы.

В OS X файлы iCloud всегда автоматически продвигаются к iCloud в ответ на изменения локальной файловой системы.

Автоматический, в ответ на изменения локальной файловой системы.

Используйте объекты операции (или удобные методы CKOperation и CKDatabase классы) для инициирования передачи данных.

Передача метаданных

Автоматический, в ответ на изменения локальной файловой системы.

Не применимый (хранение значения ключа не использует метаданные).

Не применимый

Пользовательский интерфейс

Ни одно предоставленное iOS. Ваше приложение ответственно за отображение информации о данных iCloud при желании; сделайте так беспрепятственно и с минимальными изменениями в предварительном iCloud Вашего приложения UI.

В OS X, NSDocument обеспечивает iCloud UI.

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

Ни одно предоставленное iOS. Ваше приложение ответственно за обеспечение интерфейса, должен был вывести на экран данные, полученные из записей.