CloudKitでCore Dataを使用する

(音楽) (拍手) おはようございます

AppleのCore Dataチームの ニック･ジレットです Core DataとCloudKitの 併用方法を説明します 我々は各自所有する どのデバイスを― どこで使っても自分のデータが 利用できるべきだと考えます これを実現するために― アプリケーションへの 機能追加の簡易化が必要です 外ではiPhoneを 家ではMacを使い― カバンにMacBookを入れて 持ち歩く方も多いと思います どのデバイスのデータも もともとは固定されています 移動させるにはユーザによる 何らかの操作が必要です この操作にはクラウドの ストレージを使っています あるデバイスのデータを 包括的かつ― 透過的に別のデバイスに 移動できるからです デバイスが１つでも クラウドの利点はあります デバイスのデータはクラウドに バックアップされます 何らかの理由で 新しいデバイスに変えても― すぐに前のデバイスのデータが いつも通りに復元されます 我々のプラットフォームには これを解決する別の技術もあります 例えばCore Dataは 強力なAPIで― アプリケーションやディスクの データをローカルで管理します CloudKitは巨大なデータベースへの アクセスを可能にします これらのフレームワークは我々の全ての プラットフォームで利用できます これで多彩なアプリケーションを 構築できます ２つのフレームワークは とても似ています 記述パターンやパラダイムも 共通しています 双方のAPIをオブジェクト モデル ストアを軸にモデル化します Core Dataではオブジェクトを NSManagedObjectと呼びます アプリケーションはディスクに 保存した値にアクセスできます CloudKitで閲覧できる CKRecordは― クラウドに保存したデータに アクセスするキーバリューです オブジェクトを記述するのは モデルです Core Dataでは NSManagedObjectModelと呼ばれ― コードまたはXcodeの モデルエディタで生成できます 同様にCloudKitでは Schemaを使います CloudKitのSchemaは開発時に CKRecordかダッシュボードを― 使うことでCloudKitに 動的に定義されます 各Core Data利用のため オブジェクトの一貫性は― ストアに保持されます Core Dataでは これを NSPersistentStoreと呼びます CloudKitではCKRecordは CKRecordZoneまたは― CKDatabaseに保存されます 長年 皆様から多くのご要望を 頂いていた― ２つの似た概念のフレームワークの 結合に取り組みました 今年大きく改善した点を― Xcodeのアプリケーション生成の 例でご覧ください Xcodeを開きました 新しいiOSプロジェクトを― Master Detailアプリケーション として作成します Master Detailの優れたUIで Core Dataの機能を生かせます 選択して次に進みます アプリケーションに 名前をつけます 今回は単純に WWDCDemoとします Core Dataのお話ですから Core Dataにチェックを入れます Xcode 11の変更点はUse CloudKit というチェックボックスです これがXcodeにCore Dataと CloudKitを使った― アプリケーションの作成を 可能にします チェックを入れ 次に進み― ファイルシステムのどこかに アプリケーションを置きます CreateをタップするとXcodeが アプリケーションを生成します CloudKitアプリケーションを 過去に構築した方なら― 作業前に いくつか追加すべき項目が あることをご存じでしょう 機能という項目を― Singning & Capabilitiesの タブから作成し追加します ２つの機能を追加します １つ目はiCloudの機能です Capabilityの隣のプラスを クリックして追加し― iCloudと入力し エンターキーを押します するとiCloudチェックボックスに チェックでき― プッシュ通知も追加されます XcodeはiCloud Container Identifierも自動生成し― アプリケーションで 使用可能にします 次にバックグラウンドモード機能を 追加します プラスを押し バックグラウンドと 入力し エンターを押します これで遠隔通知が 可能になり― アプリケーションの非稼働時に プッシュ通知を受信できます アプリケーションを稼働し Xcodeの成果を確認します 簡潔なビューコントローラが ２つあるアプリケーションです テーブルビューが左に ディテールビューが右にあります 右隅のプラスボタンで データを追加できます Xcodeは単純な タイムスタンプでできた― Core Dataデータモデルを デフォルトで生成します 同期機能の追加方法を ご覧ください デバイスがもう１つ必要です iPhoneのアプリケーションを 起動します マスタービューコントローラと 入力した全データが表示されています iPhoneでデータを追加します ご覧の通りiPadと同期します このコントローラのプッシュ通知で 同期がいつでも可能です もう少し分かりやすく 説明します iPadからiPhoneに追加した 上４行を全て削除します 今度はiPhoneからiPadに追加した 全データを削除します 前はプッシュ通知を使いましたが 今度はコントローラを使いません この録画動画を 再生しますので― ２つのデバイスが 同期する様子をご覧ください

