翻訳者から：-私はAndroidアプリケーションのコードをよりきれいにする方法に長い間興味があり、これはおそらく私が考えなかった最初の記事です：「なぜこれがすべてあるのですか？」 そして「彼は一度人生でそれを使用しようとしたことがありますか？」 したがって、私は翻訳することにしました。多分それは他の誰かに役立つでしょう 。



Hello Worldの作成は常に簡単です。 コードはシンプルでわかりやすいように見え、SDKはお客様のニーズに合わせて調整されているようです。 しかし、より洗練されたAndroidアプリケーションを作成した経験がある場合は、動作するコードのすべてが間違っていることがわかります。 WiFiが利用できない場合に電話の向きを変更した後、ショッピングカートが更新されない理由を理解しようとして何時間も費やすことができます。 問題の解決策は、アクティビティの457行のonCreate()



メソッドの場合、Android 4.1を搭載したSamsungでクラッシュを修正するコードと、クーポンを表示するコードの間のどこかに別のユーザーの誕生日ごとに5ドル。 良い方法があります



Remind（ およそ Per。-著者の勤務する会社の名前）では、2週間ごとに新しい機能を展開しています。このスピードと製品の高品質を維持するために、コードをシンプルで、サポートされ、分割された状態に保つ方法が必要です（ およそ。疎結合の意味での「分離」）およびテスト可能。 MVPアーキテクチャパターンを使用すると、これを実行し、コードの最も重要な部分であるビジネスロジックに集中できます。



MVPまたはModel-View-Presenterは、ユーザーインターフェイスを実装する際の責任の共有に寄与するいくつかのパターンの1つです。 これらのパターンのそれぞれで、レイヤーの役割はわずかに異なります。 この記事の目的は、パターン間の違いを説明することではなく、これをAndroid（ RailsやiOSなどの最新のUIフレームワークに似ています）に適用する方法と、アプリケーションがこれからどのように利益を得るかを示すことです。



以下に説明するほとんどのアプローチを示すサンプルコードは、ここにあります。

https://github.com/remind101/android-arch-sample

オールドスクールAndroid

Androidフレームワークによって暗示される責任の分離は、次のようになります。 モデルは任意のPOJOであり、 ビューはXMLマークアップであり、フラグメント（または最初のアクティビティ）はController / Presenterとして機能します 。 理論的には、これは非常にうまく機能しますが、アプリケーションが成長するとすぐに、ビューに関連する多くのコードがコントローラーに表示されます。 これは、XMLでできることはあまりないため、すべてのデータバインディング（データバインディング）、アニメーション、入力処理などが、ビジネスロジックと共にフラグメントで行われるためです。



複雑なインターフェイス要素がリストまたはグリッドに配置されると、すべてがさらに悪化します（ 約 -がGridView / GridLayoutを指し、実際に「グリッド要素」を指します）。 現在、アダプターには、これらすべての要素のビューとコントローラーコードを格納するだけでなく、それらをコレクションとして管理する責任があります。 これらの要素はすべて密接に関連しているため、保守が非常に難しくなり、テストがさらに難しくなります。

Model-View-Presenterの紹介

MVPを使用すると、インターフェイスを表示してビューで操作するために必要な退屈な低レベルのAndroidコードをすべて強調表示し 、アプリケーションが行う必要のある高レベルのビジネスロジックをPresenterに移動できます。



これを実現するには、Androidで、アクティビティまたはフラグメントをプレゼンテーションレイヤーと見なし、プレゼンテーションを制御するための軽量なプレゼンターを提供する必要があります。 最も重要なことは、各層の責任を決定し、それらの間のインターフェースを標準化することです。 分離の一般的な説明は次のとおりです。



ビュー（アクティビティまたはフラグメント）の役割は次のとおりです。

1. プレゼンターインスタンスとそのアタッチメント/デタッチメントメカニズムの作成。
2. 発表者に重要なライフサイクルイベントについて警告する。
3. 入力イベントに関する発表者へのメッセージ。
4. ビューの配置とデータとの接続。
5. アニメーション
6. イベント追跡;
7. 他の画面に切り替えます。

