CKSyncEngineでiCloudに同期

CKSyncEngineでiCloudに同期

CKSyncEngineを使用して、人々のCloudKitデータをiCloudに同期する方法を紹介します。同期操作のスケジューリングをシステムに任せることで、アプリのコード量を削減する方法を学びます。CloudKitの進化に合わせて強化されたパフォーマンスの恩恵を自動的に受ける方法、同期実装のテストなどをご紹介します。このセッションを最大限に活用するには、CloudKitとCKRecordタイプに精通している必要があります。

関連する章
- 0:00 - Intro
- 0:48 - The state of sync
- 3:09 - Meet CKSyncEngine
- 9:47 - Getting started
- 13:18 - Using CKSyncEngine
- 19:25 - Testing and debugging
- 22:27 - Wrap-up
リソース
関連ビデオ

Tech Talks
- CloudKit共有の最大限の活用
ダウンロード

♪ ♪
こんにちは CloudKitチームのエンジニアTimです同僚のAamerと私は CKSyncEngineという新しいCloudKit APIについて話していきます CKSyncEngineはデバイスとクラウド間のデータ同期を支援するために設計されていますまずAppleプラットフォームでの CloudKitへの同期状況について話します次にCKSyncEngineがどのようなものでどのように動作するのかについて説明しプロジェクトから CKSyncEngineを使い始める方法について学びますセットアップが完了したらデバイス間でデータを同期化する同期エンジンの使い方を学びます最後にCKSyncEngine との統合をテストまたはデバッグするためのベストプラクティスについて知識を深めていきますまずCloudKitとのシンク状況について
新しいアプリを作るとユーザーは自分のデータが同期されることを期待します iPhoneで何かを作りMacを開くとそこにもそれがあるものだと思います外からだと　これはまるで魔法のようですユーザデータは一ヶ所場所だけでなくあちこちにあります簡単なことではないです CloudKit自体はそれほど複雑ではないが同期全般は難しいのです複数のデバイスをシナリオに持ち込む場合うまくいかないことがたくさんありますだから同期コードはシンプルであればあるほど好ましいのです同期コードを簡素化する最善の方法はできるだけ記述を少なくすることですありがたいことにCloudKit と同期化の素晴らしい API の選択肢がいくつかあり　これらのAPIが多くの重要な作業を代行してくれますローカル永続化を含むフルスタック・ソリューションが必要な場合は NSPersistentCloudKitコンテナを使えます独自のローカル永続化を行いたい場合は新しい CKSyncEngine API を使用できますなおよりきめ細かい制御が必要だと感じたらCKDatabaseと CKOperationsを使いましょうしかしCloudKitと同期したい場合や NSPersistentCloudKitContainerを使用していない場合は CKSyncEngineを使用する必要があります同期には多くの可動部分があり CKSyncEngineのような APIを使用することで複雑さを軽減し高レベルのアプリの同期エクスペリエンスを向上させます
シンクの核心はほとんどの場合あるデバイスから変更を送信し別のデバイスでそれをフェッチし必要に応じてCloudKitのレコードとの間で変換しますそれだけなら簡単かもしれませんがするべきことはそれだけではありませんさまざまな操作やエラーシステム状態の監視アカウント変更リッスンプッシュ通知の処理サブスクリプションの管理と追跡などすべてを学ぶ必要があります CKSyncEngineを使えば書かなければならない同期のためのコード量はずっと少なくなってより集中できるようになるでしょうアプリに特有なことだけを処理するだけで残りは同期エンジンが処理してくれます適切な同期エンジンを書くにはおそらく数千行のコードが必要でテストではその倍が必要になり実はNSPersistentCloudKitContainer CKSyncEngineにもかなり多くのテストがあるという噂を聞きましたこのソフトが多くのことを処理してくれるからです CKSyncEngineにもかなり多くのテストがあるこの新しいCKSyncEngine APIとは何でしょうか？
CKSyncEngine は CloudKitデータベースと同期するための共通ロジックをカプセル化します便利なAPIを提供しつつ必要に応じて柔軟性を持たせることを目指していますカスタム同期エンジンを書くようなほとんどのアプリのニーズを満たすように設計されています一般的にアプリのプライベートデータや共有データを同期させるなら CKSyncEngineが最適です同期エンジンで使用するデータモデルはレコードとゾーンで構成されこれらはCloudKitの他の部分で使用されるのと同じデータタイプです既存のCloudKit APIを使用してこれらのデータにアクセスできますこのため既存のCloudKit同期実装がある場合は CKSyncEngineはそれと同期することができますこの同期エンジンはFreeformアプリを含むシステム全体のいくつかのアプリやサービスで使用されていますもう一つの例は同期エンジンの上で書き直された NSUbiquitousKeyValueStoreですこれは後方互換性のある使用例です新しいOSでは同期エンジンを使用しますが以前のバージョンとも同期しますすでにカスタムCloudKit同期実装を持っている場合は CKSyncEngineに切り替えるオプションがありますこのメリットが気に入れば乗り換えを検討すべきですが必須ではありません時にはメンテナンスするコードが少なくてすむのは便利です CKSyncEngineに新しい機能が追加されるたびにメリットを受けられますプラットフォームが進化すれば同期エンジンも進化しより簡単で効率的な同期が可能になります CKSyncEngineのAPIサーフェスが小さいというメリットもありますこれで特定のデータモデルとユースケースに集中できるます CKSyncEngineの使用を検討しているがサポートされていない特別なニーズがある場合はいつでも自分で構築することができますただしCKSyncEngine の新機能によってニーズが満たされると思われる場合ユースケースを添えてフィードバックを提出してください結局のところ　同期エンジンの最高のアイデアのいくつかは、あなたのようなデベロッパから生まれたものなのですでは同期エンジンは実際にどのように機能するのか？一般的に同期エンジンはアプリとCloudKit サーバー間のデータのパイプとして機能しますアプリは同期エンジンと通信します保存すべき変更があるとアプリはそれを同期エンジンに伝えます他のデバイスでこれらの変更を取得するとそれらをあなたのアプリに提供しますそれでも同期エンジンが仕事を抱えている場合必ずしもすぐにそれを実行するとは限りませんサーバーと通信する必要がある場合はシステムのタスクスケジューラと相談しますこれはバックグラウンドタスク管理に OS全体で使われているのと同じスケジューラーでデバイスがデバイスが同期できる状態にあることを確認しますデバイスの準備が整うとスケジューラーがタスクを実行し同期エンジンがサーバーと通信しますこれが同期エンジンの基本的な動作の流れです具体的にそのように同期エンジンが変更をサーバーに送るのでしょうかまず誰かがデータに変更を加え何かをタイプしたかスイッチを入れましたのかまたは何かを削除したかアプリは保留中の変更を同期エンジンに伝えサーバーに送信することを同期エンジンに指示します次に、同期エンジンはタスクをスケジューラに送信しますデバイスの準備ができたらスケジューラはタスクを実行タスクが実行されると同期エンジンは変更をサーバーに送信するプロセスを開始しますそのためにアプリに次の変更の送信を要求するしますもし誰かが1つだけ変更を加えた場合保留中の変更は1つだけかもしれませんしかし誰かが新しいデータの巨大なデータベースをインポートした場合何百何千もの変更があるかもしれません 1回のリクエストでサーバーに送信できる量には限りがあるからです同期エンジンはこれらの変更を一括して要求しますこれで実際に必要になるまでレコードをメモリに取り込まないことによりメモリのオーバーヘッドを減らすのにも役立ちます次のバッチを提供した後同期エンジンはそれをサーバーに送信しますサーバーは変更の成否に関する情報を含め操作の結果を応答しますリクエストが終了すると　同期エンジンは結果をアプリにコールバックしますこれは作戦の成否に反応するチャンスです保留中の変更がある場合同期エンジンは送信するものがなくなるまでバッチを要求し続けますあるデバイスがデータをサーバーに送信すると他のデバイスがそのデータを取得しますサーバーが新しい変更を受信するとそのデータにアクセスできる他のデバイスにプッシュ通信します CKSyncEngineはアプリでこれらのプッシュ通知を自動的にリッスンします通知を受け取るとタスクをスケジューラに投入しますスケジューラタスクが実行されると同期エンジンがサーバーからフェッチします新しい変更を取得するとアプリに送りますこれらの変更をローカルに保持し UIに表示するチャンスですこれが同期エンジンを使う際の基本的な操作の流れとなりますこれらのフローに共通しているのはシステムのスケジューラーです通常CKSyncEngineは何かをする前にスケジューラを参照しますこのように自動的に同期されるのです
スケジューラはネットワーク接続性　バッテリー残量リソースの使用状況などを監視します同期を試みる前に　デバイスが前提条件を満たしていることを確認しますスケジューラを尊重することで同期エンジンはユーザー体験とデバイス・リソースの適切なバランスを確保することができます通常のコンディションであれば同期はかなり速く通常は数秒かそこらで完了しますしかしネットワーク接続がない場合またはデバイスのバッテリー残量が少ない場合同期が遅れたり延期されたりすることがありますデバイスに大きな負荷がかかっている場合同期メカニズムがアプリ内の他の緊急タスクの邪魔になることは避けたいです同期エンジンの自動スケジューリングに頼ることでシンクすることができますより効率的なだけでなく使いやすくなりました同期するタイミングを気にする必要がなければ他のことに集中できます引き直して更新するUIがあるかもしれませんまたは今すぐバックアップボタンがあれば保留中の変更を即座にサーバーに送信できるかもしれません手動で同期することは自動テストを書くときにも役に立ちますイベントの順序を制御する必要がある場合複数のデバイスに特定の同期シナリオをシミュレートするのに役立ちます一般的には自動同期スケジューリングに頼ることをおすすめしますしかし手動で同期する有効なユースケースがあることは理解していますし同期エンジンは必要に応じてそれを行うためのAPIを備えていますこれからAamerがCKSyncEngineの使い始め方について話してくれます Tim 紹介ありがとう CloudKitクライアント・チームのエンジニアの Aamerですこれから CKSyncEngineについて説明します CKSyncEngineを使用する前にプロジェクトをセットアップするために必要なことがいくつかありますこれらの要件はCKSyncEngineを使用する場合でも独自のCloudKit実装を構築する場合でも同じですまずCloudKitの基本的なデータ型である CKRecordとCKRecordZoneの基本的な知識が必要です同期エンジンのAPIはレコードとゾーンを多用するのでその意味をよく理解してから使いましょう次にXcodeでプロジェクトのCloudKit 機能を有効にする必要があります最後に同期エンジンはプッシュ通知に依存していて最新の状態を保つためにリモート通知機能を有効にする必要がありますこれができたら同期エンジンを初期化しますまずCKSyncEngineを初期化する必要があります同期エンジンを初期化すると自動的にプッシュ通知とスケジューラタスクをバックグラウンドで受信しはじめますこれらの通知やタスクはいつでも発生する可能性がありそれらを処理するために同期エンジンを初期化する必要があります
アプリとCKSyncEngineの間の主な通信手段は CKSyncEngineDelegate と呼ばれるプロトコルです同期エンジンを初期化する際にはこのプロトコルに準拠したオブジェクトを提供する必要があります適切かつ効率的に機能するために同期エンジンはいくつかの内部状態を追跡しますまた同期エンジンの状態や既知のバージョンを提供する必要があります
同期操作を行っている間デリゲートには時々状態更新イベントという形でこの状態の更新版が渡されます同期エンジンが新しい状態を連続化するたびにそれをローカルに永続化する必要がありますこうすることで次にプロセスを起動し同期エンジンを初期化するときにこの情報が提供されるようになりますこれを理解するためにいくつかのコード例を使って説明しましょう
同期エンジンを初期化するには設定オブジェクトを指定し同期したいデータベースと同期エンジンの状態の最終バージョンを指定する必要がありますデリゲート・プロトコルの関数のひとつに handle event関数がありますこの機能は通常の同期操作中に発生する様々なイベントを同期エンジンがアプリに通知する方法です例えばサーバーから新しいデータを取得したりアカウントが変更されたときにイベントを投稿しますこれらのイベントのひとつに状態更新イベントというものがあります同期エンジンが内部状態を更新したときまたはあなた自身が状態を更新したとき同期エンジンは状態更新イベントをポストしますこのイベントに応答してこの新しい連続化されたバージョンの状態をローカルに永続化しなければなりませんこの例では次に同期エンジンを初期化するときにこの状態のシリアライズを使用しますこれで土台は整ったので同期エンジンを使った同期について説明します
サーバーに変更を送信するにはいくつかの簡単な手順がありますまず保留中のレコードゾーンの変更と保留中のデータベースの変更を同期エンジンの状態に追加しますこれは同期エンジンにシンクをスケジュールするよう警告します同期エンジンは一貫性を確保しこれらの変更を重複排除します
次にデリゲートメソッドを実装同期エンジンは次のレコードゾーン変更のバッチを取得するためにデリゲートメソッドを呼び出しサーバーに送信します最後にイベント sentDatabaseChanges と sentRecordZoneChanges を処理しますこれらのイベントは変更がサーバーに送られると投稿されます
サーバーに変更を送信する例ですこのアプリケーションはデータを編集し新しいレコードの変更を同期しようとしてますそのためには同期エンジンにそのレコードを保存する必要があることを伝え保留中のレコードゾーンの変更を同期エンジンの状態に追加します同期エンジンがレコードをシンクする準備のできたところでデリゲートメソッドを呼び出しますサーバーに送信する次の変更バッチを返しますレコードゾーン変更バッチを初期化するには保留中の変更のリストとレコードプロバイダを提供することで初期化します保留中の変更のリストには保存または削除するレコードIDと実際の同期が行われるときにそれらのIDをレコードにマッピングするレコードプロバイダが含まれていますアプリがサーバーから変更を取得する方法を説明していきます同期エンジンが自動的にサーバーから変更を取得しますそうしてフェッチされたDatabaseChangesと fetchedRecordZoneChangesのイベントが投稿されますユースケースによってはFetchChangesと didFetchChangesのイベントをリッスンしたいかもしれません例えばこれらのイベントをハンドリングすることは変更をフェッチする前後にセットアップやクリーンアップのタスクを実行したい場合に便利です以下はアプリがサーバーから変更をフェッチする例です同期エンジンがレコードゾーン内の変更をフェッチするとイベントを投稿しますこのイベントには他のデバイスによって実行された変更と削除が含まれますこれをリッスンする際にはフェッチされた変更とフェッチされた削除をチェックする必要があります修正を受けたらデータをローカルに永続化する必要があります削除を受けたらローカルでデータを削除してくださいデータベースの変更をフェッチするのもよく似ていて同じアプローチで処理できますエラーの処理は厄介です同期エンジンがこれに役立ちます同期エンジンはネットワークの問題スロットリングアカウントの問題などの一時的なエラーを自動的に処理します同期エンジンはこれらのエラーの影響を受けた作業を自動的に再試行しますその他のエラーについてはアプリが処理する必要がありますこれらのエラーを解決したら必要に応じ仕事のスケジュールを変更する必要があります
これはレコードゾーンの変更を送信する際のエラーハンドリングの例です sentRecordZoneChangesイベントが投稿されたら failedRecordSavesをチェックして
保存に失敗したレコードがあるかどうかを確認する必要がありますこれはアプリがまだ取得していない新しいバージョンを別のデバイスが保存したということですコンフリクトを解決し作業を再スケジュールしなければなりません
zoneNotFoundはまだサーバに存在しないことを示しますこれを解決するにはゾーンを作成し作業を再スケジュールする必要があるかもしれません同期エンジンは常に最初にゾーンの保存を試み次にnetworkFailure networkUnavailable serviceUnavailable そしてrequestRateLimitedは一過性のエラーの例ですこのようなエラーが表示されることはありますがそれに対してアクションを起こす必要はありません同期エンジンはシステム状況が許す限りこれらのエラーに対して自動的に再試行します
もうひとつ同期エンジンが役立つのはアカウントの変更です iCloudアカウントの変更はデバイス上でいつでも発生する可能性があります同期エンジンはこれらをサポートします同期エンジンは変更をリッスンしサインイン　サインアウトまたはアカウントが切り替わったことを accountChange イベントで通知しますアプリはタイプに応じて変更に対応する必要があります
同期エンジンはデバイスにアカウントが存在するまで iCloudとの同期を開始しません
同期エンジンはいつでも初期化できアカウントに変更があった場合は自動的に更新されます他のユーザーとデータを共有するのは CloudKitの重要な部分です同期エンジンはここでも生活を楽にしてくれます同期エンジンは CloudKit 共有データベースで動作しますアプリで使用するデータベースごとに同期エンジンを作成するだけですたとえばプライベートデータベース用に同期エンジンを作成し共有データベース用に別の同期エンジンを作成することができます CloudKitによる共有の詳細については Tech Talk「Get the most out of CloudKit Sharing」をご覧ください。
これはCKSyncEngineを使用することをカバーしていますではそれを使う際のテスト方法について説明していきましょう自動テストは迅速な開発を行いながらコードベースの安定性を確保する最良の方法です同期エンジンを使用すると複数の CKSyncEngineインスタンスを使用してデバイス間のユーザーフローをシミュレートできます
アプリが遭遇する可能性のあるエッジケースをシミュレートする必要がありますこれを行うには同期エンジンのフローに介入して automaticallySyncを無効に設定します以下は2つのデバイスとサーバー間のデータ競合をシミュレートしたテストケースですこのテストの目的は複数のデバイスを操作する際にユーザーが取るであろう完全なフローをシミュレートすることにあります競合解決も有効ですまずMySyncManagerを使って 2つのデバイスをシミュレートしますこの例ではMySyncManagerがローカルデータベースと同期エンジンを作成しますデバイスAは値をAに設定しその変更をサーバーに送信
デバイスBがサーバーから変更をフェッチする前にその変更をサーバーにも送るように要求しますデバイスAが先にサーバーに保存したためデバイスBの保存は失敗すると考えられますこの結果サーバーのレコードが変更されたエラーが発生しローカルの競合解決コードが実行されますこのサンプルでは競合解消がサーバーからのデータを優先することを期待しているためデバイスBの新しい値はデバイスAからサーバーに送信された直近の値になります
テストとデバッグのスピードアップに役立つポイントをいくつか紹介していきましょう各デバイスでの一連のイベントを理解することはアプリケーションのフローのどこで問題が発生しているかを特定するのに役立ちます開発時に可能な限りログを取ることはこれらのフローをトレースし複数のデバイス間でログを比較するのに役立ちます CloudKitは受信した各イベントをログに記録しますがアプリ内でイベントに関連するアクションもレコードIDとゾーンIDをログに記録することで
同期エンジン　サーバーそしてシンクしている他のデバイスの間でどのようなデータが流れているかをデバッグできるようになります
それぞれのユーザーフローをシミュレートするテストを書くことでコードベースが大きくなっても安定性を保つことができます
パズルをつなぎ合わせ謎を解くように同期オペレーションは数回しか行われないかもしれないし短時間に何度も行われるかもしれない正しいトレースができているかどうかを確認することは複数のデバイス間でデバッグを行う際の鍵となります
これらの手順はCKSyncEngineを使用して信頼性が高く長持ちするアプリを作成し維持するのに役立ちます
これでCKSyncEngineについての話を終わります同期エンジンのサンプルコードでアプリでの完全な動作例を参考にしてくださいさらに詳しく知りたい場合は CKSyncEngineのドキュメントを確認して同期エンジンを改善するための提案があるならば CloudKitチームにフィードバックを送ってください私たちはどんな作品ができるのか楽しみにしていますご視聴ありがとうございました素晴らしいWWDCを！ ♪ ♪

