8

Model-View-Presenter (MVP) は、GUI アプリケーションのよく知られたデザイン パターンです。Android の場合、プレーンな Java モジュールでビジネス ロジックを実装すると、Android エミュレーターを必要とせずにテストが容易になります。

ただし、Android アプリケーションの GUI には特別な要件があるため、Android でパターンを実装するのに苦労しています。

  • アクティビティはいつでも破棄される可能性があり (着信コール、ユーザーがホーム ボタンを押すなど)、再作成されたときは、残されていたときとまったく同じ状態になるはずです。これは、他のほとんどの GUI アプリケーションとは異なります。

  • アクティビティは、多くのライフサイクル状態を通過できます。一時停止される場合があります。その場合、アクティビティの UI は変更されません。たとえば、一部のデータがバックグラウンドでロードされている場合、MVP (アクティビティ) の View 部分に一時停止状態にあると配信できません。繰り返しますが、これは異常な要件です。

ブログ投稿MVP for Androidを読み、ソース コードの例を確認しました。MVP パターンを使用して達成しようとしている最終目標は、トランスパイラーj2objcを使用してすべてのビジネス ロジックを Objective-C に変換できるようにすることです。これにより、iOS で同じアプリを実装しながらビジネス ロジックを再利用できます。

Android の MVP パターンを正常に実装した人はいますか? その場合、何が足りないのでしょうか?

4

2 に答える 2

1

Android が構築されている MVP バリアントは、アプリ内のビジネス ロジックを分離するための正しい方向への一歩であることがわかりました。ただし、懸念事項をより適切に分離し、その結果、より再利用可能なドメイン/ビジネス ロジックを実現したい場合は、Presenter First パターンを使用することをお勧めします (コメントで簡単に言及してください)。結合を減らすことは別として、TDD に適しているため、すべてのビジネス ロジックの単体テストを行うことができます。

私は最近、Android 用の Presenter First の例を含む GitHub リポジトリを開始しました。Android アーキテクチャが複雑なため、パターンを実装するのは簡単ではありません ビューは、通常の Presenter First アプリで許容できると思われるものよりも「太る」傾向があります。これは主に、アクティビティのライフサイクルやその他の奇妙な点が原因です。ビジネス ロジックをプラットフォームから分離するために最善を尽くしましたが、改善の余地は確かにあります。例は次の場所にあります。

http://github.com/olerass/presenter-first-android

そこからのアイデアが活かせるかも？または、さらに良いことに、あなた自身のいくつかを貢献してください。

于 2016-01-14T22:53:30.177 に答える