モバイルアプリのデザインパターン。 コマンドプロセッサ

「あたかもあなたが住んでいる場所を知っている暴力的なサイコパスが同伴するかのようにコードを書いてください。」
マーティン・ゴールディング

GooglePlacesAPIを使用してプロジェクトの1つを開発するとき、AndroidアプリケーションとサーバーAPI間のネットワーク相互作用を整理する問題がありました。 AsyncTaskの直観と「麺」は、この種の相互作用を整理する他の方法があるべきだと示唆しました。 そこで、私はCommandProcessorデザインパターンに出会いました。 Androidアプリケーションでのこのデザインパターンの使用についてお話したいと思います。

まず、解決する必要がある問題について説明します。 Google Places APIを使用してアプリケーションを作成し、ユーザーが選択したマップ上の任意の場所のプレビューを表示し、ユーザーが詳細な情報（たとえば、より多くの画像を表示）を取得する場合、選択した場所の指定されたIDに画像を読み込み、すべての画像を既に表示する必要がありました選択した場所に関連しています。 当時の私にとって最も明白な方法は、AsyncTaskを使用することでした。 しかし、いくつかの試みの後、より便利な他の方法があるはずであることが明らかになりました。 AsyncTaskを使用すると、次の理由で不便でした。

1）場所のプレビューを取得するには、まず、ユーザーが選択した場所の隣にあるすべての場所に関する情報を取得するよう要求する必要がありました。

2）受信したIDフォームに基づいて、写真プレビューのリクエストを送信します。

3）プレビューをクリックすると、この場所に関連するすべての写真が表示されます。

したがって、AsyncTaskを使用すると、特定の「ウォーターフォール」が取得され、あるAsyncTaskを別のAsyncTask内で使用する必要があります。 そして、グーグルで調べると、上記のタスクに対処するコマンドプロセッサパターンに関する情報が見つかりました。

CommandProcessorデザインパターンは、サービスリクエストとその実行を分離します。 パターンの主要コンポーネントであるCommandProcessorは、要求を管理し、実行をスケジュールし、追加のサービスも提供します。たとえば、実行の遅延や要求のキャンセルなどの要求の保存です。 [1]から引用した図は、パターンのコンポーネント間の関係を示しています。

パターンの範囲

• ユーザーがグラフィカルインターフェイスを介してシステムと対話するプログラム。 例：テキストエディター、オフィスアプリケーション。 コマンド（以降、コマンドはクエリと同じ）は、ユーザーがマウスボタン、ホットキー、メニューボタンなどを押した後に何らかのタスクを実行するために使用されます。 コマンドは、実行のためにプロセッサに渡されるオブジェクトです。
• 分散システムまたは並列システム。 このパターンを使用すると、コマンドを送信して別のスレッドで実行できます。 コマンドなどのキューを作成します。
• ネットワークと対話するアプリケーション。

実装

次に、このパターンをモバイルアプリケーション、特にAndroidアプリケーションの開発に適用する方法を見てみましょう。 IntentServiceまたはHaMeRフレームワーク（Handler、Messages、Runnable）を使用することができますが、このパターンをテストアプリケーションに実装する方法を見てみましょう。 そのため、テストアプリケーションは、特定のルートに含まれるルートと場所のリストを表示します。 したがって、TracksRequestとPlacesRequestの2種類のリクエスト（コマンド）があります。 両方のクラスは、プロセッサー（CommandProcessor）によって処理されるために、CommonRequest基本クラスの子孫です。

//  CommonRequest   public abstract class CommonRequest { public abstract void sendRequest(int i); public int requestId; } 

 //  PlaceRequest public class PlacesRequest extends CommonRequest{ private MessageController handler_; public PlacesRequest(MessageController handler){ this.handler_ = handler; } public void sendRequest(int id){ sendAsyncPlaceRequest(id); } } 

 //  TracksRequest public class TracksRequest extends CommonRequest { private MessageController handler_; public TracksRequest(MessageController handler) { this.handler_ = handler; } public void sendRequest(int id) { sendAsyncTracksRequest(); } } 

すべての作業はsendAsyncPlaceRequestメソッドで行われます。APIリクエストのURLを作成し、新しいスレッドを作成し、応答を解析して、ハンドラーを使用してコントローラーに結果を渡すことができます。

 private void sendAsyncPlaceRequest(final int id){ Thread background = new Thread(new Runnable() { @Override public void run() { String response = sendRequest(getUrl(id)); List<Place> places = new ArrayList<>(); try { places = getPlacesFromJson(response); } catch (JSONException e) { Log.e("JSONException", e.getMessage()); } handler_.sendMessage(handler_.obtainMessage(States.PLACES_WERE_FOUND,places)); } }); background.start(); } 

