AndroidのMVCパターン

AndroidのJavaでモデル、ビュー、コントローラーのパターンを実装することは可能ですか？

それとも、アクティビティによってすでに実装されていますか？または、AndroidにMVCパターンを実装するより良い方法はありますか？

AndroidにはMVCはありませんが、次のものがあります。

• 解像度、ハードウェアなどによって、さまざまなXMLファイルでユーザーインターフェイスを定義します。
• ロケールなどによって、さまざまなXMLファイルでリソースを定義します。
• ListActivity、TabActivityなどのクラスを拡張し、インフレーターでXMLファイルを利用します。
• ビジネスロジックに必要な数だけクラスを作成できます。
• Utilsの多くは既に作成されています-DatabaseUtils、Html。

普遍的にユニークなMVCパターンはありません。MVCは、堅固なプログラミングフレームワークというよりはコンセプトです。独自のMVCを任意のプラットフォームに実装できます。次の基本的な考え方に固執する限り、MVCを実装しています。

• モデル：何をレンダリングするか
• 表示：レンダリング方法
• コントローラー：イベント、ユーザー入力

また、このように考えてください。モデルをプログラムするとき、モデルはレンダリング（またはプラットフォーム固有のコード）について心配する必要はありません。モデルはビューに対して言うでしょう、あなたのレンダリングがAndroidかiOSかWindows Phoneかは気にしません、これは私があなたにレンダリングする必要があるものです。ビューは、プラットフォーム固有のレンダリングコードのみを処理します。

これは、クロスプラットフォームアプリケーションを開発するためにMonoを使用してモデルを共有する場合に特に便利です。

Androidのアクション、ビュー、およびアクティビティは、Android UIを操作するための組み込みの方法であり、モデル-ビュー-ビューモデル（MVVM）パターンの実装であり、モデル-ビュー（同じファミリー内）と構造的に類似しています-コントローラ。

私の知る限りでは、このモデルから抜け出す方法はありません。それはおそらく可能ですが、既存のモデルが持つすべての利点を失う可能性があり、それを機能させるために独自のUIレイヤーを書き直す必要があります。

いくつか検索した後、最も合理的な答えは次のとおりです。

MVCはすでにAndroidに次のように実装されています。

1. ビュー=レイアウト、リソース、および組み込みのようなクラスButtonから派生android.view.View。
2. コントローラー=アクティビティ
3. モデル=アプリケーションロジックを実装するクラス

（ちなみに、これはアクティビティにアプリケーションドメインロジックがないことを意味します。）

小規模な開発者にとって最も合理的なことは、このパターンに従い、Googleがしないと決めたことをしようとしないことです。

PSアクティビティは時々再起動されるので、モデルデータを置く場所がないことに注意してください（再起動を引き起こす最も簡単な方法はandroid:configChanges="keyboardHidden|orientation"、XML から省略してデバイスをオンにすることです）。

編集

私たちはMVCについて話しているかもしれませんが、FMVC、Framework--Model--View--Controllerと言えます。フレームワーク（アンドロイドOS）は、コンポーネントのライフサイクルと関連イベントのその考えを課し、そして実際にコントローラー（Activity/ Service/ BroadcastReceiver）これらに対応するための責任がすべての最初のあるフレームワークは、（のようなイベント-imposed のonCreate（）を）。ユーザー入力は個別に処理する必要がありますか？たとえそうであっても、分離することはできません。ユーザー入力イベントもAndroidから送信されます。

とにかく、Android固有ではないコードをActivity/ Service/ に挿入する回数が少ないほどBroadcastReceiver、優れています。

従うことができる単一のMVCパターンはありません。MVCは多かれ少なかれ、データとビューを混ぜてはならないことを述べているので、たとえばビューはデータを保持する責任があるか、データを処理しているクラスがビューに直接影響を与えています。

