CloudKit. CKShare nested objects (шаринг дочерних записей)

cloudkit
#1

Кто-то практиковал в достаточной степени шаринг у КлаудКита? Везде в документации у Эппл написано, что при шаринге корневой записи, для дочерних автоматом создаются ckshare, что логично. Однако при чтении CKShare другим юзером корневая читается норм, а по дочерним ошибка, что нет таких записей в данной зоне записи…
Есть какие-то подводные камни или ньюансы? Ищу ошибку в коде, но пока вроде всё норм, а шарить отдельно все дочерние - так не должно быть, нелогично же.

#2

Решил. Но там конечно то ещё минное поле:

  1. Когда вы создаёте вложенные объекты в CloudKit, вы указываете родителя при помощи reference. Но этого недостаточно для общего использования! Вы обязаны указать родителя методом .setParent()!!! Это обязательное условие для автоматического шаринга дочерних записей. Это необходимо делать на этапе создания записи в CloudKit.
  2. При запросе дочерних записей, вы получаете записи из общей базы данных sharedDB.
    Важная особенность: в общей базе данных, через которую вы получаете доступ к чужим записям в приватных базах, совершенно другие зоны записи, нежели в частных - они формируются автоматически формате CustomZone: _acBxvsdvsdkvmndsljvns! В общем к id зоны записи, которую вам шарят, ещё добавляется различный суффикс.
  3. Поэтому, при получении самой записи, которую шарят, нет ничего сложного, тк метаданные этой записи приходят в методы делегата обработки принятия шары. А вот для получения дочерних, нужно запрашивать recordID из правильной зоны записи. А её как раз можно достать из корневой шары - CKRecord.recordID.zoneID!!!

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

#3

А кто-то знает, как получить данные от SharedDB какой именно объект изменился? А то нашёл подписки только на БД в целом или зону записи…

#4

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

  1. вы получаете уведомление, что в БД что-то изменилось.
  2. при помощи CKFetchDatabaseChangesOperation вы получаете изменения в БД или CKFetchRecordZoneChangesOperation измения в определённой зоне…