ご覧の通りです Core Dataと CloudKitを使い― とても簡単にデバイスを同期する アプリケーションを構築できました もし１万5000行のコードを アプリケーションに隠したら― 皆さんは困りますよね それでは こちらをご覧ください

こちらは標準の アプリケーションデリゲートです 前にXcodeでCoreData アプリケーションを作った方は― なじみがあるでしょう Core Dataスタックを配置した このエリアを含みます 今年のアプリケーションの 唯一の違いは― CoreDataの新APIである NSPersitentCloudKitContainerです CloudKitのデータベースで 保存された― Core Dataのストアを 管理します

Xcodeでアプリケーションを 作った方は気づくでしょうが― ここに現れるのはNSPersistent CloudKitContainerの最上位の― NSPersistentContainerです これでコードを１行変更すれば Core Dataアプリケーションに― CloudKitの機能を 追加できます NSPersistentCloudKitContainerの 本質は何でしょうか？ それはCloudKitを使う デバイス同期に必要な― ごく一般的なパターンの カプセル化になります 何千ものコードを保存できます

将来はこれの上に繰り返し 構築できるようにしたい基盤です その実現には… さあ ここがポイントです 皆様の協力が必要です

NSPersistentCloudKitContainerの 使い勝手の感想が必要です アプリケーション構築に 足りない機能や― 現存の機能がニーズを 満たしているか教えてください いくつかの機能について 詳しく説明します NSPersistent CloudKitContainerは― アプリケーションにローカルの レプリカを供給します アプリケーションを保存する Core Dataまたは― CloudKitのデータベースと 完全に同一です 強力なスケジューリングと エラー回復イベントループで― アプリケーションは演算が 不要になります 最後に変換は― NSManagementObjectと CKRecord間で行われます

ローカルのレプリカは 多くの理由で重要です アプリケーションは オブジェクトで作動するので― Core Dataで管理されたローカルの ストアファイルに上書きします 同じファイルから 読み込みもします これはローカルデータベースの パフォーマンスプロファイルと― クラウドストレージの違いです ローカルのファイルにアクセスする 待ち時間ですが― 最長でもミリ秒でディスク上の ファイルを読み込めます しかしネットワーク上では データへのアクセスに― 数秒から数分かかるかも しれません 同様にローカルのストアファイルは アプリケーションに― 広い帯域幅を提供しています iPhoneでさえギガバイト毎秒が 必要になりますが― クラウドでは メガバイト毎秒か― キロバイト毎秒に 制限されています ローカルのレプリカにより必然的に データは複雑化します しかし これにより強力な スケジューリングと― エラー回復イベントループが 可能になります アプリケーションがローカルの ストアに記述する時も同じです NSPersistent CloudKitContainerが― 自動的にオブジェクトを クラウドに上げます CloudKitで変更があると― NSPersistentCloudKitContainerも システムを稼働します オブジェクトを呼び出し― ローカルにインポートし アプリケーションで利用可能にします このプロセスで― オブジェクトは 必然的に変換されます NSPersistent CloudKitContainerにより― NSManagedObjectが CKRecordとなります 同様にクラウドの更新時には― CKRecordが NSManagementObjectとして― ローカルのストアファイルに生成され 利用可能になります

