☰

Android ではどのアーキテクチャ パターンが使用されていますか? [closed] 質問する

tag-icon • tag-icon android design-patterns
Android ではどのアーキテクチャ パターンが使用されていますか? [closed] 質問する

モバイル プラットフォームについて少し調査しているのですが、Android ではどのようなデザイン パターンが使用されているのかを知りたいです。

たとえば、iOS では、モデル ビュー コントローラーは委任やその他のパタ​​ーンとともに広く使用されています。

Android では具体的にどのようなパターンがどこで使用されますか?

編集

私が尋ねているのは、カーネルや dalvik などで深く使用されている設計パターンではなく、アプリケーション開発者がアプリケーションを開発する際に遭遇するパターンについてです。

ベストアンサー1

私は、Android 開発を行うために、モデル - ビュー - コントローラ(MVC) とモデル - ビュー - プレゼンターの両方のアーキテクチャ パターンを使用しようとしました。私の調査結果では、モデル - ビュー - コントローラは問題なく動作しますが、いくつかの「問題」があります。すべては、Android クラスをどのように認識するかにかかっていますActivity。それはコントローラでしょうか、それともビューでしょうか?

実際のActivityクラスは Android のViewクラスを拡張するものではありませんが、ユーザーへのウィンドウの表示を処理し、そのウィンドウのイベント (onCreate、onPause など) も処理します。

つまり、MVC パターンを使用している場合、コントローラーは実際には疑似ビュー コントローラーになります。setContentView を使用して追加した追加のビュー コンポーネントを使用して、ユーザーへのウィンドウの表示を処理し、少なくともさまざまなアクティビティ ライフ サイクル イベントのイベントも処理します。

MVC では、コントローラーがメインのエントリ ポイントになるはずです。アクティビティはほとんどのアプリケーションの自然なエントリ ポイントであるため、これを Android 開発に適用する場合、これが当てはまるかどうかは多少議論の余地があります。

Because of this, I personally find that the model–view–presenter pattern is a perfect fit for Android development. Since the view's role in this pattern is:

  • Serving as a entry point
  • Rendering components
  • Routing user events to the presenter

This allows you to implement your model like so:

View - this contains your UI components, and handles events for them.

Presenter - this will handle communication between your model and your view, look at it as a gateway to your model. Meaning, if you have a complex domain model representing, God knows what, and your view only needs a very small subset of this model, the presenters job is to query the model and then update the view. For example, if you have a model containing a paragraph of text, a headline and a word-count. But in a given view, you only need to display the headline in the view. Then the presenter will read the data needed from the model, and update the view accordingly.

Model - this should basically be your full domain model. Hopefully it will help making your domain model more "tight" as well, since you won't need special methods to deal with cases as mentioned above.

By decoupling the model from the view all together (through use of the presenter), it also becomes much more intuitive to test your model. You can have unit tests for your domain model, and unit tests for your presenters.

Try it out. I personally find it a great fit for Android development.

おすすめ記事