2016-05-05 8 views
4

私の質問は、WWDC 2014 Advanced CloudKitに名前が付けられているので、「Delta Download」に関するものです。CloudKit:CKFetchRecordChangesOperation、CKServerChangeToken、Deltaダウンロード

私はコアデータアプリケーションの同期化を試みています。これは現在のところiPhoneのみです(1つのデバイスしかアクティブではないと思います)。つまり、基本的には、今のところほとんどの場合、同じデバイスのクラウドにユーザーレコードを格納します。

CKFetchRecordChangesOperation別名デルタダウンロードに基づくカスタムゾーン機能の理解に問題があります。

WWDCで提示されているように、同期操作(私は別のデバイスによって追加/変更/削除されたレコードのみをダウンロードすることを意味します)を維持するために、CKServerChangeTokenを持っています。 しかし、私が理解できないのは、CKFetchRecordChangesOperationの後にのみトークンを受け取るということです。レコードをクラウドに保存すると、新しいトークンが取得されません。

そして、現在の使用可能なトークンをフェッチした場合(フェッチ後に変更されるため)、前回の保存操作で保存されたレコードを受け取ります。基本的には、私たちのデバイス上にすでに存在するレコードを保存します。どうして?私はここに何かを逃している?

クラウドに(デバイスAから)いくつかのデータをシードすると、デバイスBがゾーンレコードを取得しているときの状況は正当ですが、デバイスAがあればどうなりますか?すべてのレコードを再度ダウンロードしますか?

CKRecordrecordChangeTagが見つかりました。これはローカルオブジェクトとの競合を解決するために使用できるプロパティです(フェッチされたオブジェクト(同じまたは異なるバージョン))。もしそうなら、私はこれをどうやって行う必要があるかの例を教えてください。 RecordChangeTagをコアデータに初めて記録するとCloudKitにレコードが保存されるか?

文書の欠如はそのような頭痛です。

+1

私は実際にこの問題についてAppleにサポートケースを開いた。 'CKFetchRecordChangesOperation'を使ってデバイスからの変更についてデバイスに通知するのは意味がありません。私は平らに言われました - そうです。だからあなたのコードは、これらの重複レコードの変更をすべて処理する必要があります。 – rmaddy

+0

@rmaddyああ、この情報をありがとう。あなたがそれを答えとして書くと、私はそれを受け入れます。なぜなら、他の答えはなく、あなたは最も近いものですからです。 –

+0

@rmaddyリンゴのdevforum Rickに関するディスカッションを読んで、私はあなたに聞きたいのですが、PBKが提案した回避策を試しましたか?ディスカッションへのリンク:https://forums.developer.apple.com/message/77233#77233 –

答えて

3

私はこの質問の答えを書く時間を見つけました。私は実装を掘り下げませんが、私はそのコンセプトについて話します。

CloudKitは、お使いのデバイスとCloudKitサーバー間のデータ同期を実現します。 私の場合、iPhoneとiPadの間で私の場合、同期プロセスを確立するために使用するのは何ですか(iPhone + iPadアプリをお持ちの場合は、さらに多くの手順が必要です)。

プライベートクラウドデータベースにカスタムゾーンがあります。 私は、互いに依存する異なる非同期プロセスを確立するためにOperationQueueを使用します。一部の操作には、独自の操作キューがあります。

ステップ:

1)は、カスタムゾーン

1.2が存在しない場合は、私のカスタムゾーンが)

1.1を存在しているかどうかを確認してください)新しいカスタムゾーンを作成します。 (オプション:レコードの追加)

トークン

1.3)リフレッシュゾーンの変更あなたは、ゾーンの変更トークンをリフレッシュすることができます実行 CKFetchRecordChangesOperationfetchRecordChangesCompletionBlock戻りCKServerChangeToken )NSKeyedArchiverを使用して)例えば(UserDefaultsに保存。この操作のタスクは、トークンをリフレッシュすることであり、終了同期プロセスで実行されます。

2)カスタムゾーンがすでに

2.1がある場合)以前に保存されたゾーンの変更トークンを使用してゾーンから変更を取得します。 (CKFetchRecordChangesOperation

2.2)ローカルレコードを更新および削除します。

2.3)リフレッシュゾーン変更トークン。

2.4)ローカルの変更を確認してください(最後のクラウド同期タイムスタンプを使用して、後で変更されたレコードを確認しています)。

2.5)トークンを再度クラウドキットデータベース

2.6)リフレッシュゾーンの変更にレコードをアップロードします。

私は非常にニック・ハリスの記事シリーズをお勧めします:https://nickharris.wordpress.com/2016/02/09/cloudkit-core-data-nsoperations-introduction/

あなたがそこに実装し、デザインコンセプトを見つけることができます。それは読む価値がある。私は誰かがこのすべてが役に立つと思うことを願っています。

+0

これを書いていただきありがとうございます!それは同じ問題で私を助けてくれました。アップルのWWDCのビデオとドキュメンテーションは、この問題を明確にしたり警告したりすることはありません。彼らはCloudKitを神の送信フレームワークとして販売していますが、多くの行き詰まりや悪夢があります。 – lostAtSeaJoshua

+0

CoreDataをローカルストレージとして使用する場合、この問題を解決するためのもう1つの方法は、 'CKFetchRecordChangesOperation'のために送られたすべての'変更されたレコード 'でフェッチ要求を行うことができるということです。 'recordChangeTag'を比較することに基づいてレコードをフィルタリングします。したがって、同じレコードが返されても、フィルタリングされて実際の変更を処理します。 – lostAtSeaJoshua

+0

@lostAtSeaJoshuaあなたは正しいですが、CloudKitキットには良い機会がありますが、iCloudとのコアデータの同期化など、いくつかのトピックに関するドキュメントが欠けています...(それは問題ありませんが)フィルタリングについては、レコードの検証が必要です。しかし、わかりましたが、 'CKFetchRecordChangesOperation'は既に廃止されています... https://developer.apple.com/reference/cloudkit/ckfetchrecordchangesoperation –

関連する問題