WWDC Quick Look 💓 By SwiftGGTeam
Sync a Core Data store with the CloudKit public database

Sync a Core Data store with the CloudKit public database

元の動画を見る

ハイライト

iOS 14 用NSPersistentCloudKitContainerOptions増加databaseScopeこれにより、コア データ ストアが CloudKit パブリック データベースと同期し、アクセス許可クエリ、ポーリング インポート、ソフト削除戦略を使用してパブリック データセットの読み取りおよび書き込み境界を処理できるようになります。

主要内容

2019年NSPersistentCloudKitContainerCore Data ストアは CloudKit プライベート データベースと同期されています。このモデルはユーザー自身のデータに適しています。アカウントが存在する必要があり、データは現在のユーザーにのみ属し、CloudKit プッシュ通知は変更を適時にローカルに戻すことができます。 (00:38)

パブリック データベースの必要性は、別の種類のアプリから生じます。開発者は、すべてのユーザーが読み取れる一連のアプリケーション テンプレートを事前設定し、ユーザーが共有データを提供できるようにしたいと考えています。ゲームのハイスコアリストはスピーチの中で最も直接的な例です。ハイスコアはすべてのプレイヤーによってローカルで読み取られ、並べ替えられ、クエリされる必要があり、アーカイブとキャラクター設定は依然としてプライベートデータベースに残されるべきです。 (05:14)

iOS 14 の変更は小規模ですが、データリンク全体に影響します。 Core Data ストアをパブリック データベースにポイントして、プライベート データを別のストアに配置しながら、デバイス上に完全なローカル イメージを保持できます。このように、UI は引き続きコア データを読み取り、ローカルのフェッチ、ソート、および順序付けのパスは変更されず、CloudKit がパブリック データを取り込む役割を果たします。 (02:2805:58)

その代償として、パブリック データベースのセマンティクスはより複雑になります。 iCloud にログインしていないユーザーもパブリック データベースを読み取ることができます。ログインしたユーザーのみがレコードを作成できます。変更と削除は、レコードの所有者、ストアの種類、および CloudKit ゾーンの機能によって異なります。 Session の焦点は、これらの境界をクリアし、プライベート データベースの同期前提をパブリック データベースに直接移動しないようにすることです。 (06:48)

詳細

パブリック データベース ストアを構成する (02:28)

プレゼンテーションにおける最小限の変更は、既存の Core Data スタックにストアの説明を設定することでしたcloudKitContainerOptions、 またNSPersistentCloudKitContainerOptions.databaseScopeに設定public。完全なシーケンスは次のとおりです。NSPersistentStoreDescription、履歴追跡とリモート変更通知を保持、作成NSPersistentCloudKitContainerOptions、設定databaseScope、オプションをストアの説明に戻し、最後にコンテナにこれらのストアをロードさせます。

キーポイント:

  • databaseScopeこのセッションで導入された新しい API で、パブリック データベースかプライベート データベースを選択するために使用されます。
  • NSPersistentCloudKitContainerOptions教えてNSPersistentCloudKitContainerこのストアは CloudKit に接続する必要があります。
  • パブリック ストアは通常の Core Data ストア記述を通じて読み込まれるため、UI レイヤーを直接アクセスするように変更する必要はありません。CKDatabase
  • アプリにパブリック データとプライベート データの両方がある場合、それらを異なるストアに配置し、同じ Core Data スタックで管理できます。

CloudKit ダッシュボードにインデックスを追加 (03:30)

設定databaseScope最後に、CloudKit スキーマを構成する必要があります。パブリックデータベースのインポート方法はクエリに依存し、ダッシュボードの各レコードタイプはrecordNameそしてmodifiedAtインデックスを増やします。講義の例には 5 つのレコード タイプがあるため、この手順を 5 回繰り返す必要があります。

キーポイント:

  • これらのインデックスはサポートするために使用されます。NSPersistentCloudKitContainerパブリック データベースに対してクエリを開始します。
  • ダッシュボードに完全なレコード タイプが表示されない場合は、最初にスキーマの初期化を行う必要があります。
  • パブリック データベースはデバイス上に完全なローカル イメージを形成するため、ローカル クエリは引き続き Core Data を通過できます。
  • 各レコードタイプを設定する必要があります。タイプが欠落していると、そのタイプのレコードのインポートに影響します。

コントロールの作成、変更、インターフェイス編集ステータス (06:48)

プライベート データベースのルールは単純です。ログインせずに iCloud を操作することはできません。ログイン後は、ユーザーはすべて自分のデータを所有します。パブリック データベースでは、ログインしていないユーザーがデータを読み取ることができます。レコードを作成するにはログインが必要です。レコードを変更するには、現在のユーザーがこのオブジェクトを変更する権限を持っているかどうかを判断する必要があります。以前は、まず CloudKit から現在のアカウントをリクエストしてから、NSPersistentCloudKitContainer管理対象オブジェクトの背後にあるレコードを取り出し、作成者のユーザー ID と比較しますが、このパスはすべての UI コントロールに適しているわけではありません。

キーポイント:

  • canUpdateRecord(forManagedObjectWithID:)管理オブジェクト ID を使用して、現在のオブジェクトが更新可能かどうかを判断します。
  • この判断では、現在のデバイス アカウント、オブジェクトが配置されている永続ストア、ストアが CloudKit でサポートされているかどうか、およびアカウントの切り替えとその他の境界条件が考慮されます。
  • canModifyObjects(in:)これはリスト ページなどのより粒度の粗い UI に適しており、ストア内のオブジェクトを変更できるかどうかを判断するために使用されます。
  • 編集ボタン、新規ボタン、詳細ページの編集コントロールは、アプリがiCloudにログインしているかどうかだけを見るのではなく、これらの判定結果を使用する必要があります。

