web-dev-qa-db-ja.com

MVPプロ​​ジェクトのパッケージ構造のベストプラクティス

Android MVPアーキテクチャを使用しているStudioプロジェクトがあります。このスタイルで実行できるプロジェクトの推奨パッケージ構造は次のとおりです。

app:
  screen_name
    activityA
    presenterA
    interfaceA

or:
   activities
     activityA
     activityB
   preentors
     presentorA
     presentorB
etc
androidpackagemvp
9
presenchi

あなたの問題は、[〜＃〜] ui [〜＃〜]のみMVPアーキテクチャパターン。これは、対応するPresentersとともにViewクラスです。そして、より良い解決策はfirstアプローチです。

enter image description here

アプリには、一般的な機能ではなく、機能に応じたパッケージが必要です。 一緒に変更/修正するクラスをグループ化する必要があります。

一部の開発者は、2番目のアプローチのように、ソースコードをレイヤー別にグループ化します。これは、作業するすべてのプロジェクトで同じパッケージ構造を維持したいためです。しかし、同じ親クラスを共有しているという理由だけでグループ化されたクラスを見つけるのは常に難しいので、それは悪い決定です！

例：アクティビティの場合、すべてのアクティビティがactivityクラスを拡張するため、一部の開発者はそれらをActivityパッケージに入れます。これはアクティビティのみのパッケージなので理にかなっていますが、これらのパッケージを通過するのは困難です。

詳細については、次を参照してください： Android-mvp-architecture およびこのS.O answer

17
nhoxbypass

MVPは良い選択です。次のパターンに従うことができます。

アプリ：1.アクティビティ：+ビュー（つまり、アクティビティ）を表すインターフェース+実際のアクティビティJavaクラス2.プレゼンター：+プレゼンターを表すインターフェース+ Javaクラスプレゼンター実装を表す3.モデル：+モデルを表すインターフェース+ Javaモデル実装を表すクラス（ここでネットワーク呼び出しを行い、コールバックをプレゼンターに渡し、アクティビティにデータを渡します）

0
The90sArtist

他の回答に加えて、 Androidアーキテクチャの設計図 を参照することをお勧めします。これにより、アプリケーションの構成方法と実装方法がわかります。

0
Alon Aviram