これがNSPersisten CloudKitContainerの機能です CloudKitのデータベースの 完全なレプリカです しかしCore Dataとの同期のために 特定のカスタムゾーンを管理します

自動スケジューリングですので― 挙動の最適化やシステムの スケジューリングは不要です 何よりもアプリケーションの エラー回復のロジックが不要です そしてNSManagedObjectから CKRecordへの― 自動シリアライゼーションも 行われます その実行にはNSManaged ObjectModelを利用します

しかし“NSPersitent CloudKitContainerがあるから―” “アプリケーションは完璧だ” とは言えません ですから後半は― NSPersitentCloudKitContainerの 活用方法についてお話しします まずCore Dateで画期的な アプリケーションを作る方法です NSPersitentCloudKitContainerで 作った基盤を拡張し― アプリケーション構築の需要に応える 方法も後ほどお話しします Core Dataでアプリケーションを 作るには多くの知識の吸収が必要です NSPersitentCloudKitContainerの 膨大なドキュメントを用意しました アプリケーションへの実装方法も 説明しています

Core DateにはNSPersitent CloudKitContainerと― 相性の良い機能があります FetchResultsControllerでは― 大量データを保存した スケーラブルなUIを構築できます Query GenerationsはNSPersitent CloudKitContainerなどが原因の― バックグラウンドでの 更新に対しUIを安定させます 数年前に導入した 履歴追跡では― データベースの更新を 把握できます NSPersitentCloudKitContainerでは バックグラウンドの更新が― アプリケーション利用者に 必要かどうか判断できます この件は木曜の午後３時から もっと詳しくお話しします 関連する新アプリケーションの サンプルもご紹介します これはNSPersitent CloudKitContainerおよび― Core Dataの機能の使用感を 試してもらうアプリケーションです これでポストを管理します ポストは我々が構築に励んできた Core Dataでのテーマです CloudKitによる異なる オブジェクトグラフへの影響を― 確認できる 便利なオブジェクトです ご覧の通りデータモデルは とてもシンプルです タイトルとコンテンツと― 各ポストに関連する タグがあります このアプリケーションでCloudKitでの 写真管理などもイメージできます デバイスのフォトライブラリーの ファイルをポストに添付できます

NSPersitentCloudKitContainerの 利用方法をお話しします とても濃密なお話になりますが― ドキュメントに詳細が たくさん掲載されていますので 分からない点があっても 心配無用です

NSPersitentCloudKitContainerの 拡張方法はたくさんあります まずは複数のストアの 利用方法です またCloudKitで使うSchemaや NSPersitentCloudKitContainerを― カスタマイズする方も多くいます これはCloudKitがApple以外に WebサービスやJava Scriptなど― 多くのプラットフォームで 利用可能だからです ですから我々のプラットフォームを 利用していなくても― NSPersitentCloudKitContainerの オブジェクトが利用できます 最後はコラボするための Data Modelingのお話です

アプリケーションで複数のストアを 利用する場合が多くあります 特にネットワークに 保存されたストアです アプリケーションの利用が 異なる場合― 複数のストア利用で データを分離できます また多様な動作改善も 可能になります 特定の動作検証を管理する ストアファイルで― インプットを検証する時などは 別のストアを利用可能です

複数のストアではデバイス上で 頻繁に記述されるデータを― 絞り込んだり合体させたりできます デバイス自体またはアルゴリズムが 生成したデータを― 読み込む時に便利です アルゴリズム生成頻度が 高い場合― 全てを常にCloudKitに 同期させるのは大きな負担です 別のストアファイルを 工程に追加し― それを利用してデータを統合し 分析可能にしてCloudKitに上げます

これを実証しCore Dataの利便性を ご覧に入れるため― ConfigurationsというNSManaged ObjectModelの機能を活用します

