Используя координацию файла для доступа к файлам и каталогам

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

Приложения то использование объекты документа (UIDocument в iOS и NSDocument в OS X), получают координацию файла бесплатно. Объекты документа реализуют предъявителя (NSFilePresenter) протокол и использование его методы для управления базовым файлом или пакетом файла. При чтении или записи содержания файла, объекты документа также используют координаторов файла (экземпляры NSFileCoordinator класс) автоматически. Если Вы не используете объекты документа для доступа к файлам, необходимо обработать координацию файла сами. Для получения дополнительной информации, о как к координации файла поддержки в Ваших собственных объектах, посмотрите Роль Координаторов Файла и Предъявителей в Руководстве по программированию Файловой системы.

Передача Данных к и от iCloud

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

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

Когда новый файл появляется в iCloud, тот файл должен быть загружен на другие устройства пользователя, как показано на рисунке 3-4. Для каждого устройства iCloud сначала отправляет метаданные того документа так, чтобы устройство знало о существовании файла. После этого синхронизация для получения данных файла зависит от типа устройства. В iOS приложения должны попросить, чтобы система (или явно или неявно) загрузила файл. Вы неявно загружаете файл путем попытки получить доступ к тому файлу, или можно явно загрузить файл путем вызова startDownloadingUbiquitousItemAtURL:error: метод NSFileManager. Mac загружает файлы автоматически, как только он обнаруживает их на сервере. Поэтому Mac иногда упоминается как “жадная коллега”. Если Ваше приложение Mac видит метаданные для нового документа, но сам документ еще не локален, это, вероятно, уже загружается системой от имени Вашего приложения.

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

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

Проект для сетевого коэффициента передачи

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

Зарегистрируйте свой формат файла документа и его связанное расширение файла, в Вашем приложении Info.plist файл списка свойств в XCode. В частности используйте ключ CFBundleDocumentTypes для указания форматов файлов, которые приложение распознает и в состоянии открыться. Укажите и расширение файла и универсальный идентификатор типа (UTI), соответствующий содержанию файла. Система использует эту информацию для соединения пакетов файла к приложению, и, в OS X, к пакетам дисплейного файла пользователю, как будто они - нормальные файлы.

Проект для персистентного состояния документа

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

Существует два места, можно сохранить специфичное для документа состояние:

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

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

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

Например, предположите, что пользователь редактировал документ длинного текста о ее iPad, работая на странице 1. Немного позже она открывает документ о своем iPhone и прокручивает к последней странице. Это плохо себя ведомое приложение в качестве примера настойчиво сохраняет позицию прокрутки конца документа — даже при том, что пользователь не внес никакие другие изменения. Когда пользователь позже открывает документ о ее iPad, чтобы продолжить редактировать, существует бесполезный конфликт вследствие данных позиции прокрутки. Система отметила документ как в конфликте (UIDocumentStateInConflict), и более новая версия (автоматически назначенный победителем конфликта) является той, прокрученной до последней страницы. Чтобы быть приложением iCloud хорошего поведения, этот текстовый редактор должен был проигнорировать изменение в позиции прокрутки на iPhone, потому что пользователь не редактировал содержание.

Продумайте различные сценарии использования для своего приложения и разработайте соответственно для улучшения пользовательского опыта. Заботьтесь с состоянием как:

• Позиция прокрутки документа

• Выбор элемента

• Открытые в последний раз метки времени

• Табличный порядок сортировки

• Размер окна (в OS X)

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

Проект для устойчивости и межплатформенной совместимости

Помните следующие факторы при разработке формата файла документа для iCloud:

• Используйте межплатформенное представление данных. Подобно названные классы — те, префиксами которых является «UI» для iOS и «NS» для OS X — не непосредственно совместимы. Это - истина для цветов (UIColor и NSColor), изображения (UIImage и NSImage), и пути Безье (UIBezierPath и NSBezierPath), а также для других классов.

  Например, OS X NSColor объект определяется с точки зрения цветового пространства (NSColorSpace), но в iOS нет никакого класса цветового пространства.

  При использовании такого класса в свойстве формата документа необходимо разработать промежуточное представление iCloud, которое можно искренне перераспределить в собственное представление на любой платформе, как изображено на рисунке 3-6. Когда NSDocument объект сохраняет свои данные к диску (шаг 1), это преобразовывает каждый специфичный для платформы тип данных в промежуточное межплатформенное представление. Те межплатформенные данные сохраняются к iCloud и загружаются на другие устройства пользователя (шаги 2 и 3). Когда версия iOS Вашего приложения извлекает те данные (шаг 4), это преобразовывает данные из межплатформенного представления в специфичную для iOS версию.

  

  Храня документ из Вашего приложения для iOS для более позднего просмотра на любой платформе, Вы инвертировали бы процесс, показанный на рисунке 3-6 — запуск, храня Ваш документ iOS с помощью межплатформенного представления данных.

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

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

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

• Всегда используйте нечувствительные к регистру имена файлов. OS X, по умолчанию, и для почти всех пользователей, использует нечувствительную к регистру файловую систему. Например, файл mydoc.txt и файл MyDoc.TXT не может оба существовать в том же каталоге в OS X. В отличие от этого, iOS обрабатывает те имена файлов, как являющиеся отличающимся.

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

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

  Управление версиями Ваш формат документа всегда был хорошей идеей, и с iCloud и кросс-платформенными форматами, это еще более важно. Например, у пользователя iCloud, вероятно, будут многократные устройства, на которых можно просмотреть содержание; но пользователь не мог бы добросовестно обновить Ваше приложение на всех ее устройствах сразу. Так, например, Mac пользователя мог бы иметь новейшую версию Вашего приложения OS X, но его iPad мог бы иметь версию года Вашего приложения для iOS.

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

Для получения дополнительной информации о методах для разработки форматов файлов, посмотрите Types Выбора, Formats, и Strategies for Document Data in Document-Based App Programming Guide for iOS или Handling a Shared Data Model in OS X и iOS в Основанном на документе Руководстве по программированию Приложения для Mac.