actor MySyncManager : CKSyncEngineDelegate {
    
    init(container: CKContainer, localPersistence: MyLocalPersistence) {
        let configuration = CKSyncEngine.Configuration(
            database: container.privateCloudDatabase,
            stateSerialization: localPersistence.lastKnownSyncEngineState,
            delegate: self
        )
        self.syncEngine = CKSyncEngine(configuration)
    }
    
    func handleEvent(_ event: CKSyncEngine.Event, syncEngine: CKSyncEngine) async {
        switch event {
        case .stateUpdate(let stateUpdate):
            self.localPersistence.lastKnownSyncEngineState = stateUpdate.stateSerialization
        }
    }
}

14:13 - Sending changes to the server

func userDidEditData(recordID: CKRecord.ID) {
    // Tell the sync engine we need to send this data to the server.
    self.syncEngine.state.add(pendingRecordZoneChanges: [ .save(recordID) ])
}

func nextRecordZoneChangeBatch(
    _ context: CKSyncEngine.SendChangesContext, 
    syncEngine: CKSyncEngine
) async -> CKSyncEngine.RecordZoneChangeBatch? {

    let changes = syncEngine.state.pendingRecordZoneChanges.filter { 
        context.options.zoneIDs.contains($0.recordID.zoneID) 
    }

    return await CKSyncEngine.RecordZoneChangeBatch(pendingChanges: changes) { recordID in
        self.recordToSave(for: recordID)
    }
}