こちらはサンプルの アプリケーションになります Xcodeのモデルエディタにおける NSManagedObjectModelです ポストにロケーションを 追加してみましょう ポストの生成ごとにロケーションを 記録したいのですが― ロケーションの生成頻度は とても高く― ポストがそのロケーションで 生成されない限り不要です ですからロケーションを 他のデータモデルから分離します まず左下隅のプラスをクリックして 新しいエンティティを追加します これでロケーション情報が 格納されます この場合の ロケーションは簡潔です 緯度と経度のみで 両方ともDoubleです Core Locationの フレームワークで示されます 高度や精度などを 追加しても結構です

次にこのロケーションを 他のデータから隔離します そのために新しい設定をします またプラスを押しますが 今回は長押しして― メニューを表示させ 設定を選択します この設定をCloudと呼び― 同期させる４つのエンティティを 追加します

このCloudの設定には― CloudKitと同期させたい エンティティしか存在しません 次にLocalと呼ぶ設定をします ここにロケーションの オブジェクトが格納されます

数行のコードで起動し― Core Dataはストアが格納した オブジェクトを自動的に知らせます 最上部でNSPersitent CloudKitContainerが生成されます するとNSPersitent StoreDescriptionは― NSPersitentCloudKitContainerが 管理するストアを指示します NSPersitentStoreDescriptionは local.sqliteファイルを指示し― ロケーション情報を保持します そして作成したローカルの設定に ロケーション情報を割り当てます 次にクラウドのストアを 設定します NSPersitentStoreDescriptionの インスタンスを同様に作り― cloud.sqliteに割り当てます Cloudを付与すると― ストアに格納すべきポストやタグや 添付ファイルや画像といった― エンティティだけをNSPersitent CloudKitContainerに指示します 最後にNSPersitent CloudKitContainerOptionsの― インスタンスを割り当てNSPersitent CloudKitContainerに― このストアが同期すべき iCloudコンテナIDを指示します 最後にこの２つのストアの 概要を― NSPersistent CloudKitContainerに属するｰｰ PersistenStoreDescriptionsの プロパティに割り当てます NSPersistentCloudKitContainerで 更に拡張できます すでにローカルストアと クラウドストアがあります CloudKitのデータを共有し― 複数のアプリケーションで 使う場合はどうでしょうか NSPersistentCloudKitContainerが それも処理します Core Dataの利用で― アプリケーションでは同時に 各ストアの全データを取り扱えます Core Dataは 正しいストアファイルに入れた― データを自動的に書き出します

これは３行のコードを 追加するだけで実現します 新しいStoreDescriptionは 共有したファイルを指示し― 共有と呼ぶ新規設定をします 最後にNSPersistent CloudKitContainer Optionsの― インスタンスを割り当て― 格納したい共有データを 特定します この場合はiCloud.com. wwdc.sharedになります そしてPersistentStore Descriptionsにも割り当てます 次はSchemaのお話です Schemaのいくつかの 要点をお伝えします ハイライトの１つである― CloudKitの記録を確認する時の 最重要点です 最初は記録の種類の管理方法と― NSManagedObjectModelで 作るエンティティの管理方法です 次にAsset Externalizationという 機能の実装方法です これによりNSPersisten CloudKitContainerを利用して― CloudKitの任意の大きな値 を間断なく格納できます 最後のお話は リレーションシップの管理方法です CloudKitを利用する場合と どう違うかお話しします 参考アプリケーションの ManagedObjectModelで説明します 最初はポストの エンティティについてです 属性にはタイトルとコンテンツの ２系統があります リレーションシップにも アタッチメントと― タグという ２つのエンティティがあります Core Dataはクラスを生成し このようなコードによる― NSManagedObjectの サブクラスとして利用可能です 全ての属性と関係性が クラス上に示されます これがCloudKitで生成される レコードです このポストと連動しています これはレコードを蓄積し― 完全に実体化するための 値の例です 最初に強調したいのは― レコードのIDです Core Dataには CloudKitで生成する― 全てのオブジェクトの レコードIDがあります 各レコードに 簡単なUUIDを付与し― Record Nameとします Record NameとゾーンIDの結合で― CKRecord IDとなります