それにもかかわらず、Androidがクラスとリソースを処理する方法では、MVCパターンに従うことを余儀なくされることさえあります。私の意見ではさらに複雑なのは、ビューに責任があることもありますが、同時にコントローラーとして機能するアクティビティです。

XMLファイルでビューとレイアウトを定義し、resフォルダーからリソースをロードし、コード内でこれらの要素を混同しないようにする場合は、とにかくMVCパターンに従っていることになります。

AndroidにMVCを実装できますが、「ネイティブでサポート」されておらず、多少の努力が必要です。

とは言っても、私は個人的にはAndroid開発のアーキテクチャパターンとしてよりクリーンなMVPを好む傾向があります。そして、MVPと言うことで、私はこれを意味します：

ここにも詳細な回答を掲載しています。

AndroidでのMVC / MVP実装へのさまざまなアプローチを試した後、私はこの投稿で説明した合理的なアーキテクチャパターンを思いつきました。MVPとMVCのアーキテクチャパターンin Androidです。

AndroidにMVCを実装するために見つけた最高のリソースはこの投稿です。

私は自分のプロジェクトの1つに同じデザインを採用しましたが、うまくいきました。私はAndroidの初心者なので、これが最良のソリューションであるとは言えません。

変更を1つ加えました。アプリケーションクラスの各アクティビティのモデルとコントローラーをインスタンス化して、横向き/縦向きモードが変更されたときにこれらが再作成されないようにしました。

私はJDPeckhamに同意します。アプリケーションのUI部分を実装するには、XMLだけでは十分ではないと思います。

ただし、アクティビティをビューの一部と見なす場合、MVCの実装は非常に簡単です。Applicationを（ActivityのgetApplication（）によって返されるように）オーバーライドでき、アプリケーションの存続期間中存続するコントローラーを作成できます。

（または、アプリケーションのドキュメントで提案されているシングルトンパターンを使用できます）

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：コードの分離は非常に重要です。アーキテクチャのすべてのコンポーネントは、依存するロジックを持たずに独立している必要があります。万が一依存するロジックがある場合は、その間にマッピングロジッククラスを記述します。これは将来的に役立ちます。

レイアウト、リソース、アクティビティ、インテントを使用したAndroid UIの作成は、MVCパターンの実装です。詳細については、次のリンクを参照してください-http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

PDFのミラー

AndroidのMVCパターンは（種類の）アダプタークラスで実装されています。コントローラを「アダプタ」に置き換えます。アダプターの説明は次のとおりです。

Adapterオブジェクトは、AdapterViewとそのビューの基になるデータの間のブリッジとして機能します。

私はデータベースから読み取るAndroidアプリケーションについてこれを調べているだけなので、まだどの程度うまく機能するのかわかりません。ただし、QtのModel-View-Delegateアーキテクチャに少し似ているようで、従来のMVCパターンからのステップアップであると彼らは主張しています。少なくともPCでは、Qtのパターンはかなりうまくいきます。

この投稿は古いようですが、次の2つを追加して、Androidに関するこの領域の最近の開発についてお知らせします。

android-binding -Androidビューウィジェットのデータモデルへのバインディングを実現するフレームワークを提供します。AndroidアプリケーションにMVCまたはMVVMパターンを実装するのに役立ちます。

roboguice -RoboGuiceは、推測から解放されます。ビュー、リソース、システムサービス、またはその他のオブジェクトを挿入し、RoboGuiceに詳細を処理させます。

モデルビューコントローラー（MVC）

説明：

• ソフトウェア開発で大規模なプロジェクトをメインにする必要がある場合、MVCはプロジェクトを組織化する普遍的な方法であるため、一般的に使用されます。
• 新しい開発者はプロジェクトにすばやく適応できます
• 大きなプロジェクトやクロスプラットフォームの開発にも役立ちます。

MVCパターンは基本的に次のとおりです。

