iOS Swift: локальное сохранение с CloudKit

Я использую CloudKit для извлечения/хранения данных, но также хотел бы иметь локальный уровень сохраняемости. Предлагает ли CloudKit какие-либо возможности локального хранения? Или мне следует использовать NSUserDefaults (NSKeyedArchiver/NSKeyedUnarchiver)?


person colindunn    schedule 17.03.2015    source источник


Ответы (2)


В CloudKit нет механизма локального кеширования данных, вам придется делать это самостоятельно. Я могу предложить вам взглянуть на EVCloudKitDao, удобную библиотеку для CloudKit, которая поддерживает локальное кэширование. в файл.

person Edwin Vermeer    schedule 17.03.2015
comment
Можете ли вы порекомендовать какие-либо статьи или ресурсы, чтобы узнать больше о локальном хранилище с помощью CloudKit? - person colindunn; 20.03.2015
comment
проверил EVCloudKitDao, ничего себе, вы ниндзя :D вы не используете Core Data, но я правильно понимаю, что у вас есть классы, определенные в комплекте, и с отражением, которое вы загружаете, создаете экземпляры, установить значение? вау, это сложно, ПОЧЕМУ отражение, а не Core Data? в основном Core Data делают то же самое, но с меньшим количеством шаблонного кода ;-) - person János; 06.05.2015
comment
Я использую отражение для получения и установки всех значений из обычного объекта. Поэтому единственное, что вам нужно сделать, это определить свойства объекта. Затем EVCloudKitDao позаботится обо всем остальном. Это гарантирует, что все свойства будут добавлены в CKRecord и наоборот. Хранение данных в Core было бы вариантом, но тогда вам все равно нужно анализировать CKRecord и обратно. Я решил хранить свои данные локально в файлах с помощью NSCoding вместо того, чтобы записывать их в базу данных. - person Edwin Vermeer; 06.05.2015
comment
Определять свойства в объекте по-прежнему проще, чем поддерживать Core Data. Кроме того, вам нужно использовать только EVCloudKitDao, и вам вообще не нужен шаблонный код. Это был самый экономичный способ использования CloudKit, который я мог придумать. См. пример кода на странице github.com/evermeer/EVCloudKitDao#how-to. -use-the-evcloudkitdata это все, что вам нужно для таблицы с новостями, включая push-уведомления об изменениях - person Edwin Vermeer; 06.05.2015
comment
Забавно, у меня есть свой "EVCloudKitDao", но я называю его "Утилита". И он делает то же самое, что и ваш код. Ваша кривая обучения завершилась решением, основанным на рефлексии, а моя — на основе Core Data. Если он запущен и работает, кого это волнует. Поддерживать Core Data легко, если вы прошли крутую кривую обучения Core Data. Чтобы добавить атрибут или связь в редакторе Core Data, требуется точно такое же количество нажатий клавиши, как и для добавления свойства в исходный файл. - person János; 06.05.2015
comment
но тем не менее, Core Data поддерживает некоторые причудливые функции, т.е. rollback, пользователь взаимодействует, он генерирует операции, клиент помещает операции в последовательную очередь, и если CloudKit возвращает ошибку (какую-то серьезную, а не повторение 3-секундной последней), то все следующие операции уже на очереди будет rollback. У вас есть подобное? - person János; 06.05.2015
comment
Похоже, что ваша утилита использует Core Data в качестве основного источника и CloudKit в качестве резервного. Я работаю наоборот. Я сохраняю данные локально только в том случае, если сохранение в CloudKit прошло успешно. Кроме того, у меня есть полная интеграция обработки данных из подписок. С прямыми уведомлениями в коде, где он используется (вы, вероятно, делаете это через Core Data плюс NSFetchedResultsController?) - person Edwin Vermeer; 06.05.2015

Кэширование не встроено в CloudKit, в любом случае, когда вы реализуете его. Имейте в виду, что нужно кэшировать только системные поля для восстановления и синхронизации с CloudKit, снова проверьте это https://stackoverflow.com/a/35355916/1787109

person Ben    schedule 12.02.2016