iOSアプリの一部のデータをローカルの.sqliteファイルに直接保存します。データはApple以外のプラットフォームと互換性がある必要があるため、CoreDataの代わりにこれを行うことにしました。
今、私はこのファイルをiCloud経由で同期するための最良の方法を考え出そうとしています。多くの理由で、直接同期できないことはわかっています。CoreDataがDBを同期できることは知っていますが、CDを使用すると本質的にこのファイルがAppleプラットフォームにロックされることを無視しても（CDを少し調べただけだと思います）、このファイルのiCloud同期が機能する必要がありますiCloudでサポートされているすべてのプラットフォーム-これにはWindowsが含まれているはずです。WindowsAPIのCoreDataファイルには互換性がないと想定する必要があります。これを達成するための最良の方法を計画することは、Appleが「WindowsAPIが[最終的には？]」以上のことを私たちに教えてくれれば、はるかに簡単になるでしょう。
さらに、iCloudがサポートしていないプラットフォームをサポートするには、最終的に少なくとももう1つの同期サービスを実装する必要があります。私がiCloudに使用している方法が、将来のサービスでほとんど再利用できるのであれば、必須ではありませんが、役に立ちます。
これらの理由から、CoreDataがこれを支援することはできないと思います。私はこれを考えるのは正しいですか？
そこから先に進むと、このためのアルゴリズムを考案するか、既存のアルゴリズムまたは既存のサードパーティソリューションを見つける必要があります。私はまだ何にも遭遇していません。しかし、私は実装できるいくつかの可能な方法を検討してきました。
方法1：
CoreDataがsqliteDBを同期する方法と同様のことを行います。代わりに、「トランザクションログ」をiCloudに送信し、それらから各ローカルsqliteファイルを構築します。
各デバイスは、そのデバイスが実行したすべてのSQLコマンドをタイムスタンプとともにリストした（一意の名前の）テキストファイルを送信すると思います。デバイスは、実行したコマンドの各リストにどれだけ進んだかを保存し、ファイルが更新されるたびにその時点から続行します。一度に複数のログファイルの更新を受信した場合、タイムスタンプ順に各コマンドを実行します。
これらのファイルが大きくなると、効率的に「興味深い」ものになる可能性がありますが、それは解決可能な問題のようです。
方法2：
作業中のデータベースのコピーを定期的にiCloudに同期します。すべてのレコードに変更タイムスタンプフィールドがあります。DBの更新されたコピーが届いたら、ある参照時間よりも新しいタイムスタンプを持つすべてのレコードをクエリし、新しいデータからローカルDBのレコードを更新します。
この方法には多くの潜在的な問題があります。
-レコードの削除を認識するために、さらに何かを実装する必要があります。
-DBファイルが競合する可能性があります。各競合バージョンをタイムスタンプ順に処理することで、それらに対処できる可能性があります。
-更新元のデバイスによって異なるため、各更新を確認する日付を決定するのは難しい場合があります。
方法2には多くの潜在的な問題がありますが、方法1は私には実行可能のようです...
誰かが最善の行動方針について何か提案がありますか？私の「方法1」（またはそれが機能しない理由）よりも優れたアイデアはありますか？