• モデル：何を表示するか。これはデータソースにすることができます（例：サーバー、アプリ内の生データ）
• 表示：表示方法。これはxmlにすることができます。したがって、プレゼンテーションフィルターとして機能します。ビューはそのモデル（またはモデルパーツ）にアタッチされ、プレゼンテーションに必要なデータを取得します。
• コントローラー：ユーザー入力のようなイベントの処理。これは活動です

MVCの重要な機能： モデル、ビュー、コントローラーのいずれかを変更できますが、他のモデルには影響しません

• ビューの色、ビューのサイズ、またはビューの位置を変更するとします。そうすることで、モデルやコントローラに影響を与えません
• （サーバーからデータをフェッチしてアセットからデータをフェッチするのではなく）モデルを変更するとしますが、それでもビューとコントローラーには影響しません
• コントローラ（アクティビティのロジック）を変更するとします。モデルやビューには影響しません。

最も便利な簡略化された説明はここにあると思います：http : //www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

私がここで見たり読んだりしたすべての他のものから、これらすべてのものを実装することは困難になり、Androidの他の部分とうまく適合しません。

アクティビティに他のリスナーを実装させることは、すでにAndroidの標準的な方法です。最も無害な方法は、スライドのようにJavaオブザーバーを追加して、onClickおよびその他のタイプのアクションをまだアクティビティ内にある関数にグループ化することです。

Androidの方法は、アクティビティが両方を行うことです。それと戦っても、将来のコーディングを拡張したり実行したりすることは本当に簡単にはなりません。

二番目の投稿に同意します。これは、人々が慣れ親しんでいる方法ではなく、すでに実装されているようなものです。同じファイルにあるかどうかにかかわらず、すでに分離されています。他の言語やOSに適合させるために追加の分離を作成する必要はありません。

ここの投稿のどれも質問に答えなかったのを見て驚いた。一般的すぎる、漠然とした、正しくない、またはAndroidでの実装に対応していない。

MVCでは、ビューレイヤーはユーザーインターフェイス（UI）の表示方法のみを認識します。これにデータが必要な場合は、モデルレイヤーから取得します。ただし、ビューはデータを見つけるようにモデルに直接要求するのではなく、コントローラーを介して行います。したがって、コントローラー  はモデルを呼び出して、ビューに必要なデータを提供します。データの準備ができると、コントローラーはデータをモデルから取得する準備ができたことをビューに通知します。これで、ビューはモデルからデータを取得できます。

このフローは次のように要約できます。

ビューは 、コントローラー（パッシブMVCとも呼ばれ  ます）を介して、またはモデルにオブザーバブルを登録することでモデル内のデータを監視することによって、モデル内のデータの可用性を知ることができることに  注意してください。アクティブMVCです。

実装の部分で最初に頭に浮かぶのは、どのAndroidコンポーネントをViewに使用するべきかということです。Activity  またはFragment ？

答えはそれは問題ではなく、両方を使用できるということです。ビューは、 UIとのユーザの対話にデバイスと応答のユーザーインターフェイス（UI）を提示することができるはずです。両方Activity  とFragment  、このために必要なメソッドを提供します。

この記事で使用するアプリの例Activity では、Viewレイヤーに使用しましたが、使用するFragment  こともできます。

完全なサンプルアプリは、こちらの GitHubリポジトリの「mvc」ブランチにあります。

ここでの例を通して、AndroidでのMVCアーキテクチャの長所と短所についても取り上げました。

興味のある方のために、Androidアプリのアーキテクチャに関する一連の記事をここから始めました。そこでは、完全な動作するアプリを通じてAndroidアプリの開発のために、MVC、MVP、MVVMなどのさまざまなアーキテクチャを比較します。

AndroidでのMVx災害にうんざりしている私は最近、単方向のデータフローを提供し、MVCの概念に似た小さなライブラリを作成しました：https : //github.com/zserge/anvil

基本的に、コンポーネント（アクティビティ、フラグメント、およびビューグループ）があります。内部では、ビューレイヤーの構造とスタイルを定義します。また、データをビューにバインドする方法も定義します。最後に、リスナーを同じ場所にバインドできます。

