Cloudkit: CloudKit — iCloud — Apple Developer

Упрощаем работу с CloudKit, или синхронизация в духе Zen

Введение

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

CloudKit — это не просто фреймворк. Это полноценный BaaS (Backend as a Service), т.е. комплексный сервис с полноценной инфраструктурой, включающей в себя облачное хранилище, пуш-уведомления, политики доступа и многое другое, а также предлагающий универсальный кросс-платформенный программный интерфейс (API).

• 10Gb хранилище под ресурсы
• 100MB под базу данных
• 2GB трафика в день
• 40 запросов в секунду

Эта статья — не реклама CloudKit и даже не очередной обзор основ работы с ним. Здесь не будет ничего о настройке проекта, конфигурировании App ID в вашем профиле разработчика, создании CK-контейнера или Record Type в дэшборде CloudKit. Кроме того, за рамками статьи остаётся не только backend составляющая, но и вся программная, относящаяся непосредственно к CloudKit API. Если вы хотели бы разобраться именно в основах работы с CloudKit, то для этого уже есть прекрасные вводные статьи, повторять которые нет никакого смысла.

Когда вы уже освоились с чем-то, что давно используете, рано или поздно возникает вопрос: как автоматизировать процесс, сделать его ещё более удобным и более унифицированным? Так возникли паттерны проектирования. Так возник наш фреймворк, облегчающий работу с CloudKit — ZenCloudKit, который уже был успешно применен в ряде проектов. О нём, а именно, о новом техническом способе работы с CloudKit, и пойдет речь дальше.

Универсальный интерфейс

Фреймворк написан на Swift 3 и именно Swift-разработчики в полной мере сумеют ощутить преимущества, которые даёт его использование. Для Objective-C возможен вполне полноценный bridge, но по известным причинам аналогичные вещи будут выглядеть в нём избыточными и более громоздкими в реализации. Примеры кода в данной статье будут написаны на Swift.

Перейдём к обзору, параллельно рассматривая пример реализации.

Пример реализации

Что же здесь происходит?

Положим, у нас есть объект event со свойством entity, где entity — это NSManagedObject. У этого NSManagedObject, как и у всякого объекта базы данных, есть поля, некоторые из которых являются свойствами, некоторые — ссылками, reference, на другие объекты NSManagedObject, образуя связи один-к-одному или один-ко-многим.

Чтобы сохранить этот объект (или удалить соответствующий ему) синхронно или асинхронно в базу данных CloudKit, пробросив при этом все связи, используется прокси-объект — iCloud, который содержит в себе соответствующие методы. Достаточно вызывать entity.iCloud.save() (асинхронное) или entity.iCloud.saveAndWait() (синхронное сохранение), чтобы все поля entity были записаны в соответствующие поля объекта CloudKit, а уникальный UUID от вновь сохраненного CKRecord (т.е. строковое свойство recordName объекта CKRecordID) был автоматически записан обратно в специально отведенное для этого поле объекта entity, образовав тем самым связь между локальным и удаленным объектом.

Если вы никогда не использовали CloudKit и всё это звучит непонятно, то проще сказать, что на любую сущность есть .iCloud.save() и этого достаточно, чтобы сохранить как сам объект, так и все его связи. Никакого больше множества идентичных методов для разных сущностей и грязи в клиентском коде. Удобно, не правда ли?

Настройка объектов синхронизации

В основе работы лежит широко применяемая схема маппинга свойств, которая используется во многих библиотеках, в различных веб-парсерах (таких как RestKit) и т.д. Маппинг же реализован в классической манере — посредством KVC, который поддерживается только наследниками NSObject. Отсюда, первое условие:

1) Каждый синхронизируемый объект должен быть наследником NSObject (к примеру, NSManagedObject – это отличный выбор).

2) Каждый синхронизируемый объект должен реализовать протокол ZKEntity, который выглядит следующим образом:

Если вы работаете с CoreData, то реализовывать нужно прямо в вашем (sub-)классе:

Как видно из протокола, обязательными полями являются recordType и mappingDictionary. Рассмотрим оба.

