Android MVP：テストを有効にするのは単なる言い訳ですか？

Question

私は正直なところ、Androidに関するこのMVPや類似のものの周りに頭を浮かべることはできません。その本当のポイントは何ですか？

これまで、AndroidでMVPを使用する唯一の実用的な理由は、フレームワーククラス（アクティビティ、サービス、フラグメントなど）からユニットテスト可能なコードを抽出することでした。不可能）をテストする。

アクティビティ（および他のフレームワーククラス）は可能な場合（つまり、フレームワークにとらわれないコードを処理する場合）、プレゼンターに仕事を委任させ、そうでない場合は直接作業を行います。このため、プレゼンターは、アクティビティのライフサイクルを反映するメソッド（onStart、onResume、clickListeners ...）を持つことによって、何とか気が進まないように見えます。これがコードのにおいであるのだろうか？

これに加えて、MVP Androidアプリを構築するためのライブラリやパターンがたくさんありますが、実際には自分のプレゼンターを手動で作成して管理することの欠点は何ですか？ アクティビティとプレゼンターのデカップリングは、プレゼンターがアクティビティからのコードを単に抽出するだけであるため、定義によって密接に結合されています。プレゼンタにはプレゼンテーションロジックのみが含まれています（ビジネスロジックの残りの部分は、View/Presenterのデュオについて何も知らない専用クラスに入ります）。

私はこのトピックで少し失われていると感じています。私は、より大きな視点を得るために、この問題についていくつかの意見をしたいと思います。

Answer 1

はい、確かに、プレゼンテーションロジックのフレームワークには関係なくテストすることができますが、プレゼンターを変更することで、実行時の動作を変更することもできます。表示インターフェースには、もっと抽象的な方法が必要です（「非表示ボタンX」ではなく、データのセットを表示するなど）。 UIロジックをフレームワーク依存の実装から分離することで、UIの変更に異なるビューを使用したり、実行時にロジックを変更するPresenterを使用することができます。表示 - プレゼンターは 'シム'であり、「スパゲッティ」コードを書くのが難しくなります

Answer 2

長期的な視点からすれば、あなたのコードは実行可能で維持しやすいはずです。誰もリファクタリングコードに余分な時間を費やしたくありません。私たちがプロジェクトを始めるときには、適切なパターンについて行うべきことがあります。

MVPについて話すと、簡単にテストできるプレゼンターレイヤーが用意されています。ビュー参照がないため、junitテストケースを簡単に実行できるため、他のUIテストケースを使用する必要があります。それがこれだけのビジネスロジック

が含まれているよう

あなたは、どこでもあなたが望む私の提案を同じプレゼンターを再利用することができます何かがしやすい場合がたいが、将来のコードの問題