プレゼンターは以下を担当します。

1. モデルをダウンロードしてください。
2. モデル参照と表示状態の保存。
3. 画面に表示するものをフォーマットし、それを表示するようビューに指示します。
4. リポジトリ（データベース、ネットワークなど）との相互作用（ 約リポジトリごと -これはパターンです、念のため）。
5. ビューから入力イベントを受信したときに必要なアクションの決定。

プレゼンテーションとプレゼンターの間のインターフェイスの例を次に示します。

 interface MessageView { //      ,         //     void setMessageBody(String body); void setAuthorName(String name); void showTranslationButton(boolean shouldShow); //   void goToUserProfile(User user); } interface MessagePresenter { //       ,        //     void onStart(); //    void onAuthorClicked(); void onThreeFingersSwipe(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このインターフェイスに関連して検討する価値のある興味深い点がいくつかあります。

• プレゼンテーションを更新する方法は単純で、別の要素を対象とする必要があります。 表示する必要があるものをフォーマットするのはプレゼンターの責任であるため、すべてを更新する1つのsetMessage(Message message)
  
  
  
  メソッドを持つよりも優れています。 たとえば、将来、現在のユーザーがメッセージの作成者であり、これがビジネスロジックの一部である場合、ユーザー名の代わりに「あなた」を表示する必要があります。
• プレゼンターのライフサイクルイベントメソッドはシンプルであり、真の（過度に複雑な）システムライフサイクルを反映すべきではありません。 それらを処理する必要はありません。 ただし、プレゼンターにこのサイクルのさまざまな段階でいくつかのアクションを実行させたい場合は、その中の好きなだけ処理できます。
• プレゼンターの入力イベントは高レベルのままである必要があります。 たとえば、3本指のスワイプなどの複雑なジェスチャを定義する場合、このイベントと他のイベントはビューによって決定される必要があります。
• メソッドMessagePresenter.onAuthorClicked()
  
  
  
  およびMessageView.goToAuthorProfile()
  
  
  
  注意を払うことができます。 ビューの実装には、このプレゼンターメソッドを呼び出すクリッカーが含まれている可能性が高く、そのクリッカーはgoToAuthorProfile()
  
  
  
  を呼び出します。 これをすべて削除して、キツネのクリックから直接著者のプロファイルに移動する必要がありますか。 いや！ 名前をクリックしたときにユーザープロファイルに切り替えるかどうかの決定は、ビジネスロジックの一部であり、プレゼンターがこれを担当します。

実際に判明したように、プレゼンターのコードに純粋なJavaだけでなくAndroidフレームワークのコードが含まれている場合、おそらく何か間違ったことをしていることになります。 したがって、ビューにモデルへの参照が必要な場合は、明らかに何か間違ったこともしているようです。



テスト問題が発生するとすぐに、テストする必要があるコードのほとんどがプレゼンターになります。 すばらしいのは、このコードはAndroidのコンテキストでの実装ではなく、目的のビューのインターフェイスへのリンクのみを持っているため、Androidを実行する必要がないことです。 これは、ビューインターフェースをウェットにし、メソッドがウェットビューに対して正しく呼び出されることを確認するビジネスロジックの純粋なJUnitテストを書くことができることを意味します。 これがテストの外観です。

リストはどうですか？

これまで、私たちのアイデアは行動主義と断片であると想定していましたが、実際には何でも構いません。 ビューインターフェースを実装するViewHolder （ RecyclerView.ViewHolder



とListViewとともに使用する通常の古いViewHolderの両方）を使用して、リストを非常にうまく機能させることができました 。 アダプターでは、プレゼンターのアタッチ/デタッチを処理するための基本的なロジックが必要です（このすべての例はgitリポジトリにあります）。



メッセージのリスト、ダウンロードの進行状況、および空のビューを含む画面の例を見ると、責任分担は次のようになります。

• リストプレゼンターは、メッセージのロードとリスト/進行状況/空のスタブビューの表示ロジックを担当します。
• フラグメントは、リスト/進行状況/スタブビューの表示ロジックの実装と、他の画面への移行を担当します。
• アダプターは、プレゼンターをViewHoldersにマップします。
• メッセージプレゼンターは、個々のメッセージのビジネスロジックを担当します。
• ViewHolderは、メッセージの表示を担当します。

これらのコンポーネントはすべて疎結合であり、互いに別々にテストできます。



さらに、メッセージリスト画面と詳細画面がある場合、同じメッセージプレゼンターを再利用し、プレゼンテーションインターフェイスの2つの異なる実装（ViewHolderとフラグメント内）のみを使用できます。 これにより、DRYコードが保存されます（ 約 -「知らない人」または「繰り返さない」）。



同様に、カスタムビューはビューインターフェイスを実装できます。 これにより、カスタムウィジェットでMVPを使用して、アプリケーションのさまざまな部分でMVPを再利用したり、複雑なインターフェイスを単純なブロックに単純に分割したりできます。

MVPと構成の変更

しばらくAndroidで書いている場合、方向と構成を変更するためのサポートがあなたにどれほど苦痛を与えるか知っています。

• フラグメント/アクティビティは、その状態を復元できるはずです。 フラグメントを操作するたびに、向きを変更するときにこのことをどのように実行するか、saveInstanceStateバンドルに何を配置するかなどを自問する必要があります。
• バックグラウンドスレッドでの長時間の操作を正しく行うのは非常に困難です。 最もよくある間違いの1つは、完了後にUIを更新する必要があるため、フラグメント/アクティビティへのリンクをバックグラウンドスレッドに保存することです。 これにより、メモリリークが発生し（おそらく、メモリ消費の増加によりアプリケーションがクラッシュします）、新しいアクティビティがコールバックを受信しないため、UIが更新されません。

MVPを適切に使用することで、この問題をまったく考慮することなく解決できます。 プレゼンターは現在のUIへの強力なリンクを持たないため、非常に軽量であり、向きを変更することで復元できます。 プレゼンターはモデルとビューの状態へのリンクを保存するため、向きを変更した後、ビューの目的の状態を復元できます。 このパターンが使用されている場合、画面が回転したときに何が起こるかについての例の説明があります：

• 最初に、アクティビティが作成されました（「最初のインスタンス」と呼びましょう）。
  
  
  • 新しいプレゼンターが作成されています。
  • プレゼンターはアクティビティにアタッチされます。
• ユーザーがダウンロードボタンをクリックします。
  
  
  • プレゼンターは長時間の操作を開始します。
• 方向は変化しています。
  
  
  • プレゼンターは、アクティビティの最初のコピーから解放されます
  • アクティビティの最初のインスタンスは参照されなくなり、ガベージコレクターで使用できるようになりました。
  • プレゼンターが保存され、バックグラウンド操作が続行されます。
  • アクティビティの2番目のインスタンスが作成されます。
  • アクティビティの2番目のコピーがプレゼンターに添付されます。
• ダウンロードが完了しています。
  
  
  • プレゼンターはプレゼンテーションを更新します（アクティビティの2番目のインスタンス）。

方向の変更の間にフラグメントを保存する方法は、 PresenterManager



クラスのリポジトリで確認できます。

まとめ

はい、これで終わりです。 MVPのような共有の責任が、サポートされたテスト可能なコードを作成するのにどのように役立つかを実証できたと思います。



要約すると：

• プレゼンターのベアJavaオブジェクトにビジネスロジックを配置して、ビジネスロジックを分離します。
• プレゼンターとプレゼンテーションの間のきれいなインターフェイスに時間をかけます。
• アクティビティ、フラグメント、カスタムビューにプレゼンテーションインターフェイスを実装させます。
• リストの場合、ViewHolderはビューインターフェイスを実装する必要があります。
• プレゼンターを徹底的にテストします。
  
  
  • 向きを変えるときは発表者を維持します。

上記の実装はArchExampleリポジトリで見つけることができます 。

Mosby 、 Flow and Mortar 、またはNucleusなど、このアプローチを支援する多くのライブラリもあります。 それらを検討することをお勧めします。