// REQUIRED (обязательные поля)

1) recordType — соответствующий тип записи, Record Type, в CloudKit.

Пример: класс Person содержит свойство recordType = “Person”. После вызова save() у его экземпляра, в дэшборде CloudKit именно в этой таблице (“Person”) будет заведена запись.

Реализация:

static var recordType = "Person"

Пример: класс Person содержит поля firstName и lastName. Чтобы сохранять их в таблицу Person в CloudKit под теми же именами, необходимо написать следующее:

static var mappingDictionary = [ "firstName" : “firstName”, “lastName” : “lastName” ]

// OPTIONAL (необязательные поля)

Остальные поля протокола являются опциональными,

3) syncIdKey — имя локального свойства, которое будет хранить ID удаленного объекта. ID — это паспорт объекта, необходимый для связи локальный<—>удаленный.

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

Реализация:

static var syncId: String = "cloudID"

Аналогично предыдущему, оно условно опционально. Есть возможность опустить реализацию и указать имя свойства для всех синхронизируемых объектов во время инициализации ZenCloudKit (см. далее).

Реализация:

static var changeDateKey: String = "changeDate"

Требованием здесь является то, чтобы свойство “локальный ключ” своим типом имело класс, который удовлетворяет базовым требованиям (наследует NSObject и реализует протокол ZKEntity).

При вызове save() у локального объекта ZenCloudKit попытается также сохранить все связанные с ним.

Реализация:

static var references : [String : String] =
                                        ["homeAddress" : "address"]

