インタラクターとは何ですか? MVPデザインにどのように適合しますか?インタラクターを使用することと、プレゼンターにインタラクターコードを配置することの利点/欠点は何ですか?
MVPは、Godアクティビティの問題(行が多すぎるアクティビティ/フラグメント)に取り組むために存在します。
必須ではありませんでしたが(必要なパターンでコーディングできます)、多くの開発者はMVPがAndroidに適していることに同意しています。これにより、ソースコードがよりクリーンになり、テスト可能になり、保守しやすくなり、堅牢になります。
インタラクターは「モデル/コントローラー」と考えることができます。インタラクターは、データベース、Webサービス、またはその他のデータソースからデータを取得します。データを取得した後、インタラクターはデータをプレゼンターに送信します。したがって、UIを変更します。
別のクラスでインタラクターを使用する利点は、クラスを分離するため、クラスがよりクリーンでテスト可能になることです。確かに、プレゼンターの内部クラスにインタラクターを配置することはできますが、ポイントは何ですか?プレゼンターにインタラクターを配置することの欠点は、プレゼンタークラスが大きくなり、読み取りと管理が比較的難しくなることです。
更新:もちろんこれは単純化しすぎです。もっと深く掘り下げたい場合は、 fernando cejas blog または antonio leiva blog
Interactorは、ドメインレイヤーとプレゼンテーションレイヤーを分離するクラスです。簡単に言えば、UIの操作に使用されるコードとは別にビジネスロジックを記述する方法を提供します(データをUI /アニメーション/ナビゲーションにバインドすることにより)。
したがって、Interactorは、Presenter/ViewModelとRepositoryパターンの間の仲介者です。
MVPではInteractorパターンを使用していませんが、MVVMでは使用しています。インタラクターは、ユースケースに交換可能に使用できます。
たとえば、カテゴリを取得してリストに表示するユースケースを見てみましょう(以下の例では、PresenterはMVPを表し、ViewModelはMVVMパターンを表します)。
このプロセスではInteractorを回避できるため、このようなデータフローを使用する代わりにRepository-> Interactor-> Presenter/ViewModelで通信できることに注意してくださいこのようにRepository-> Presenter/ViewModelが発生しました。ここで、Presenter/ViewModelは、プレゼンテーションおよびドメインレイヤーの一部になります。前述したように、Interactorはこれら2つのレイヤーのセパレーターとして機能します。
これらは、参考のためにこの概念を説明するために簡潔に書かれたブログです
これが、Interactorの役割をよりよく理解するのに役立つことを願っています。ハッピーコーディング!!!
Interactorにはアプリケーションのユースケースが含まれています。つまり、プロジェクトのビジネスドメインのすべての実装が含まれます。
MVPパターンを使用したAndroidアプリケーションのアーキテクチャ に関する非常によく整理された記事を以下に示します。これを勉強することを強くお勧めします。
また、MVPパターンとInstagram APIを使用して、JuicyInstaというAndroidアプリケーションを作成しました- githubで共有されています
個人的には、モデルとは異なるView、Present、Interactorを使用しています。
データベース、サーバーなどからデータを取得する便利なメソッドを持つクラスとしてのインタラクターについて考えることができます。データを取得したら、Interactorにモデルを入力し、それを発表者に返すことができます。
例えば。 Asynctaskを作成してユーザーを認証し、受信したデータをUserModelに入力するLoginInteractorを使用できます。