次に、データが変更されると、グローバルな「render（）」メソッドが呼び出され、ビューが最新のデータでスマートに更新されます。

コードのコンパクト化のためにすべてが内部にあるコンポーネントの例を次に示します（もちろん、モデルとコントローラーは簡単に分離できます）。ここで、「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の代替構文もあります。

ライブラリ自体は非常に軽量で、依存関係がなく、リフレクションを使用していません。

（免責事項：私はこのライブラリの作成者です）

Xamarinチームが説明した説明によると（iOS MVCで「奇妙なようですが、少しお待ちください」）：

• モデル（データまたはアプリケーションロジック）、
• ビュー（ユーザーインターフェイス）、および
• コントローラ（コードビハインド）。

私はこれを言うことができます：

Androidのモデルは、単にパーセル可能なオブジェクトです。ビューはXMLレイアウトで、コントローラーは（アクティビティ+そのフラグメント）です。

*これは私の意見であり、リソースや本からではありません。

実装されたMVCアーキテクチャはありませんが、MVP（モデル-ビュー-プレゼンター）アーキテクチャを実装するためのライブラリ/サンプルのセットが存在します。

以下のリンクを確認してください：

• https://github.com/sockeqwe/mosby

• https://github.com/android10/Android-CleanArchitecture

• https://github.com/antoniolg/androidmvp

GoogleはAndroidアーキテクチャMVPの例を追加しました：

• https://github.com/googlesamples/android-architecture

多くの人がMVCがすでにAndroidに実装されていると言っているのを見てきましたが、それは事実ではありません。デフォルトでは、AndroidはMVCに従いません。

私はGoogleがiPhoneのようなMVC実装の制限を強制的に課すことはないので、プロジェクトで必要なパターンまたは技術を開発者に委ねています。小規模または単純なアプリケーションでは、MVCの使用は必須ではありませんが、アプリケーションとして成長して複雑になり、後年にコードの変更が必要になると、AndroidでMVCパターンが必要になります。

コードを修正する簡単な方法を提供し、問題の削減にも役立ちます。AndroidにMVCを実装したい場合は、以下のリンクに従って、プロジェクトでMVC実装を楽しんでください。

http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/

しかし最近では、MVPとAndroid Architectural Patternは、開発者がクリーンで堅牢なAndroidアプリケーションに使用する最良のオプションの1つだと思います。

MVC、MVVM、またはプレゼンテーションモデルをAndroidアプリに適用する場合、私たちが本当に望んでいるのは、明確な構造化プロジェクトを用意し、ユニットテストをより簡単に行えるようにすることです。

現時点では、サードパーティのフレームワークがなければ、通常、ビジネス価値を追加しない多くのコード（addXXListener（）、findViewById（）など）があります。

さらに、通常のJUnitテストの代わりにAndroidユニットテストを実行する必要があります。これにより、実行に時間がかかり、ユニットテストがやや実用的でなくなります。これらの理由により、数年前にオープンソースプロジェクトであるRoboBinding -Androidプラットフォーム向けのデータバインディングプレゼンテーションモデルフレームワークを開始しました。

RoboBindingを使用すると、読み取り、テスト、保守が容易なUIコードを作成できます。RoboBindingは、addXXListenerなどの不要なコードの必要性をなくし、UIロジックをPOJOであり、通常のJUnitテストでテストできるプレゼンテーションモデルにシフトします。RoboBinding自体には、その品質を保証するために300を超えるJUnitテストが付属しています。

私の理解では、AndroidがMVCパターンを処理する方法は次のようになります。

コントローラーとして機能するアクティビティがあります。データを取得する責任があるクラス（モデル）があり、次にビューであるViewクラスがあります。

ビューについて話すとき、ほとんどの人はxmlで定義されたその視覚的な部分についてのみ考えます。ビューには、Javaクラスで定義されたコンストラクター、メソッドなどを備えたプログラムパーツがあることを忘れないでください。