最下部でCore Dataは 種別情報を管理します ２点にご注目ください まずはこの大量の“CD ”です こうしてCore Dataは 管理するデータを― CloudKitが生成したデータから 隔離します CKRecordに改変データを 追加するケースは多くあります ユーザが 追加する場合もあります 全てのレコードタイプや フィールド名を― CD にプレフィックスします しかしCD entityNameの フィールドには― このレコードのオブジェクトの 本当の名前を保持します これでEntityInheritanceという 機能が生成され― そこにポストのサブクラスが 生成されます 例えば画像のポストや 動画のポストです 実際のエンティティは― CD entityNameフィールドで 識別されます これでCKクエリが生成されます 各レコードタイプの照会で― 目的のエンティティ階層が 特定されます

次はこの２つの文字列について お話しします 長さが変更可能な フィールドですので― CloudKitへ書き換えでは 不思議な挙動を見せます

これを４つの全フィールドに 拡張しました これでアセットの外面化が 可能になります ここに CD コンテンツフィールドと― CD コンテンツフィールド CKAssetがあります これで任意の長い文字列を 格納できます キロバイトの簡素なものから― 数百メガバイトやギガバイトの 長さのものまで格納できます このレコードは完全に 実体化されていますので― この４つのフィールドを 同時に見ることはありません 文字列がとても短い場合― レコードはCD コンテンツと CD タイトルとなります もしとても大きくなり 750キロバイト以上になったり レコードの全量がCloudKitの上限の １メガバイトを越えたりする場合― アセットフィールドまたは この場合は― レコードのCD コンテンツ CKAssetが代わりに出現します レコードを ご自身で利用する場合― 値が特定の属性に設定されているか 両箇所を確認してください

次にポストの関係性を見てみます コードで使えるCore Dataが 生成したオブジェクトにおける― NSSetの両方のインスタンスが 見えます これはポストの関係性が 過剰であるためです ポストが多すぎるアタッチメントに 割り当てられることになり― 関連するタグが大量になる 可能性があります アタッチメントの関係性が いわゆるMany-to-Oneです １つのアタッチメントの関連は １つのポストだけです

これのためにコードが 生成されると― ポストにNSSetが出現します アタッチメントManagedObjectに 出現するのは― １つのポストオブジェクトだけです これがアタッチメント用に 生成されるレコードです ポストと同様にUUID エンティティ名 レコード種別を持ちますが― CD ポストという 別のフィールドも持ちます これでTwo-Oneと呼ぶ関係性を 格納します CloudKitにおける 関連レコードのUUIDは― 必ずリンクされたオブジェクトに 格納されます CKReferenceではできないのか と思うでしょうが― CKReferenceには制限があり― Core Dataのクライアントでは うまくいかないのです 全部で750のオブジェクトが 上限値です しかし このように 関係性を格納すれば― CloudKitコンテナで 随意に保持できます

次にMany-to-Manyの関係性を 見てみましょう この場合はポストと そのタグの関係性です このオブジェクトには ２つのNSSetがあります 両オブジェクトが多くの種別と 関連しているからです これらのオブジェクトのレコードが 生成されると― 関係性を保持するために実体化した フィールドはなくなります 代わりにCore Dataが カスタム結合レコードを実体化します 関連性のあるデータベースを 使う方には― この概念はおなじみでしょう 基本的には結合表の 列の外挿です CDMRまたはCore Data Mirrored Relationshipと呼ばれます CDMRは二極を持ち― リンクされた２つのオブジェクトを 記述する設計になっています この２つのオブジェクトの エンティティ名と― レコード名の記述から始めます 前述のように これはレコードIDではありません レコード名ですから ゾーンIDと結合させ― CDMRとリンクした アイデンティティを確認してください このリンク生成をしていたものと 同じ関係性のカプセル化もします