Схема: ZKRefList(entityType: ZKEntity.Type,
localSource: локальное свойство, которое возвращает массив объектов ZKEntity,

Реализация:

            static var referenceLists: [ZKRefList] = [ZKRefList(entityType: Course.self,
                                                    localSource: "courseReferences",
                                                    remoteKey: "courses")]

courseReferences – это user-defined свойство, возвращающее массив объектов ZKEntity, которые вы хотели бы сохранить и ссылки на которые необходимо поместить в перечень ссылок корневого объекта.

Код (продолжение):

 var courseReferences : [Course]? {
             get {
                 return self.courses?.allObjects as? [Course]
             }
     
             set {
                 DispatchQueue.main.async {
                     self.mutableSetValue(forKey: "courses").removeAllObjects()
                     self.mutableSetValue(forKey: "courses").addObjects(from: newValue!)
                 }
     
             } 

isWeak — опциональный флаг, который, будучи установленным (true), указывает на то, что любой другой объект, ссылающийся на экземпляр данного типа, образует слабую ссылку (аналогия с модификатором weak) в CloudKit. Это означает, что запись о нём будет удалена каскадно, как только будет удален объект, который содержит ссылку на него.

Пример: есть объект A, ссылающийся на объект B.

Если установить B.isWeak = true, объект А будет сохранен в CloudKit со “слабой ссылкой” на B. Объект B будет удален автоматически, как только вы удалите объект A.

Этот флаг является реализацией нативного API CloudKit и апеллирует к конструктору CKReference с флагом .deleteSelf:

CKReference.init(record: <CKRecord>, action: .deleteSelf)

Реализация:

static var isWeak = true

Если предполагается, что объект сущности CoreData должен всегда содержать какое-либо значение, отличное от nil, в качестве ссылки на другой объект, то всякий раз, когда данный объект будет отсутствовать в CloudKit при синхронизации, локальному свойству может быть автоматически задано значение по умолчанию.

Пример: есть класс A со свойством b и, зеркально ему, такой же Record Type в CloudKit.

В CloudKit имеется объект A, который отсутствует локально, имеющий пустую ссылку на B (значение отсутствует). При обычном сценарии в результате синхронизации вы бы получили объект A, у которого свойство b было бы nil. Но с установленным значением по умолчанию в локальном классе (referencePlaceholder = …) ZenCloudKit автоматически присвоит свойству b указанное вами значение:

A.b = referencePlaceholder,

где последний является экземпляром B.

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

Реализация:

static var referencePlaceholder: ZKEntity = B.defaultInstance()

// SUMMARY

На момент написания статьи это весь функционал, поддерживаемый ZKEntity. Подытожим изложенное ещё раз в виде конкретного примера.

Положим, есть класс Event:

Здесь:

• словарь для маппинга свойств.
• словарь для маппинга ссылок (опционально)
• CloudKit Record Type

Настройка контроллера и делегата

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

Класс-делегат должен будет реализовать следующий протокол:

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

Класс CloudKitPresenter в приведенном примере является делегатом ZenCloudKit. Здесь происходит инициализация и вызов callback-функций, необходимых для реализации полного цикла синхронизации. Полный цикл синхронизации — это последовательность закадровых операций, при которых осуществляется сравнение локальных и удаленных объектов по времени изменения и их актуализация на обоих концах. Для этого по каждому типу, т.е. по каждой зарегистрированной сущности ZKEntity, фреймворку необходимо предоставить три функции, реализующие соответственно создание, запрос объекта по ID (fetch) и запрос всех доступных объектов. В каждой из трёх функций в качестве параметра выступает класс ZKEntity (ofType T: ZKEntity.Type). В результате выполнения ZenCloudKit ожидает получить объекты именно данного типа.

zenAllEntities(ofType T: ZKEntity.Type)
— ожидает получить массив всех сущностей типа T

zenCreateEntity(ofType T: ZKEntity.Type)
— ожидает получить новый экземпляр T.

zenFetchEntity(ofType T: ZKEntity.Type, syncId: String)
— ожидает получить существующий экземпляр T по данному syncId (или nil если таковой отсутствует).

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

В приведенном примере для осуществления перечисленных операций используются стандартные методы MagicalRecord для поиска существующего, создания нового и запроса всех объектов, которые работают как extension-методы (или методы категорий, выражаясь в духе Objective-C) для NSManagedObject. Это значительно упрощает реализацию. Код становится универсальным, поскольку пропадает нужда делать type-check для каждого случая T.

Функции являются конкретной реализацией generic-абстракции, хотя, строго говоря, обобщения в сигнатуре функций не используются в целях обеспечения совместимости с Objective-C.

В последней функции используется инструкция T.predicateForId(…). Это метод расширения, предоставленный ZenCloudKit, который возвращает корректный предикат поиска для данного типа T по данному syncId (чтобы избежать хард-кода и связанных с ним возможных ошибок в названии свойства, локально хранящего ID).

zenEntityDidSaveToCloud (entity: ZKEntity, record: CKRecord?, error: Error?)
— вызывается каждый раз при завершении сохранения в CloudKit. На этой фазе объект entity уже получил ID удаленного объекта, поэтому здесь можно, например, сохранить главный контекст базы данных.

Делегат реализует закрытый Singleton (sharedInstance не виден клиенту). Для того, чтобы проинициализировать и контроллер, и его делегат, достаточно где-либо извне в нужный момент вызвать метод:

В методе инициализации происходит настройка фреймворка:

Задаются стандартные для CloudKit параметры:

• имя контейнера (container)
• тип базы данных (ofType: .public/.private)

В параметр entities мы передаем массив всех типов, с которыми собираемся работать.

ignoreKeys — массив строковых ключей, обнаружив которые, ZenCloudKit должен проигнорировать объект (например, не сохранять или не удалять его).

deviceId — ID устройства. Очень важный параметр, если в синхронизации будет задействовано несколько устройств. Об уникальности этого параметра должен позаботиться разработчик. Стандартно, берётся Hardware UUID, но возможны и другие варианты.

// RECAP

Реализация настроек, описанных до сих пор, является необходимым и достаточным условием для того, чтобы работал базовый функционал, предоставленный прокси-объектом iCloud, который, в свою очередь, реализует протокол ZKEntityFunctions:

Второй вариант — принудительная синхронизация (forced: true). Могут быть случаи, когда целостность данных оказывается нарушенной. Тогда вы можете в принудительном порядке проверить каждый синхронизируемый объект, игнорируя дату последнего успешного цикла, и актуализировать данные локально и удаленно. Локальные объекты будут обновлены тем, что лежит в CloudKit (если по каким-то причинам этого не произошло ранее). А в CloudKit могут быть сохранены локальные объекты, которые также почему-то не были сохранены. В зависимости от специфики вашего приложения, вы сами можете определить, в каком месте вызывать принудительную синхронизацию (например, при старте, во время длительного простоя или же отвести эту функцию в настройки). В общем случае в этом вызове нет нужды и, скорее всего, вам не придётся к нему прибегать.

Вызов метода syncEntities() на уровне контроллера делает то же самое, только применительно ко всем зарегистрированным сущностям. Параметр specific принимает конкретные типы, которые вы бы хотели синхронизовать (nil — если нужно применить ко всем).

Осталось разобрать метод zenSyncDIdFinish, сигнатура которого выглядит так:

T — тип сущности, объекты которой необходимо создать или обновить.

newRecords, updatedRecords — массивы CKRecord, объектов, которые необходимо создать или обновить локально. Ориентиром при поиске локального соответствия выступает уникальный ID, который стандартно хранится в свойстве CKRecord. recordID.recordName. Сущность, среди объектов которой нужно искать соответствия и экземпляр которой создать, является T.

deletedRecords — массив объектов ZKDeleteInfo, каждый из которых хранит информацию об удаляемом объекте: локальный ZKEntity-тип и ID объекта. Эти объекты могут быть различных типов, поэтому ориентироваться на тип T в данном случае не нужно. Тип удаляемого объекта следует смотреть в свойстве entityType, а ID объекта — в свойстве syncId объекта ZKDeleteInfo. Класс выглядит следующим образом:

Всегда вызывайте finishSync() в конце синхронизации.

Это относится не только к фазе удаления, описанной выше, но и к фазам создания и обновления.

Подытожим сказанное, рассмотрев фрагмент реализации функции zenSyncDIdFinish:

— вызов finishSync()
— функции обновления UI, которые бы отразили изменившееся состояние БД (если требуется).

При помощи следующей инструкции:

мы заполняем поля локального объекта полями CKRecord, который нам доступен как аргумент в одном из массивов. Флаг fetchReferences позволяет загрузить все связи. Под загрузкой связей подразумевается реальная загрузка соответствующих объектов (приведенных в массивах references и referenceLists, описанных в протоколе ZKEntity) из CloudKit и их привязка к данному объекту entity. Если при загрузке связи обнаружится, что соответствующий локальный объект не существует (zenFetchEntity == nil), он будет автоматически создан в локальной базе данных путём вызова метода делегата zenCreateEntity.

Если образование этих связей предполагает изменение UI, об этом необходимо позаботиться дополнительно (updateEntity — в части заполнения связей — работает асинхронно и дожидаться его выполнения не стоит). В обработчике ZKRefList это можно сделать в сеттере, о чём уже говорилось:

При получении связей *-ко-многим (в результате вызова updateEntity с флагом fetchReferences = true) в сеттер teacherReferences попадает массив объектов Teacher. В главном потоке мы обновляем этот список у корневого объекта NSManagedObject, а затем вызываем методы обновления UI.

Маппинг связей *-к-одному (массив references, содержащий название свойств-ссылок на другие сущности ZKEntity) не предполагает обработчиков (get/set), поэтому, если требуется отслеживать образование этих связей, необходимо прибегнуть либо к аналогичному методу — в качестве ключей в массиве references указывать обработчики и переопределять их геттер и сеттер, — либо использовать ReactiveCocoa или иные средства для наблюдения за свойствами.

Работа со ссылками кажется богатой нюансами, и это действительно так, однако эти нюансы — закономерное следствие обвязки и автоматизации работы двух систем — CoreData и CloudKit.

Если вам нужно иметь более прямой контроль над образованием связей, обновлением UI или другими sync-related процессами, по усмотрению вы можете совместить средства ZenCloudKit и нативный CloudKit API. В методе zenSyncDidFinish передаются массивы объектов CKRecord, которые, помимо свойств, содержат объекты CKReference. Это значит, что вы можете кастомизировать парсинг, а также вручную загрузить те объекты, которые вам нужны.

На этом настройка ZenCloudKit окончена.

Нюансы использования

Push-уведомления

Блокировка синхронизации

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

Логгирование

Для успешной работы приложению и ZenCloudKit необходим доступ на чтение и запись всех используемых Record Type, включая query-права на ключ modifiedDate (CKRecord). Не забудьте включить всё это в дэшборде. Кроме того, фреймворком в базе данных будут созданы таблицы под названием Device и DeleteQueue. Первая будет содержать список зарегистрированных устройств, которые обращаются к вашей базе данных. Вторая — очередь на удаление — представляет собой таблицу с мета-информацией об удаленных объектах, которые необходимо удалить на каждом устройстве (для каждого устройства — соответствующая запись). После того, как это устройство осуществит локальное удаление соответствующего объекта, запись из DeleteQueue также будет стёрта. Эти две таблицы являются служебными, к ним должен быть полный доступ на чтение и запись для каждого устройства.

Безопасность

Описанного выше сценария гарантированно не случится с ZenCloudKit, который на этапе инициализации создает очередь для каждого зарегистрированного типа ZKEntity, обеспечивая строгую последовательность в выполнении операций сохранения. Если среди 15 объектов — по 3 объекта разных типов (итого 5 типов), то при их одновременном сохранении, “в одно время” будет запущен процесс сохранения для 5 объектов, без какой-либо угрозы. Также схема сводит на нет возможность отказа (DoS).

Заключение

Некоторые функции в данной статье не описаны (например, управление потерянным соединением и автоматический запуск полного цикла синхронизации, по мере его восстановления). Известны также некоторые нюансы: например, на данный момент отсутствует поддержка CKAssets (однако её реализовать не сложно).

В данный момент фреймворк вместе с демо-проектом готовится на выкладку. Если вы хотели бы получить исходной код ZenCloudKit или у вас есть какие-либо вопросы или комментарии, будем рады узнать о них в комментариях к данной статье или через ЛС.

Введение в CloudKit — CoderLessons.com

Вступление

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

• до 1 ПБ хранилища активов (изображения, аудиофайлы и т. д.)
• до 10 ТБ хранилища базы данных (строки, числа, массивы и т. д.)
• аутентификация пользователя iCloud
• уведомления

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

Требования

Это руководство требует, чтобы вы работали с Xcode 6+ и имели учетную запись разработчика iOS. Вам также необходимо скачать стартовый проект с GitHub .

1. Конфигурация проекта

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

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

Откройте вкладку « Возможности » вверху и включите iCloud , переключая переключатель справа. Это покажет настройки iCloud для цели CloudBug .

В настройках iCloud установите флажок CloudKit, чтобы включить CloudKit для цели CloudBug.

Создайте и запустите приложение на физическом устройстве в iOS Simulator, чтобы увидеть, все ли работает без ошибок.

2. Создание типа записи об ошибке

Нажмите кнопку CloudKit Dashboard в нижней части настроек iCloud. Это откроет панель управления CloudKit в вашем браузере. После входа в систему с учетной записью разработчика должна появиться панель управления CloudKit. Прежде чем продолжить, позвольте мне пройтись по пунктам на боковой панели слева.

схема

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

Публичные данные

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

Частные данные

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

Администратор

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

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

Если вы выберете « Типы записей» на боковой панели слева, вы заметите, что тип с именем « Пользователи» уже существует.

Давайте создадим новый тип записи с именем Bug, который будет содержать заголовок и описание. Нажмите кнопку «плюс» вверху, чтобы создать новый тип записи.

Измените имя нового типа записи на Bug и добавьте два атрибута, Title и Description . Создайте оба атрибута типа String, отметив только опцию индекса запроса . Вот как должен выглядеть новый тип записи.

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

3. Создание записей в CloudKit Dashboard

Когда вы выбираете Зону по умолчанию в Общедоступных данных , тип записи об ошибке уже должен быть выбран. Создайте новую запись, нажав « Новая запись» или кнопку «плюс» вверху.

Введите все, что вы хотите для описания записи и Поля заголовка .

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

4. Загрузка записей

Вернитесь к Xcode и откройте MasterViewController.swift . Вверху добавьте оператор импорта для импорта платформы CloudKit.

Обновите метод viewDidLoad , добавив следующий фрагмент кода.

Давайте посмотрим, что происходит в этом фрагменте кода.

• Сначала мы получаем ссылку на контейнер по умолчанию для вашего приложения. Этот контейнер содержит типы записей и записи, которые мы создали на информационной панели CloudKit. Вы можете создать больше контейнеров с уникальным идентификатором в Target Inspector> Capabilities .
• Во-вторых, мы получаем ссылку на публичную базу данных контейнера. Формат такой же для частной базы данных.
• Затем мы создаем запрос для типа записи об NSPredicate экземпляр NSPredicate . Этот предикат можно использовать для фильтрации результатов запроса, например, только выборки записей, созданных или измененных после определенной даты. Для этого примера мы выбираем каждую запись типа Bug .
• Далее мы сообщаем базе данных выполнить запрос, который запускает асинхронный запрос. Когда запрос завершен, блок завершения выполняется, передавая нам массив results и объект error .
• Если объект error равен nil , мы перебираем элементы массива results и создаем локальный экземпляр Bug для каждой записи. Каждый экземпляр Bug добавляется в источник данных табличного представления, а табличное представление перезагружается в главном потоке.

Создайте и запустите ваше приложение, чтобы увидеть, загружена ли запись, созданная нами на панели мониторинга CloudKit, в CloudBug.

Если вы видите ошибку в консоли Xcode, похожую на приведенную ниже, убедитесь, что вы вошли в правильную учетную запись iCloud на своем тестовом устройстве. Это также верно, если вы используете CloudBug в iOS Simulator.

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

5. Создание записей

В то время как загрузка данных из iCloud через CloudKit может быть очень полезной, CloudBug также нужна возможность, позволяющая пользователям создавать новые записи. В MasterViewController.swift добавьте следующий фрагмент кода в метод receiveBug(_:) .

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

Обратите внимание, что объект record возвращаемый из iCloud в обработчике завершения saveRecord(_:completionHandler:) включает в себя значения, которые вы устанавливаете вручную, а также пять атрибутов по умолчанию, которые мы видели ранее на панели мониторинга CloudKit.

Создайте и запустите свое приложение, а также опубликуйте новую ошибку, нажав кнопку «плюс» в правом верхнем углу, заполнив поля заголовка и описания. Нажмите « Опубликовать» и сохраните новую запись в iCloud в базе данных CloudKit.

Еще раз зайдите на панель мониторинга CloudKit и перейдите в зону по умолчанию в разделе « Общие данные» . Если все прошло хорошо,   Вы должны увидеть две записи об ошибках в базе данных.

6. Удаление записей

Давайте закончим этот урок, позволив пользователям удалять ошибки. Добавьте следующий фрагмент кода в tableView(_:commitEditingStyle:forRowAtIndexPath:) метод чуть выше objects. removeAtIndex(indexPath.row) .

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

Создайте и запустите приложение и удалите одну из ошибок, проведя вправо или нажав кнопку « Изменить» .

Еще раз зайдите на панель управления CloudKit, чтобы увидеть, действительно ли выбранная вами ошибка была удалена.

Вывод

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

Swift, CloudKit, HomeKit и Metal — новые инструменты для разработчиков, представленные на WWDC 2014

Apple посвятила заключительную часть своей презентации на конференции WWDC новшествам в комплекте программного обеспечения для разработчиков (SDK), среди которых отметился новый язык программирования Swift и инструменты разработки для сервисов здоровья, домашней автоматизации, iCloud и взаимодействия приложений.

  импорт UIKit
импортировать CloudKit

class ViewController: UIViewController {

}
  

  импорт UIKit
импортировать CloudKit

class ViewController: UIViewController {

    // MARK: - Просмотр жизненного цикла

    переопределить функцию viewDidLoad () {
        super.viewDidLoad ()

        CKContainer.default ()
    }

}
  

  импорт UIKit
импортировать CloudKit

class ViewController: UIViewController {

    // MARK: - Просмотр жизненного цикла

    переопределить функцию viewDidLoad () {
        super.viewDidLoad ()

        CKContainer.default (). FetchUserRecordID {(идентификатор записи, ошибка) в
            if let error = error {
                печать (ошибка)
            } иначе, если разрешить recordID = recordID {
                печать (идентификатор записи)
            }
        }
    }

}
  

 CKRecord * запись = [[выделение CKRecord] initWithRecordType: @ "RecordType"];
запись [@ "key"] = @ "Некоторые данные";
[[CKContainer defaultContainer].(CKRecordID * recordID, NSError * error) {

}]; 

  Лицензия MIT (MIT)

Авторские права © 2015 Yalantis

Настоящим предоставляется бесплатное разрешение любому лицу, получившему копию этого программного обеспечения и связанных файлов документации («Программное обеспечение»), для работы с Программным обеспечением без ограничений, включая, помимо прочего, права на использование, копирование, изменение, объединение, публикацию, распространять, сублицензировать и / или продавать копии Программного обеспечения, а также разрешать лицам, которым предоставляется Программное обеспечение, делать это при соблюдении следующих условий:

Вышеупомянутое уведомление об авторских правах и это уведомление о разрешении должны быть включены во все копии или существенные части Программного обеспечения.ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ, ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ,
ПРИГОДНОСТЬ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ И ЗАЩИТА ОТ ПРАВ. НИ В КОЕМ СЛУЧАЕ
АВТОРЫ ИЛИ ДЕРЖАТЕЛИ АВТОРСКИХ ПРАВ НЕСУТ ОТВЕТСТВЕННОСТЬ ЗА ЛЮБЫЕ ПРЕТЕНЗИИ, УБЫТКИ ИЛИ ДРУГИЕ
ОТВЕТСТВЕННОСТЬ, ВЫЯВЛЯЮЩАЯСЯ ЛИ В РЕЗУЛЬТАТЕ ДОГОВОРА, ПРАКТИКИ ИЛИ ИНЫМ ОБРАЗОМ,
ВНЕЗАПНО ИЛИ В СВЯЗИ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ, ИЛИ ИСПОЛЬЗОВАНИЕМ ИЛИ ДРУГИМИ ДЕЯМИ В
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ.
  

  func getRecordsFromCloud () {
        // Получение данных с помощью Convenience API
        let cloudContainer = CKContainer.defaultContainer ()
        пусть publicDatabase = cloudContainer.publicCloudDatabase
        let predicate = NSPredicate (значение: true)
        let query = CKQuery (recordType: "Pivo", предикат: предикат)
        query.sortDescriptors = [NSSortDescriptor (ключ: "creationDate", по возрастанию: false)]

        // Создаем операцию запроса с запросом
        пусть queryOperation = CKQueryOperation (запрос: запрос)
        queryOperation.желаемыйKeys = ["имя", "тип", "местоположение"]
        queryOperation.queuePriority = .VeryHigh
        queryOperation.resultsLimit = 50
        queryOperation.recordFetchedBlock = {(запись: CKRecord!) -> Пусто в
            if let restaurantRecord = record {
                self.restaurants.append (restaurantRecord)
            }
        }

        queryOperation.queryCompletionBlock = {(курсор: CKQueryCursor ?, ошибка: NSError?) -> Пусто в
            if (error! = nil) {
                print ("Не удалось получить данные из iCloud - \ (ошибка !.localizedDescription) ")
                возвращаться
            }

            print («Успешно получить данные из iCloud»)
            self.refreshControl? .endRefreshing ()
            NSOperationQueue.mainQueue (). AddOperationWithBlock () {
                self.spinner.stopAnimating ()
                self.tableView.reloadData ()
            }

        }

        // Выполняем запрос
        publicDatabase.addOperation (queryOperation)
    }
  

 @AppStorage («логин»)  частный   var  login =  false  

  пусть  userID = UserDefaults.standard.object (forKey: «userID»)  как ? Строка 

  if  (! Login && (userID ==  nil )) {
 ... 
} else {
 ... 
}