私はほとんどの場合、Web サービスからデータをダウンロードするときに Service を使用します。結果をデータベースに保存し、カーソルローダーを使用してビューに結果を表示します。しかし、Google がネットワーク ライブラリ Volley をリリースした後、私は少し混乱しました。ボレー ライブラリはサービスの代わりに非同期タスクを使用し、カーソルを使用しません。データを失ったり、データを再度ダウンロードしたりすることなく、向きの変更を適切に処理できるように、非同期タスクを避けてデータをデータベースに保存する必要があると考えました。
私の質問は、いつ自分のダウンロード戦略の代わりに Volley を使用する必要があるかということです。
個人的には、これまでサービスの使用は実装が面倒だと感じていましたが、最終的には適切に構成され、一貫した優れたエクスペリエンスでした。しかし、スレッド化のパフォーマンスは...管理が難しいです。
サービス クエリ -> データベースの負荷 -> 通知
UI は、クエリとカーソルの読み込みを開始します - > UI を更新します。
ボレーを使用すると、以前はサービスとデータベース内で処理されていたコンポーネント全体をスキップしたくなります。
UI ボレー リクエスト -> ボレー レスポンス -> UI の更新
ただし、これは、表示しようとしているデータや、次の要件のいずれかに対してクエリを実行しているサーバーによっては、すぐに崩壊します。
ユーザーは下にスクロールして、さらに多くのページを表示する可能性があります。ただし、ユーザーがアクティビティに戻ったり、単に回転したりした場合でも、ページを構成する他のすべてのクエリを具体的に覚えていない限り、Volley の呼び出しは最初のページの結果のみを返します。これは、より便利になることを意図したアーキテクチャにとっては大変な作業になります。または、わずかに異なるページであっても、ユーザーが電話を回転させるだけの場合、一貫性のないエクスペリエンスになる可能性があります。
変更をローカルに適用してから、いつでもサーバーに適用する方が簡単です。ボレーのみでは、REST の更新と (以前のすべてのクエリの) 再クエリを同期的に行う必要があります。
ボレーは本当に速いです。ただし、クエリしているサーバーに依存する可能性のある利用可能なキャッシュヒットを除いて、永続性がありません。積極的なキャッシングは、古いデータでアプリに大混乱をもたらすことさえあります。ローカル データベースからプルすると、過去のクエリで実際にデータを参照している可能性のある複数のアクティビティをナビゲートするときに、一貫性のある高速なエクスペリエンスが提供されます。純粋なボレー エクスペリエンスでは、以前のクエリから技術的には既に持っているが、そのデータを取得するための中央データ ストアがないデータに対してクエリを実行する必要がある場合があります。
最近は実際にサービス部分をスキップしていますが、それ以外はすべて従来のアーチのままです
UIがボレー クエリとカーソル ロードを開始 - > UI を更新
ボレークエリ-> データベースの更新 -> 通知
また、UI がサービスに ping を実行し、サービスがボレーを使用することを妨げるものは何もありません...より伝統的に見えますが、より多くの制御ロジックをより集中化された場所に移動する価値があるかもしれませんが、それが内部から実行されているという事実「サービス」は実際には技術的な利点を提供しません。
それが役立つことを願っています。基本的に、ボレーだけにしようとしないでください。私が試してみたところ、それがうまくいった場合、非常に具体的でシンプルなアプリになり、主な落とし穴を特定できたことを願っています.
また、サービス中なのにロボスパイスでも同じような落とし穴を見つけてしまいました… しかし… YMMV
Volley は、スレッドなどを管理するサーバーと通信するための単なるヘルパー レイヤーです。はい、すでに素敵なスレッド キャッシュなどを実装しています。ただし、アクティビティで使用する必要はありません。私はあなたがすべきではないとさえ言うでしょう。実際、サービスはバックグラウンド ネットワーク作業を行う場所であることは誰もが知っています。これは、構成の変更に耐えるように設計されており、アプリケーションがバックグラウンドで動作することを宣言する自然な方法であり、システムで細心の注意を払う必要があります。
想像してみてください、ボレーはありませんでした。あなたならどうしますか？スレッド サポートをサービスに実装することは間違いありません (サービスがメイン スレッドで動作することは誰もが知っています)。これは、単一の静的ワーカー スレッドとそのハンドラーである IntentService と同じくらい単純かもしれません。または、気を利かせて ExecutorService を使用してスレッドのプールを作成することもできます。new Thread()または、夢中になって で毎回開始することもできますonStartCommand()。あなたのニーズと好みに合ったものは何でも。
そのため、ボレーをこのタスクを達成するための別の方法と見なすことを好みます。今回は、自分でスレッドを操作する必要はありません。Volley に任せるだけです。
要するに、ボレーとサービスを一緒に使用することです。
Volley は、ネットワーク要求を非同期で実行するためのより便利な方法を提供することを目的としています。Serviceaまたは anをサブクラス化する必要はなくAsyncTask、その構文は経験豊富な開発者にとって非常に単純です。
上で述べたように、これは完全に便宜上のものです。うまく機能するメカニズムがある場合は、ぜひそれを使用してください。Volley既存のモデルに従ってコードを頻繁に書き直していることに気付いた場合は、またはdroidQueryなどの再利用可能なライブラリを調べることをお勧めします。
正解も不正解もありません。しかし、より良いまたはより悪い要因があるかもしれません。ここでの主な比較は速度です。Volleyは高速性を誇っており、 Android SDKOKHTTP (または互換パック)の一部になるだけでなく、まもなくサポートされる予定であり、Android プラットフォームとともに成長し続けています。これらのことが重要な場合は、将来のアプリケーションに切り替える必要があるかもしれません (現在のアプリケーションに顕著な遅延がない限り、動作するコードを変更するポイントを見つけるのに苦労するでしょう)。