Android上のMVCパターン
Android用のJavaでモデル - ビュー - コントローラーのパターンを実装することは可能ですか？
それとも、すでに活動を通じて実施されていますか？それともAndroid用のMVCパターンを実装するためのより良い方法はありますか？
AndroidにはMVCがありませんが、次のものがあります。
- あなたは ユーザーインターフェース を解像度、ハードウェアなどによって様々なXMLファイルで定義します。
- あなたは リソース をロケールなどによってさまざまなXMLファイルで定義します。
- ListActivity 、 TabActivity などのクラスを拡張し、 inflaters によってXMLファイルを利用します。
- ビジネスロジックに必要な数のクラスを作成できます。
- Utils の多くはすでにあなたのために書かれています - DatabaseUtils、Html。
普遍的にユニークなMVCパターンはありません。 MVCは、堅実なプログラミングフレームワークというよりはむしろ概念です。あなたはどんなプラットフォームにあなた自身のMVCを実装することができます。次の基本的な考え方に固執する限り、MVCを実装しています。
- モデル： 何を描画するか
- 表示： レンダリング方法
- コントローラー： イベント、ユーザー入力
また、このように考えてください。モデルをプログラムするとき、モデルはレンダリング（またはプラットフォーム固有のコード）について心配する必要はありません。モデルはビューに言うでしょう、私はあなたのレンダリングがAndroidかiOSかWindows Phoneであるかどうか気にしません、これは私があなたがレンダリングする必要があるものです。ビューはプラットフォーム固有のレンダリングコードのみを処理します。
これは、クロスプラットフォームアプリケーションを開発するために Mono を使用してモデルを共有する場合に特に便利です。
Androidのアクション、ビュー、アクティビティは、Android UIを操作するための組み込みの方法であり、 モデル - ビュー - ビューモデル（MVVM）パターン の実装です。 ）モデル - ビュー - コントローラ。
私の知る限りでは、このモデルから抜け出す方法はありません。それはおそらく可能ですが、既存のモデルが持っているすべての利点を失う可能性があり、それを機能させるには独自のUI層を書き直す必要があります。
検索した結果、最も妥当な答えは次のとおりです。
MVCはすでにAndroidに次のように実装されています。
- View = layout、resources、そして
Buttonのような組み込みクラスはAndroid.view.Viewから派生したものです。 - コントローラー=活動
- モデル=アプリケーションロジックを実装するクラス
（ところで、これはアクティビティ内にアプリケーションドメインロジックがないことを意味します。）
小規模な開発者にとって最も合理的なことは、このパターンに従って、Googleがやらないと決めたことをやらないようにすることです。
PS Activityは時々再起動されるので、モデルデータのための場所はありません（再起動を引き起こす最も簡単な方法はXMLからAndroid:configChanges="keyboardHidden|orientation"を省略してデバイスをオンにすることです）。
編集
MVCについて話しているかもしれませんが、FMVC、Framework - Model - View - Controllerと言うのもそうでしょう。 Framework（Android OS）は、コンポーネントのライフサイクルとそれに関連するイベントという概念を課しています。実際には、Controller（Activity/Service/BroadcastReceiver）最初にこれらのFrameworkインポーズイベント（onCreate（）など）に対処する責任があります。ユーザー入力は別々に処理されるべきですか？たとえそれがあったとしても、あなたはそれを分離することはできません、ユーザー入力イベントはまたAndroidから来ます。
とにかく、あなたがあなたのActivity/Service/BroadcastReceiverに入れた、Android固有ではないコードが少ないほど良いです。
あなたが従うことができる単一のMVCパターンはありません。 MVCは多かれ少なかれあなたがデータとビューを混ぜるべきではないと述べています。ビューは、データを保持しているか、データを処理しているクラスがビューに直接影響しているかを保持します。
それにもかかわらず、Androidがクラスやリソースを扱う方法では、MVCパターンに従うことを余儀なくされることさえあります。私の考えではもっと複雑なのは、その見解に対して責任を負うことがありますが、それにもかかわらず同時にコントローラーとして機能する活動です。
XMLファイルでビューとレイアウトを定義する場合は、resフォルダーからリソースをロードします。コード内でこれらのことを混同しないようにするには、MVCパターンに従う必要があります。
AndroidにMVCを実装することはできますが、「ネイティブにサポートされる」わけではなく、ある程度の努力が必要です。
とは言っても、私は個人的にはAndroid開発のためのはるかにクリーンなアーキテクチャー・パターンとして MVP を好む傾向があります。そしてMVPを言うことによって私はこれを意味します：
私はより詳細な回答を投稿しました here 。
AndroidでMVC/MVPを実装するためのさまざまなアプローチを試した後、私はこの投稿で説明した合理的な建築パターンを思いつきました： AndroidにおけるMVPおよびMVC建築パターン 。
私がAndroidにMVCを実装するために見つけた最高のリソースは この記事 ：です。
私は自分のプロジェクトでも同じデザインを採用しましたが、とてもうまくいきました。私はAndroidの初心者なので、これが最善の解決策であるとは言えません。
1つ修正を加えました。横長/縦モードが変更されたときにこれらが再作成されないように、アプリケーションクラスの各アクティビティに対してモデルとコントローラーをインスタンス化しました。
私はJDPeckhamに同意します。そして、XMLだけではアプリケーションのUI部分を実装するのに十分ではないと思います。
ただし、アクティビティをビューの一部と見なすと、MVCの実装は非常に簡単です。 Application を（ActivityのgetApplication（）から返されるように）オーバーライドすることができます。アプリケーションの存続期間中存続するコントローラを作成できるのは、ここからです。
（あるいは、アプリケーションの資料に示されているように、シングルトンパターンを使用することもできます）
レイアウト、リソース、アクティビティ、および目的を使用したAndroid UIの作成は、MVCパターンの実装です。これについて詳しくは、次のリンクを参照してください - http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf
Android上のMVC-アーキテクチャ AndroidではMVCではなくMVPに従うほうがよいが、それでも問題に対する答えによればこれは解決策となり得る
説明とガイドライン
Controller -
Activity can play the role.
Use an application class to write the
global methods and define, and avoid
static variables in the controller label
Model -
Entity like - user, Product, and Customer class.
View -
XML layout files.
ViewModel -
Class with like CartItem and owner
models with multiple class properties
Service -
DataService- All the tables which have logic
to get the data to bind the models - UserTable,
CustomerTable
NetworkService - Service logic binds the
logic with network call - Login Service
Helpers -
StringHelper, ValidationHelper static
methods for helping format and validation code.
SharedView - fragmets or shared views from the code
can be separated here
AppConstant -
Use the Values folder XML files
for constant app level
注1：
今ここにあなたがすることができる魔法のかけらがあります。コードを分類したら、IEntityやIServiceのような基本インターフェースクラスを書きます。一般的な方法を宣言します。抽象クラスBaseServiceを作成し、独自のメソッドセットを宣言してコードを分離します。
注2： アクティビティが複数のモデルを提示している場合は、アクティビティ内にコードやロジックを記述するよりも、ビューをフラグメントに分割する方が良いでしょう。それがいいです。そのため、将来、ビューに表示するためにさらにモデルが必要になった場合は、フラグメントをもう1つ追加します。
注3： コードの分離は非常に重要です。アーキテクチャ内のすべてのコンポーネントは、依存ロジックを持たずに独立している必要があります。もしあなたが何か依存ロジックを持っているのなら偶然ならば、その間にマッピングロジッククラスを書いてください。これは将来あなたを助けます。
この記事は古くなっているようですが、以下の2つを追加して、Android用のこの分野における最近の開発についてお知らせします。
Android-binding - Androidビューウィジェットのデータモデルへのバインドを可能にするフレームワークを提供します。 AndroidアプリケーションでMVCまたはMVVMパターンを実装するのに役立ちます。
roboguice - RoboGuiceは当て推量を開発から除外します。ビュー、リソース、システムサービス、またはその他のオブジェクトを挿入して、RoboGuiceに詳細を確認させます。
AndroidのMVCパターンは（一種の）それらの アダプタ クラスで実装されています。コントローラを「アダプタ」に置き換えます。アダプターの説明には、次のように記載されています。
Adapterオブジェクトは、AdapterViewとそのビューの基になるデータとの間のブリッジとして機能します。
データベースから読み取るAndroidアプリケーションを探しているだけなので、まだうまく機能していません。しかし、これはQtのModel-View-Delegateアーキテクチャに少し似ているように見えます。これは、従来のMVCパターンからのステップアップだと主張しています。少なくともPCでは、Qtのパターンはかなりうまくいきます。
モデルビューコントローラ（MVC）
説明：
- ソフトウェア開発で大規模プロジェクトを主導する必要がある場合は、MVCが一般的に使用されます。これは、プロジェクトを体系化するための普遍的な方法だからです。
- 新しい開発者はすぐにプロジェクトに適応できます
- 大規模プロジェクトやクロスプラットフォームの開発にも役立ちます。
MVCパターンは基本的にこれです：
- モデル：表示するものこれはデータソースになることができます（例：サーバー、アプリ内の生データ）
- 表示：表示方法これはxmlにすることができます。そのため、プレゼンテーションフィルタとして機能しています。ビューはそのモデル（またはモデル部分）に添付されており、プレゼンテーションに必要なデータを取得します。
- コントローラ：ユーザ入力のようなイベント処理これが活動
MVCの重要な機能： モデルやビュー、コントローラのいずれかを変更しても他のものには影響しない _
- ビューの色、ビューのサイズ、またはビューの位置を変更したとします。そうしても、モデルやコントローラには影響しません
- モデルを変更したとします（サーバーから取得したデータを資産から取得したデータではなく）が、ビューやコントローラには影響しません。
- モデルとビューに影響を与えないコントローラ（アクティビティ内のロジック）を変更したとします。
私は最も便利で簡単な説明がここにあると思います： http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf
私がここで見て読んだ他のすべてのことから、これらすべてを実装することはそれを難しくし、Androidの他の部分とうまく合いません。
アクティビティに他のリスナーを実装させることは、すでにAndroidの標準的な方法です。最も無害な方法は、スライドがonClickやその他の種類のアクションを記述し、まだアクティビティ内にある関数にグループ化するように、Java Observerを追加することです。
Androidの方法は、アクティビティが両方を実行することです。それと戦っても、将来のコーディングを拡張したり実行したりすることが実際には容易になるわけではありません。
第2の投稿 に同意する。これは、すでに実装されているようなもので、人々が慣れ親しんでいる方法ではありません。同じファイルにあるかどうかにかかわらず、すでに分離があります。他の言語やOSに適合させるために特別な分離を作成する必要はありません。
AndroidでのMVxの災害にうんざりしている私は最近、単方向のデータフローを提供し、MVCの概念に似た小さなライブラリを作りました。 https://github.com/zserge/anvil
基本的には、コンポーネント（アクティビティ、フラグメント、ビューグループ）があります。内部では、ビューレイヤの構造とスタイルを定義します。また、データをビューにバインドする方法も定義します。最後に、リスナーを同じ場所にバインドできます。
その後、データが変更されると、グローバルな "render（）"メソッドが呼び出され、ビューは最新のデータでスマートに更新されます。
これは、コードをコンパクトにするためにすべてを内部に持つコンポーネントの例です（もちろんModelとControllerは簡単に分離できます）。ここで "count"はモデル、view（）メソッドはビュー、そして "v - > count ++"はボタンクリックを監視してモデルを更新するコントローラです。
public MyView extends RenderableView {
public MyView(Context c) {
super(c);
}
private int count = 0;
public void view() {
frameLayout(() -> { // Define your view hierarchy
size(FILL, WRAP);
button(() -> {
textColor(Color.RED); // Define view style
text("Clicked " + count); // Bind data
onClick(v -> count++); // Bind listeners
});
});
}
分離されたモデルとコントローラでは、それは次のようになります。
button(() -> {
textColor(Color.RED);
text("Clicked " + mModel.getClickCount());
onClick(mController::onButtonClicked);
});
ここで各ボタンをクリックすると数が増え、それから "render（）"が呼ばれてボタンのテキストが更新されます。
Kotlinを使用すると、構文がより快適になります。 http://zserge.com/blog/anvil-kotlin.html 。また、ラムダのないJavaの代替構文もあります。
ライブラリ自体は非常に軽量で、依存関係はなく、リフレクションも使用しませんなど。
（免責事項：私はこの図書館の作者です）
ここの投稿のどれもが質問に答えなかったことに驚いた。それらは一般的すぎるか、曖昧であるか、間違っているか、Androidの実装に対応していません。
MVCでは、Viewレイヤーはユーザーインターフェイス（UI）の表示方法のみを知っています。これにデータが必要な場合、Modelレイヤーから取得します。ただし、ビューはモデルに直接データを検索するよう要求するのではなく、Controllerを使用して実行します。 ControllerはModelを呼び出して、Viewに必要なデータを提供します。データの準備ができると、ControllerはViewにModelからデータを取得する準備ができたことを通知します。これで、ViewはModelからデータを取得できます。
このフローは次のように要約できます。
ViewがController-として知られているModelでデータの可用性について知ることができることは注目に値しますパッシブMVC -またはModelのデータを監視することにより、オブザーバブルを Active MVC に登録します。
実装の部分では、最初に思い浮かぶことの1つは、どのAndroidコンポーネントをView？に使用すべきかということです。 ActivityまたはFragment？
答えは重要ではなく、両方を使用できるということです。 Viewは、デバイスにユーザーインターフェイス（UI）を表示し、ユーザーのUIとの対話に応答できる必要があります。 ActivityとFragmentの両方が、これに必要なメソッドを提供します。
この記事 で使用されているサンプルアプリでは、ViewレイヤーにActivityを使用していますが、Fragmentも使用できます。
完全なサンプルアプリは、GitHubリポジトリの 'mvc'ブランチにあります here 。
また、例 here を使用して、AndroidのMVCアーキテクチャの長所と短所も扱っています。
興味のある方のために、Androidアプリアーキテクチャに関する一連の記事を開始しました ここ では、Androidアプリ開発用の異なるアーキテクチャ、つまりMVC、MVP、MVVMを比較しています完全に機能するアプリを通じて。
実装されたMVCアーキテクチャーはありませんが、MVP（モデル - ビュー - プレゼンター）アーキテクチャーを実装するための一連のライブラリー/例があります。
リンクを確認してください。
Googleは、AndroidアーキテクチャMVPの例を追加しました。
MVCはすでにAndroidに実装されていると多くの人が言っていることを私は見てきましたが、そうではありません。 AndroidはデフォルトでMVCに従いません。
私はGoogleがiPhoneのようなMVC実装の制限を強制的に課すことは決してありませんが、プロジェクトに必要なパターンやテクニックを開発者に課しています。成長して複雑になり、後の年にそのコードの修正が必要になると、AndroidでMVCパターンが必要になります。
それはコードを修正する簡単な方法を提供し、また問題の減少を助けます。あなたがAndroid上でMVCを実装したい場合は、リンクをクリックしてあなたのプロジェクトでMVCの実装を楽しんでください。
http://www.therealjoshua.com/2011/11/Android-architecture-part-1-intro/ /
しかし、最近では、MVPとAndroid Architectural Patternは、クリーンで堅牢なAndroidアプリケーションのために開発者が使うべき最良の選択肢の1つであると思います。
説明 によると、Xamarinチームは次のように説明しています。
- モデル（データまたはアプリケーションロジック）
- ビュー（ユーザーインターフェース）
- コントローラー（分離コード）.
私はこれを言うことができます：
Androidのモデルは、単に解析可能なオブジェクトです。ビューはXMLレイアウトであり、コントローラは（アクティビティ+そのフラグメント）です。
*これは私の意見です。リソースや本からのものではありません。
MVC、 _ mvvm _ 、または Presentation Model をAndroidアプリに適用する場合、明確に構造化されたプロジェクトを作成し、単体テストをより簡単にすることが本当に必要です。
現時点では、サードパーティのフレームワークがなければ、通常はビジネス上の価値を付加することのない多くのコード（addXXListener（）、findViewById（）など）があります。
さらに、通常のJUnitテストの代わりにAndroid単体テストを実行する必要があります。このテストは実行に時間がかかり、単体テストがやや実用的でなくなります。これらの理由から、数年前にオープンソースプロジェクト、 RoboBinding - Androidプラットフォーム用のデータバインディングプレゼンテーションモデルフレームワークを開始しました。
RoboBindingは、読みやすく、テストし、そして保守しやすいUIコードを書くのに役立ちます。 RoboBindingはaddXXListenerやsoのような不要なコードを不要にし、POロジックである通常のJUnitテストを介してテスト可能なPresentation Model）にUIロジックを移行します。その品質を確保するために。
私の理解では、AndroidがMVCパターンを処理する方法は次のようになります。
あなたはコントローラーとして機能するアクティビティを持っています。あなたにはデータを取得する責任があるクラス - モデル - があります、そしてあなたにはビューであるViewクラスがあります。
このビューについて話すとき、ほとんどの人はxmlで定義されている視覚的部分についてだけ考えています。ビューには、Javaクラスで定義されたコンストラクタ、メソッドなどを含むプログラム部分もあることを忘れないでください。