関係性の説明に 時間をかけているのは― コラボのためのデータのモデル化に 大きな影響があるからです ここで明確にしたいと思います コラボとは コンフリクトの解決ではありません コンフリクトの解決とはNSPersistent CloudKitContainerによって 自動的に実装されるものです コンフリクトを解決するには― CloudKitのグラフとデータを モデル化した方法と一貫させます しかしこの作業について 我々は長年 不満を耳にしてきました 結合の挙動の改善方法と その際に特定の顧客の― 関連性を利用したケースの 調整方法をご覧ください

これにはポストアプリケーションを 再び利用します ポストは生成しますが コンテンツには割り当てません もう１つのデバイスと 同期させるとしましょう 両方に編集を同時に加えます これを今まではコンフリクトと 呼んでいました これは２つのデバイスが １つの値に対してコラボする好例です NSPersitent CloudKitContainerが― CloudKitでの変更を 検知した場合ー ２つの値の１つを保持し これを解決します “last writer wins merge” ポリシーが適用されます コラボの素晴らしさが 伝わると思います 本当です

本当に処理できるのかと 思う方もいると思います Core Dataでは２つの文字列を どうして連結できないのかと できます しかし助言通りに 差分保存をしないと― 想像もつかない このような結果になります 文にさえなっていません

どうすればよいでしょうか 我々にもお客様にも― とても大事な問題です ポストエンティティに 改善策はないか見てみます

まずは平坦な値の衝突を 中止します コンテンツは 平坦な文字列ですので― 文字列を見ても期待する文字列の 結合挙動を推論できません しかし関係性として 分解してみると― 複数のデバイスは自ら コンテンツフィールドに寄与します Two-Oneの関係性の 格納により― 多くのデバイスで同時に オブジェクトに貢献できます ポストオブジェクトの衝突は 起こりません よって簡潔な文字列のポストコンテンツ エンティティに分解しました Two-Oneの関係性の格納により デバイス自体が関係性を結合します 最終値をコンパイルするために 関係性を横断させます これが最終的な一貫性です 両デバイスが ポストコンテンツを寄与し― 他方のデバイスから ポストコンテンツをダウンロードします これを連結または結合 または任意のトポロジーで― 最終値をアセンブルします しかしどんなデバイスでも 同じ状態を望みます しかしダウンロード指令が 違えば― 最終値も違ってきます 日にちのような平凡な 指令をしてみます Core Dataのソートディスクリプタ による連結の前に― ポストコンテンツオブジェクトを 指令できます 一貫した指令と結合挙動を 全デバイスに出します 分散型データ処理システムおたくな 私にも時間は容赦ありません 実際にデバイスの時間認識は 一緒に並んでいても揃いません 一歩踏み込んで完全な ツリーを構築します 元の貢献に対して関係性を 活用して― 実際の貢献をしているデバイスの 情報をエンティティに付与します コンフリクトしない複製可能なデータの 青写真ができました これはコンピュータ科学の 卓越した新分野で― アルゴリズムを活用して 一貫した結合挙動を― ユーザ間の様々な状況で 創出できます

以上がCore DataとCloudKitの 併用についての説明でした NSPersistent CloudKitContainerを使えば― 簡単に同期機能を アプリケーションに組み込めます 今年は他に素晴らしい サンプルコードや資料もあります これらの新しいAPIとともに 大いにお楽しみ頂けると思います 最後に皆様がNSPersistent CloudKitContainerを使って― 何を作り いかに拡張していくかを 大いに期待しています 今年は多くのラボを開催しています 今週も毎日です 木曜日の３時に― Core Dataの更なる機能について トークをします

ありがとうございました 有意義なWWDCでありますように (拍手)