デザインアプローチ：Android安心JSON

Question

私は、モバイルデバイスがサーバーデータベースから駐車データを照会する駐車システムを開発しています。換言すれば、ユーザは空の駐車スポットを要求し、サーバは彼のデバイス上にフリースポット番号を送る。私はJSONで安らかなアーキテクチャを使用しています。

私はGoogleのI/0 2010残りのクライアントアプリケーションのビデオを見て、彼はあなたが3デザインパターンを使用することができることを説明した：のContentProviderのAPI

のContentProvider & syncadapter

1. サービスAPI

2. これら3つのうちどれが自分のアプリケーションに最も適しているかを判断することはできません。誰にも有用なヒント/知識がありますか？

   ご協力いただきありがとうございます。

Answer 1

Google I/Oセッションの提案を使用してソリューションを実装しましたが、これは本当にうまく機能しています。

リモートサーバーからデータを取得するには、サーバーが応答するのを待っている間にUIスレッドをブロックできないため、バックグラウンドスレッドは必須です。これを行う最も簡単な方法は、サーバからデータをdoInBackgroundに取得したAsyncTaskを使用して、UIの更新やデータの保存をonPostExecuteで行う必要があります。このアプローチは、多くのユースケースで十分に機能しますが、Google I/Oセッションで対処していた問題は、サーバが応答するのを待っている間にアクティビティが中断された場合にデータを失うことでした。このセッションで提案されたソリューションは、データを保存してアクティビティに添付されていない方法で保存できるようにする方法の提案でした。

サービスを使用すると、データ取得をアクティビティから分離できます。 （ただし、サービスはUIスレッド上で実行されているため、データを取得するためにService内に個別のスレッドを作成する必要があります）ContentProviderは、サービスから情報を要求されたアクティビティに渡すときに機能しますサーバーデータ。データベースを使用してレスポンスを保存することができます。その後、アクティビティはデータベースから応答を取得できます。

SyncAdapterを使用すると、アプリケーションが必要なときに新鮮で準備が整うように、アプリが特にリクエストすることなく、失敗したサーバーコールを再試行したり、サーバーからデータを取得したりすることができます。もちろん、それはバッテリーをかなり枯渇させる可能性があるので、実際には非常に控えめに使用する必要があります。

少なくともService/ContentProviderのアプローチをお勧めします。私はそのソリューションを使用して、キャッシュメカニズムを簡単にアプリケーションに組み込むことができました。

希望に役立ちます。

Answer 2

サービスは確かです。私が望んでいると思っているのは、オープンスポットとそのスポットがジャッキであれば変更をユーザーに知らせるセミ・コンスタント・アップデートです。サービスは、JSONデータを送信するのを待って、バックグラウンドで実行するのに最適です。

ContentProviderとSyncAdapter私は携帯電話のデータだけを扱うと考えているので、なぜそれらを使用したいのか分かりません。