CoreData + CloudKit, но без обмена
CoreData - это круто. Это делает кодирование постоянного хранилища с помощью базы данных SQLite довольно предсказуемой.
CloudKit - это круто. Это упрощает программирование постоянного хранилища в iCloud и позволяет использовать его на устройствах пользователя.
CoreData + CloudKit - это вдвойне круто, так как он дает преимущества как локального хранилища данных, так и совместного использования между устройствами.
Теперь я совершенно тупой и удивлен тем фактом, что Apple не поддерживает обмен CloudKit между пользователями при использовании CoreData + CloudKit. Каждый раз, когда я задаю этот вопрос, люди смотрят на меня так, как будто это кому-то нужно? Я в замешательстве. Есть ли причина, по которой нельзя использовать комбинацию хранилища с синхронизацией локального и облачного доступа?
Было бы очень полезно, если бы кто-нибудь мог помочь мне понять, почему этого не существует или почему я не хотел бы разрабатывать хранилище, которое включает локальную сохраняемость с синхронизацией с облаком и возможностью совместного использования этих объектов между пользователями?
2 ответа
Джастин, если я понимаю твою точку зрения, ты на 100% прав,
"Теперь я совершенно тупой и удивлен тем фактом, что Apple не поддерживает обмен CloudKit между пользователями при использовании CoreData + CloudKit..."
Синхронизация просто очень сложная.
"" Основными технологическими краеугольными камнями эпохи, в которой мы живем, являются Parse (программисты заслуженно заработали триллионы долларов), Firebase и сервисы синхронизации, предлагаемые AWS и Goog-services.
И многие другие конкуренты синхронизации, такие как Couchbase, ably.io, realm.io и подобные магистрали, такие как pubnub.
Синхронизация - это буквально основная магистраль сегодняшнего дня.
(Самые большие сервисы - TikTok, Twitter - это не более чем то, что вы просите, сервисы синхронизации, с добавлением нескольких кнопок и логотипов сверху.)
CFRD и другие подходы действительно очень сложны с точки зрения информатики (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type), и это невероятно сложно с точки зрения аппаратного обеспечения и проводов в большом масштабе.
Таким образом, вы в основном говорите: "Когда, о, когда Apple поторопится и создаст основу для синхронизации, чтобы я, наконец, смог прекратить использовать {Firebase, AWS или что-то еще, что у вас есть}…"
Ты прав.
(И не забывайте, что одна проблема заключается в том, что мы живем в мире двойственности droid-iphone. Ни один клиент не собирается нанимать вас для создания следующего тиктока для собак, facebook для собак, и это будет "просто iOS". Если Apple создают свою собственную службу синхронизации, она будет мертвой по прибытии, самый бессмысленный белый слон в творении, если только это не ios, droid, www, а также второстепенные мажоры, такие как unity и т. д.)
Если я понимаю ваш вопрос, да, думаю, это просто вопрос времени. Но (как и любая из магистралей синхронизации) он должен быть все-платформенным.
Даже не упоминать с iot, очками apple и т.
Согласились все вокруг.
Как вы упомянули, NSPersistentCloudKitContainerне поддерживает совместное использование в iOS 13, но из-за большого количества запросов на это добавляется в этом году (в настоящее время в стадии бета-тестирования). Вот доклад WWDC20, в частности, о публичной базе данных: https://developer.apple.com/videos/play/wwdc2020/10650/.
Отправной точкой здесь является NSPersistentCloudKitContainerOptions.databaseScope.
Между тем, если вам нужно поделиться прямо сейчас, до того, как этот материал будет выпущен, вы можете напрямую получить доступ к CKRecords, возможно, для реализации совместного использования без необходимости перестраивать всю реализацию CloudKit. Немного нечетко, но в первом абзаце этого документа это прямо указано, но без подробностей о том, как CKShare работает с синхронизацией основных данных.