Храня и Используя Документы в iCloud

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

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

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

Хранение iCloud APIs

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

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

Работа с Документами в iCloud

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

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

Когда изменения собираются произойти, в дополнение к координированию операций координаторы файла также работают с предъявителями файла для уведомления приложений. Предъявитель файла является любым объектом, соответствующим NSFilePresenter протокол и берет на себя ответственность за управление определенным файлом (или каталог файлов) в приложении. Задание предъявителя файла должно защитить целостность своих собственных структур данных. Это делает это путем прислушивания к сообщениям от других координаторов файла и использования тех сообщений для обновления его внутренних структур данных. В большинстве случаев предъявителю файла ничего не, вероятно, придется сделать. Однако, если координатор файла объявляет, что это собирается переместить файл в новый URL, предъявитель файла должен был бы заменить его старый URL новым, предоставленным для него координатором файла. NSDocument класс является примером предъявителя файла, отслеживающего изменения в его базовом файле или пакете файла.

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

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

• После создания предъявителя файла зарегистрируйте его путем вызова addFilePresenter: метод класса NSFileCoordinator. Регистрация важна. Система может уведомить только зарегистрированные объекты предъявителя.

• Прежде, чем удалить предъявителя файла, не зарегистрируйте его путем вызова removeFilePresenter: метод NSFileCoordinator.

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

1. Создайте экземпляр NSFileCoordinator класс и инициализирует его с объектом предъявителя файла, собирающимся выполнить работу файла.

2. Используйте методы NSFileCoordinator возразите, чтобы считать или записать файл:

   • Для чтения всех или части единственного файла используйте coordinateReadingItemAtURL:options:error:byAccessor: метод

   • Чтобы записать в файл или удалить его, вызовите coordinateWritingItemAtURL:options:error:byAccessor: метод.

   • Для выполнения последовательности операций чтения или операций записи используйте coordinateReadingItemAtURL:options:writingItemAtURL:options:error:byAccessor: метод.

   • Записать в многократные файлы или переместить файл в новое расположение, использование coordinateWritingItemAtURL:options:writingItemAtURL:options:error:byAccessor: метод.

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

3. Когда Вы сделаны с операциями, выпускаете координатора файла объект.

Для получения дополнительной информации об использовании координаторов файла и предъявителей файла, посмотрите Роль Координаторов Файла и Предъявителей.

Перемещение Документа Хранению iCloud

Перемещать документ хранению iCloud:

1. Создайте и сохраните файл в надлежащем локальном каталоге.

2. Если Вы не используете NSDocument класс для управления файлом создайте предъявителя файла, чтобы быть ответственными за него. Для получения информации о предъявителях файла посмотрите Работу с Документами в iCloud.

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

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

4. Вызовите setUbiquitous:itemAtURL:destinationURL:error: метод NSFileManager перемещать файл к указанному месту назначения в iCloud.

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

После перемещения документа iCloud не необходимо сохранить URL к расположению документа постоянно. Если Вы управляете документом с помощью a NSDocument объект, тот объект автоматически обновляет свои локальные структуры данных с новым URL документа. Однако это не сохраняет тот URL НА ДИСК, и ни один не должен Ваши пользовательские предъявители файла. Вместо этого потому что документы могут переместиться, в то время как в хранении iCloud пользователя, необходимо использовать NSMetadataQuery возразите для поиска документов. Поиск гарантий, что приложение имеет корректный URL для доступа к документу. Для получения информации о том, как искать документы в iCloud, посмотрите Хранение iCloud APIs.

Для получения дополнительной информации о методах NSFileManager класс, посмотрите Ссылку класса NSFileManager.

Поиск Документов в iCloud

Для определения местоположения документов в хранении iCloud приложение должно искать использование NSMetadataQuery объект. Поиск является гарантируемым способом определить местоположение документов в хранении iCloud пользователя. Необходимо всегда использовать объекты запроса вместо того, чтобы постоянно сохранить URLs, потому что пользователь может удалить файлы из хранения iCloud, когда не работает приложение. Используя запрос для поиска единственный способ гарантировать точный список документов.