次に、リクエストを管理して実行するCommandProcessorクラスを実装する必要があります。

 publicclassRequestProcessor { private UpdateCallbackListener clientActivity_; public RequestProcessor(UpdateCallbackListener clienActivity) { this.clientActivity_ = clienActivity; } //         public void execute(CommonRequest request, int id) { request.sendRequest(id); } public void updateActivity(List<? extends Result> results) { clientActivity_.onUpdate(results); } } 

ここで、状態に応じて、プロセッサに異なるコマンドを送信するコントローラーが必要です。 要求の結果は、ハンドラーを使用してストリームから送信されます。

 public class MessageController extends Handler { private static MessageController instance = null; private RequestProcessor processor_; public void init (UpdateCallbackListener listener) { processor_ = new RequestProcessor(listener); } public static MessageController getInstance(){ if (instance == null){ instance = new MessageController(); } return instance; } public void handleMessage(Message msg) { switch (msg.what) { case States.INIT_REQUEST: CommonRequest request = (CommonRequest)msg.obj; processor_.execute(request); break; case States.REQUEST_COMPLETED: List<Result> results = (List<Result>)msg.obj; processor_.updateActivity(results); break; default: break; } } } 

アクティビティでの作業結果を返し、ユーザーインターフェイスを更新するためにupdateUI（）を呼び出す（ListViewの入力、マップ上のマーカーの描画など）には、UpdateCallbackListenerインターフェイスを定義する必要があります。

 public interface UpdateCallbackListener { void onUpdate(List<? extends Result> results); } 

そして、それをアクティビティに実装します。

  public void onUpdate(List<? extends Result> results){ tracks_ = (List<Track>) results; TrackAdapter trackAdapter = new TrackAdapter(this,tracks_); listView_.setAdapter(trackAdapter); } 

リクエストへの応答で結果が返された後（たとえば、このルートに沿ったすべてのプレイスのリクエスト）、アセットを更新し、プレイスオブジェクトをアダプタに転送する必要があります。 processor_.updateActivity（places）メソッドを介してこれを行うことができます。このメソッドは、このメソッドを実装したアクティビティでonUpdate（）を呼び出します。 [1]から取った次の図は、パターンの動作のダイナミクスを示しています。



リクエストを開始するには、アクティビティでTracksRequestオブジェクトを作成し、それをコントローラーに渡す必要があります。

  controller_ = MessageController.getInstance(); controller_.init(this); TracksRequest tracksRequest = new TracksRequest(controller_); controller_.sendMessage(controller_.obtainMessage(States.INIT_REQUEST,tracksRequest)); 

IntentServiceを使用した実装

IntentServiceを使用すると、このパターンを完全に実装することもできます。 図を考えてください：



Intentをコマンドオブジェクトとして使用し、プロセッサに渡すことができます。 Creatorはアクティビティであり、コマンドオブジェクトを作成し、このオブジェクトをエグゼキュータ、つまりこの場合はIntentServiceに渡します。 したがって、CommandProcessorの役割は、CustomIntentServiceクラス、つまりonHandleIntent（）メソッドによって実行されます。onHandleIntent（）メソッドは、Intentに含まれるデータに応じて、さまざまな操作を実行できます。 この場合、結果をアクティビティに返すには、BroadcastReceiverを使用できます。

順を追った説明

したがって、要約すると、このパターンを実装するには、以下を実行する必要があります。

• 抽象コマンドのインターフェースを定義します。 インターフェイスは、個々のコマンドの実装をカプセル化します。 私たちの場合、それはsendRequest（int i）メソッドであり、各コマンド（リクエスト）は別々に実装されていました。
• チームが結果を呼び出し元に返す方法を決定します。 このように、各アクティビティにonUpdate（）メソッドを使用して、UpdateCallbackListenerインターフェイスを定義しました。
• 各チームを実装します。 リクエストには2種類あります。1つはルートに関する情報を受信するため（TracksRequest）、もう1つは場所に関する情報を受信するため（PlacesRequest）です。
• コマンドを送信するコントローラーを実装します。 コマンドの作成と送信は、Abstract FactoryまたはPrototypeを使用して実装できます。 ただし、コントローラーがコマンドの作成者である必要はありません。 例からわかるように、リクエストオブジェクトはアクティビティで作成されました。
• コマンドとプロセスを受け取るプロセッサクラスを実装します。 リクエストごとに、RequestProcessorクラスはexecute（）メソッドを実行します。

パターンの長所と短所。

利点：

• テキストエディタなどのアプリケーションでは、異なるインターフェイス要素が同じコマンドを使用できます。 たとえば、「作成」メニューのボタンと、コンテキストメニューの同じ名前のボタンは、同じコマンドにアクセスできます。
• 要求の結果に応じて、非同期要求を送信し、呼び出しの順序を制御する機能。
• 既存の機能を損なうことなく、新しいコマンド（リクエスト）の形で新しい機能を追加する際の柔軟性。 新しいコマンドを変更または追加しても、コマンドハンドラーには影響しません。
• 異なるクライアント（この場合、アクティベーション）は同じコマンドを使用できます。 たとえば、IDによるイメージのダウンロード要求は、さまざまなアクティビティに使用できます。

短所：

• さらに、各状態を追跡し、それに応じて処理する必要があります。
• チームの数は非常に多くなる可能性があります
• 双方向通信。 アクティベーションが要求の作成を開始し、応答が受信された後、結果をアクティベーションに返す必要があります。

おわりに

おそらく、何らかの形で、すでにパターンの実装を見てきました。 しかし、モバイルアプリケーションアーキテクチャのテーマは非常に重要であるため、この記事が役に立てば幸いです。 将来的には、モバイルアプリケーションの開発で使用されるいくつかのパターンを検討する予定です。 コメントに質問を書いて、後でまた会いましょう。

ソースのリスト

[1]パターン指向ソフトウェアアーキテクチャボリューム1.ダグラスシュミット、マイケルスタル、ハンスローナート、フランクブッシュマン
[2] Command Revisited www.dre.vanderbilt.edu/~schmidt/PDF/CommandRevisited.pdf
Githubテストプロジェクト： github.com/GregaryMaster/CommandProcessor