7

私は、サーバー (XML、JSON など) からデータを取得する通常の iPhone アプリに取り組んでおり、同期データを実装する最良の方法は何か疑問に思っています。基準は、速度 (ネットワーク データ交換が少ない)、堅牢性 (更新が失敗した場合のデータ回復)、オフライン アクセス、および柔軟性 (新しい列のように、データベースの構造がわずかに変更された場合に適応可能) です。アプリによって異なることは承知していますが、戦略や経験を共有していただけますか?

私の場合、次のようなことを考えています。

1) 最終更新日をiPhoneに保存する

2) 起動時に、getNewData.php?lastModifiedDate=... のようなメッセージを送信します。

3) サーバーは、前回から変更されたデータのみを処理して送り返します。

4) このデータは次のようにフォーマットされています。

<+><data id="..."></data></+> // add this to SQLite/CoreData

<-><data id="..."></data></-> // remove this

<%><data id="..."><attribute>newValue</attribute></data></%> // new modified value

<+>、<->、<%>... を各属性に対しても作成したくないのは、複雑すぎるためです。おそらく <%> フィールドを受け取ったときに、データを削除するだけです指定された id を使用して、再度追加します (ここでの id は、自動的に自動インクリメントされるフィールドではないと仮定します)。

5) すべてをダウンロードして更新したら、[最終更新日] フィールドを更新します。

この戦略の主な問題は、何かを更新しているときにネットワークがダウンした場合 => 最終更新日がまだ更新されていない => 次回アプリを再起動したときに、同じことをもう一度繰り返さなければならないことです。矛盾する可能性のあるデータは言うまでもありません。更新に一時テーブルを使用してすべてをアトミックにすればうまくいきますが、更新が長すぎる (大量のデータ変更) 場合、ユーザーは新しいデータが利用可能になるまで長時間待たなければなりません。各データ フィールドに Last-Modified-Date を使用し、データを徐々に更新する必要がありますか?

4

3 に答える 3

2

更新ルーチンをアトミックにすることから始めます。クライアントとサーバーの通信を適切に機能させる方法を理解するのに十分な量があるからです。

その後、インクリメンタルに微調整することを検討するのに良い時期ですが、それが本当に必要かどうかを判断するためにいくつかのテストを行った後でのみです. 更新プロトコルを可能な限り低帯域幅になるように調整している場合、「大きな」更新でも十分な速さでダウンロードされることに気付くかもしれません。

それを調べる別の方法は、平均的なユーザーが同期を行っているときに、どのくらいの頻度でネットワークの問題が発生するかを自問することです。おそらく、ありそうもないシナリオに合わせて調整する必要はありません。

XML はかなり冗長であるため、データ転送を最適化 (最小化) しようとしている場合は、XML とは異なる形式を検討することをお勧めします。または、少なくとも、各要素名と属性をできるだけ小さくし、不要な空白をすべて削除することで、XML の読みやすさをスペースと引き換えにしたい場合があります。

于 2010-06-06T16:45:49.933 に答える
0

同期を管理するために同期フレームワークを使用することを検討したかどうか疑問に思います。興味があれば、オープンソースプロジェクトであるOpenMobsterのSyncサービスをご覧ください。次の同期操作を実行できます

  • 双方向
  • 一方向クライアント
  • 一方向デバイス
  • 起動する

さらに、すべての変更は自動的に追跡され、クラウドと同期されます。ネットワーク接続がダウンしているときにアプリをオフラインにすることができます。変更を追跡し、接続が戻ったときにバックグラウンドで自動的にクラウドと同期します。また、複数のデバイス間でiCloudのような同期を提供します

また、クラウドでの変更はプッシュ通知を使用して同期されるため、データがローカルに保存されている場合でも、データは常に最新です。

あなたの場合、

Criteria are speed (less network data exchange), robustness (data recovery in case update fails), offline access

  • 速度：変更のみがネットワークを介して双方向に送信されます

  • 堅牢性：データをsqliteなどのトランザクションストアに保存し、失敗した更新はSyncMLペイロードで伝達されます。成功した操作のみが処理され、失敗した操作は次の同期中に再試行されます

オープンソースプロジェクトへのリンクは次のとおりです：http：//openmobster.googlecode.com

iPhone App Syncへのリンクは次のとおりです：http ：//code.google.com/p/openmobster/wiki/iPhoneSyncApp

于 2012-03-18T17:35:12.877 に答える
0

あなたの基本的なスキームは良いです。あなたがしなければならないことは、リスクなしで部分的に完了した転送を再開できるように、どうにかして更新を冪等にすることです。これは、ある種の真のアトミック コミットを実装しようとするよりも良い方法です (ただし、SQLite データベースなどを使用して実装することもできます)。

私たちの経験では、サーバーが十分に高速であれば、かなり大きな更新 (数十 KB) を非常に高速にダウンロードできます。更新を小さなビットに分割する必要はあまりありません。しかし、確かに、「最終更新」に関するより詳細な情報を保持することで、転送されるデータの量を最小限に抑えようとしても害はありません。

(そして、間違いなく、送信されるデータ表現として XML ではなく JSON を使用する必要があります。)

于 2011-12-19T03:56:13.793 に答える