NSMetadataQuery класс поддерживает следующие поисковые объемы для Ваших документов:

• Используйте NSMetadataQueryUbiquitousDocumentsScope постоянный для поиска документов в iCloud, находящихся где-нибудь внутри a Documents каталог. (Для любого данного контейнерного каталога, помещенных документов, к которым пользователю разрешают получить доступ внутри a Documents подкаталог.)

• Используйте NSMetadataQueryUbiquitousDataScope постоянный для поиска документов в iCloud, находящихся где угодно кроме в a Documents каталог. (Для любого данного контейнерного каталога используйте этот объем для хранения связанных с пользователем файлов данных, которые должно совместно использовать приложение, но которые не являются файлами, которыми Вы хотите, чтобы пользователь управлял непосредственно.)

Для использования объекта запроса метаданных искать документы создайте новое NSMetadataQuery возразите и сделайте следующее:

1. Установите поисковый объем запроса к надлежащему значению (или значениям). Важно отметить, что не возможно объединить поиски локальной файловой системы с поисками iCloud. Поиск должен быть запущен отдельно.

2. Добавьте предикат для сужения результатов поиска. Например, для поиска всех файлов укажите предикат с форматом NSMetadataItemFSNameKey == *.

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

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

4. Вызовите startQuery метод объекта запроса.

5. Выполните текущий цикл выполнения так, чтобы объект запроса мог генерировать результаты.

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

6. Обработайте результаты в своих методах обработчиков уведомления.

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

7. Когда Вы будете готовы остановить поиск, вызовите stopQuery метод объекта запроса.

Для получения дополнительной информации о том, как создать и выполнить запросы метаданных, видит Руководство по программированию Поиска Метаданных Файла.

Работа с обертками файла

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

Чтобы гарантировать, что Ваша обертка файла обрабатывается как единственный пакет, Ваше приложение должно экспортировать должным образом отформатированный UTI для Вашего пакета. В частности необходимо указать, что UTI соответствует com.apple.package, и необходимо установить расширение как дополнительное свойство с помощью UTTypeTagSpecification и public.filename-extension ключи, как показано на рисунке 4-2.

Для получения дальнейшей информации об установке и экспорте документа UTIs, посмотрите Основанный на документе Предварительный рейс Приложения. Для получения дополнительной информации об обертках файла посмотрите Используя FileWrappers как Контейнеры Файла.

Обработка конфликтов версии файла

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

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

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

Разрешить конфликты:

1. Получите текущую версию файла с помощью currentVersionOfItemAtURL: метод класса NSFileVersion.

2. Получите массив версий конфликта с помощью unresolvedConflictVersionsOfItemAtURL: метод класса NSFileVersion.

3. Для каждого объекта версии конфликта выполните любые действия, необходимы для разрешения конфликта. Опции включают:

   • Слияние версий конфликта с текущим файлом автоматически, если это практично, чтобы сделать так.

   • Игнорирование версий конфликта, при выполнении так не приводит ни к какой потере данных.

   • Запрос пользователя выбрать, который версия (текущий или конфликт) для хранения. Это должно всегда быть Вашей последней опцией.

4. Обновите текущий файл по мере необходимости.

   • Если текущая версия файла остается победителем, Вы не должны обновлять текущий файл.

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

   • Если пользователь принимает решение сохранить версию конфликта под другим именем, создайте новый файл с содержанием версии конфликта.

5. Установите resolved свойство версии конфликта возражает против YES.

   Установка этого свойства к YES заставляет объекты версии конфликта (и их соответствующие файлы) быть удаленными из хранения iCloud пользователя.

Для получения дополнительной информации о версиях файла и как Вы используете их, посмотрите Ссылку класса NSFileVersion.

Используя Хранение iCloud Ответственно

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

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

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

• Храня документы в iCloud, разместите их в a Documents каталог, когда это возможно. Документы внутри a Documents каталог может быть удален индивидуально пользователем для высвобождения пространства. Однако все вне того каталога обрабатывается как данные и должно быть удалено одновременно.

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