パブリック データベースのインポート リズムを理解する (10:08)

プライベート データベースはプッシュ通知に依存できます。 CloudKit プッシュを受信した後、NSPersistentCloudKitContainer作成するCKFetchRecordsZoneChangesOperation、変更されたレコードをローカル ストアにプルバックします。パブリック データベースはこのパスを使用できません。使用する必要があります。CKQueryOperation各レコード タイプをクエリすることで、投稿、タグ、添付ファイル、画像、多対多の関係が個別にリクエストを開始します。

キーポイント:

  • パブリック データベースは、プッシュ通知を待つ代わりにポーリングを使用します。
  • NSPersistentCloudKitContainerアプリの起動時、またはアプリの約 30 分間の使用後にのみポーリングされます。
  • パブリック データベースの鮮度はプライベート データベースの鮮度とは異なります。クラウド内のすべての変更が即座にローカルに反映されるとは限りません。
  • 管理オブジェクト モデルが単純であればあるほど、パブリック データベースに必要なクエリ要求が少なくなります。パブリック データ エンティティは、特殊な Core Data 構成に制限する必要があります。

公開データの削除セマンティクスを論理的な削除で処理する (13:35)

CloudKit は、プライベート データベースからレコードを削除するときにトゥームストーンを残します。以降のインポートは次のように行うことができます。CKFetchRecordsZoneChangesOperation他のデバイス上のトゥームストーンを参照し、ローカル オブジェクトを削除します。パブリック データベースにクエリを実行する場合、レコードが削除された後はクエリ可能なトゥームストーンは残りません。オブジェクトをダウンロードした他のデバイスは削除イベントを受信しない可能性があります。

キーポイント:

  • canDeleteRecord(forManagedObjectWithID:)現在のストア セマンティクスに従って、このオブジェクトの削除を伝播できるかどうかを判断できます。
  • 戻るfalseその際の講演では、「インターフェースからの削除」と「公開データベースからの削除」は別々に扱うべきだと示唆した。
  • アプローチ例は、オブジェクトのisTrashedに設定true次に、フェッチリクエストで述語を使用して、ゴミ箱に入れられたレコードをフィルタリングします。
  • スペースを再利用する必要がある場合は、ゴミ箱レコード内の不要になったフィールドをクリアできます。ユーザーがこの更新を処理したことを確認するまで待ってから、パブリック データベース内のレコードをクリーンアップしてください。

重要ポイント

共有テンプレート ライブラリ

対処方法: すべてのユーザーが読み取ることができるクリエイティブ アプリ用のテンプレート ライブラリのセットを提供します。ユーザー自身の下書きは引き続きプライベート データベースに保存されます。

実行する価値がある理由: このセッションでは、アプリケーション テンプレートと初期データ セットがパブリック データベースの一般的な要件であり、デバイスはローカル イメージも保持できることを明確に述べています。

開始方法: テンプレート関連のエンティティをパブリック ストアのコア データ構成に配置し、設定しますdatabaseScopeのためにpublic、CloudKit ダッシュボードの各レコード タイプに追加しますrecordNameそしてmodifiedAt索引。

コミュニティによって提供されたランキング データ

何をすべきか: ユーザーが投稿したハイスコア、レベルスコア、またはチャレンジの結果を記録し、すべてのユーザーがスコアによってローカルで並べ替えおよびフィルターできるようにします。

実行する価値がある理由: この講演では、ハイスコア テーブルが最も一般的なリクエストであると考えられています。その理由は、ユーザーはローカルでの高速フェッチ、並べ替え、並べ替えが必要であり、共有データ セットにレコードを提供する必要があるためです。

開始方法: ランキング エントリのみをパブリック ストアに置きます。アーカイブ、ロール構成、およびユーザー設定をプライベート ストアに置きます。 iCloudのログインステータスに基づいて新しいボタンを追加し、コントロールを編集しますcanUpdateRecord(forManagedObjectWithID:)裁判官。

オフラインにできるパブリックラベルディレクトリ

やるべきこと: コンテンツ アプリ用の公開タグ、カテゴリ、または厳選されたコレクションのセットを維持します。管理者は、期限切れのアイテムをインターフェイスから削除できます。

実行する価値がある理由: パブリック データベースを削除しても、ダウンロードされたデバイスにトゥームストーンが伝播されることはありません。直接削除すると、デバイスごとに異なる結果が表示される場合があります。

開始方法: 公共エンティティに追加isTrashed分野;いつcanDeleteRecord(forManagedObjectWithID:)戻るfalseいつ更新されましたかisTrashed;ゴミ箱に捨てられたレコードをフィルタリングするためのリスト取得リクエスト。

明確な更新が期待されるパブリック リポジトリ

手順: サンプル データ、参照アイテム、選択したコンテンツなどのオフライン ファーストのパブリック データベースを起動後に利用できるようにします。リフレッシュ レートには秒は必要ありません。

実行する価値がある理由:NSPersistentCloudKitContainerパブリック データベースは起動後、約 30 分の使用後にポーリングされます。これは、高い鮮度を必要としないデータに適しています。

開始方法: パブリック データ モデルを小さく明確にし、パブリック データベースと同期する必要があるエンティティのみを対応する構成に含めます。インターフェイスのコピーにより、リアルタイム更新の約束が回避されます。

関連セッション

コメント

GitHub Issues · utterances