15:40 - Fetching changes from the server

func handleEvent(_ event: CKSyncEngine.Event, syncEngine: CKSyncEngine) async {
    switch event {
        
    case .fetchedRecordZoneChanges(let recordZoneChanges):
        for modifications in recordZoneChanges.modifications {
            // Persist the fetched modification locally
        }

        for deletions in recordZoneChanges.deletions {
            // Remove the deleted data locally
        }

    case .fetchedDatabaseChanges(let databaseChanges):      
        for modifications in databaseChanges.modifications {
            // Persist the fetched modification locally
        }
      
        for deletions in databaseChanges.deletions { 
            // Remove the deleted data locally
        }

    // Perform any setup/cleanup necessary
    case .willFetchChanges, .didFetchChanges:
        break
      
    case .sentRecordZoneChanges(let sentChanges):

        for failedSave in sentChanges.failedRecordSaves {
            let recordID = failedSave.record.recordID

            switch failedSave.error.code {

            case .serverRecordChanged:
                if let serverRecord = failedSave.error.serverRecord {
                    // Merge server record into local data
                    syncEngine.state.add(pendingRecordZoneChanges: [ .save(recordID) ])
                }
            
            case .zoneNotFound: 
                // Tried to save a record, but the zone doesn't exist yet.
                syncEngine.state.add(pendingDatabaseChanges: [ .save(recordID.zoneID) ])
                syncEngine.state.add(pendingRecordZoneChanges: [ .save(recordID) ])
             
            // CKSyncEngine will automatically handle these errors
            case .networkFailure, .networkUnavailable, .serviceUnavailable, .requestRateLimited:
                break
              
            // An unknown error occurred
            default:
                break
            }
        }
      
    case .accountChange(let event):
        switch event.changeType {

        // Prepare for new user
        case .signIn:
            break
          
        // Delete local data
        case .signOut:
            break
          
        // Delete local data and prepare for new user
        case .switchAccounts: 
            break
        }
    }
}

18:49 - Using CKSyncEngine with private and shared databases

let databases = [ container.privateCloudDatabase, container.sharedCloudDatabase ]

let syncEngines = databases.map {
    var configuration = CKSyncEngine.Configuration(
        database: $0,
        stateSerialization: lastKnownSyncEngineState($0.databaseScope),
        delegate: self
    )
    return CKSyncEngine(configuration)
}

20:00 - Testing CKSyncEngine integration

func testSyncConflict() async throws {
    
    // Create two local databases to simulate two devices.
    let deviceA = MySyncManager()
    let deviceB = MySyncManager()
    
    // Save a value from the first device to the server.
    deviceA.value = "A"
    try await deviceA.syncEngine.sendChanges()
    
    // Try to save the value from the second device before it fetches changes.
    // The record save should fail with a conflict that includes the current server record.
    // In this example, we expect the value from the server to win.
    deviceB.value = "B"
    XCTAssertThrows(try await deviceB.syncEngine.sendChanges())
    XCTAssertEqual(deviceB.value, "A")
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

関連する章

リソース

関連ビデオ

Tech Talks