11

問題: 非常に大規模で複雑な Activity クラス。読みにくい/理解しにくい、修正しにくい。テストが難しい。

考えられる解決策: Model-View-Presenter (おそらく依存性注入を使用)。そして模擬テストオブジェクト!

Android アプリケーションに Model-View-Presenter を実装する予定です。これは基本的に Model-View-Controller の変形です。要するに、Activity を美化されたレイアウト マネージャーにし、ビジネス ロジックをプレゼンターに委ねます。プレゼンターのもう 1 つの見方は、アクティビティ内でインスタンス化されたヘルパー クラスのようなもので、プレゼンターが使用できるインターフェイス/コールバックを提供するアクティビティで重労働を行うことです。

これについて、コミュニティの意見を聞きたいと思います。例: これによって暗示されるインターフェイスは何ですか?
Model と View は、Presenter に対してどのような責任を負いますか。

プレゼンターの場合、アクティビティはプレゼンターに必要なインターフェイスを実装すると思いますか?
プレゼンターとアクティビティにはどのようなものを入れる必要がありますか?

プレゼンターはアクティビティと 1 対 1 になりますか? それぞれが独自のアダプターを持つ異なるウィジェットを表示する複数のフラグメントを持つアクティビティはどうでしょうか? 複数の発表者が必要ですか、それとも 1 人だけですか?

プレゼンターとアダプターはどうですか?

プレゼンターは、ListView と ListViewAdapter を使用したアクティビティとどのように関連する必要がありますか? プレゼンターとアダプターには何が入りますか?
プレゼンターは使用するアダプターを選択する必要がありますか? それとも、アクティビティがこの決定を行う必要がありますか? プレゼンターはモデル データまたはアダプターを処理する必要がありますか? アダプターとプレゼンターの間に競合はありますか? アダプターはプレゼンターですか? またはそれ以下/以上。通常、アダプタは、アクティビティ内の ListView などのウィジェット専用です。私が思うに、彼らはデータ自体を取得する呼び出しを行いません。

したがって、model-view-presenter で重要なことは、プレゼンターと他のクラスで何が行われるか、およびプレゼンターとアクティビティ、アダプター、ビュー/フラグメントを含む間の通信がどうあるべきかを実際に決定することです。

Model-View-Presenter は Android にとって本当に悪い考えですか? それとも、Android フレームワークにうまく適合しますか?

Android 以外にも、MVP のようなマイクロ アーキテクチャをまだ必要としている非常に成熟した SDK の例が数多くあることに注意してください。実際、例はたくさんあります。Flex は Flash 用の非常に成熟した SDK でしたが、ほとんどすべての主要なアプリに MVP および MVC フレームワークが必要でした。

EJB には、それを単純化して整理するために Spring が必要でした。MFC/Struts など、リストは延々と続きます。なぜAndroidは違うのですか?MVP のようなデザイン パターンのない Android の場合、SDK には必要なものがすべて揃っていると想定する必要があるのはなぜですか?

これに何百時間も費やす前に知っておくと便利です。この質問のどの部分についても、お気軽にコメント/回答してください。

4

2 に答える 2