Android VIPERジェット駆動

書かれたコードの行が多いほど、コードを複製する頻度が少なくなり、実装されるプロジェクトが増えるほど、古いものを頻繁に使用するようになりますが、愛されていても、熊手であり、建築ソリューションにますます興味を持ちます。



iOS開発者に非常に愛されているVIPERアーキテクチャテンプレートに出会うのは、Androidに次いで習慣的ではないと思います。また、Androidアプリケーションでこのようなテンプレートを不本意に使用し始めたことが突然判明するまで、このことについて近隣の部署から初めて耳を傾けました。



これはどうして起こるのでしょうか？ はい、非常に簡単です。 エレガントなアーキテクチャソリューションの検索はAndroidアプリケーションのずっと前から始まり、私のお気に入りでかけがえのないルールの1つは常に-プロジェクトをデータ、ドメイン、プレゼンテーションの3つの疎結合レイヤーに分割することでした。 そして今、もう一度、Androidアプリケーションのアーキテクチャパターンの新しいトレンドについてインターネットの広がりを調べたところ、素晴らしいソリューションに出くわしました： Android Clean Architecture 、ここで、私の謙虚な意見では、すべてが大丈夫でした：お気に入りのレイヤーへの分割、依存性注入、実装MVPとしてのプレゼンテーションレイヤー。使い慣れたデータレイヤーリポジトリテンプレートとしてよく使用されます。



しかし、長年愛されてきたデザインの手法に加えて、発見の場がありました。 Interactor（1つまたは複数のエンティティを操作するためのビジネスロジックを含むオブジェクト）の概念を紹介したのはこのプロジェクトであり、リアクティブプログラミングの力が明らかにされたのもここでした。



リアクティブプログラミング、特にrxJavaは 、過去1年間でかなり人気のあるレポートおよび記事のトピックです。したがって、この技術に簡単に慣れることができます（もちろん、これに精通していない場合を除きます）。VIPERについての話を続けます。



Android Clean Architectureの知識は、既存のプロジェクトのリファクタリングと同様に、新しいプロジェクトがrxJavaとMVPの 3つのレイヤーに削減され、Interactorsがドメインレイヤーとして使用されるようになったという事実につながりました。 画面間の遷移の正しい実装の問題は未解決のままであり、ここでルーターの概念はますます頻繁に聞こえるようになりました。 最初は、ルーターは孤独でメインアクティビティに住んでいましたが、アプリケーションに新しい画面が表示され、ルーターが非常に面倒になり、その後、別のアクティビティがそのフラグメントと共に表示され、ナビゲーションについて真剣に考えなければなりませんでした。 画面間の切り替えを含むすべての基本的なロジックはプレゼンターに含まれています。したがって、プレゼンターはルーターについて知る必要があり、ルーターは画面を切り替えるためにアクティビティにアクセスする必要があるため、ルーターは独自のものを持ち、各アクティビティに送信される必要があります作成時のプレゼンター。



そしてもう一度、プロジェクトを見ると、ビュー、インターアクター、プレゼンター、エンティティ、ルーターというVIPERがあることがわかりました。



オブザーバブル図に気づいたと思います。ジェット推進のすべての力が隠されています。 データレイヤーは、必要な表現でリモートストレージまたはローカルストレージからデータを取得するだけでなく、Observableにラップされた一連のアクション全体をInteractorに渡します。これにより、実装されているタスクに基づいて、このシーケンスを自由に続行できます。



次に、AndroidのVIPER実装の小さな例を見てみましょう（ ソース ）：

3秒ごとに「あまり柔軟性のない」サーバーにメッセージのリストを要求し、各送信者に対して後者を表示し、ユーザーに新しいメッセージを通知するアプリケーションを開発するタスクに直面しているとします。 最後のメッセージをタップすると、選択した送信者のすべてのメッセージのリストが表示されますが、メッセージは引き続き3秒ごとにサーバーと同期されます。 また、メイン画面から連絡先リストにアクセスして、そのうちの1つのメッセージをすべて表示できます。



それでは始めましょう。チャット（各連絡先からの最後のメッセージ）、特定の連絡先からのメッセージのリスト、連絡先のリストの3つの画面があります。 クラス図を投げます：







画面はフラグメントであり、その間の遷移は、ルーターインターフェイスを実装するアクティビティによって規制されます。 各フラグメントには独自のプレゼンターがあり、フラグメントと対話するために必要なインターフェースを実装します。 新しいプレゼンターとフラグメントの作成を容易にするために、基本的な抽象クラスBasePresenterとBaseFragmentが作成されました。



BasePresenter-ビューおよびルーターインターフェイスへのリンクが含まれ、フラグメントのライフサイクルを繰り返す2つの抽象メソッドonStartおよびonStopもあります。

public abstract class BasePresenter<View, Router> { private View view; private Router router; public abstract void onStart(); public abstract void onStop(); public View getView() { return view; } public void setView(View view) { this.view = view; } public Router getRouter() { return router; } public void setRouter(Router router) { this.router = router; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BaseFragment-BasePresenterで主な作業を実行します。初期化して対話インターフェイスをonActivityCreatedに渡し、対応するメソッドでonStartとonStopを呼び出します。



AndroidアプリケーションはすべてActivityで始まります。フラグメントが切り替えられるMainAcivityは1つだけです。







上記のように、ルーターはアクティビティ内に存在します。具体的な例では、MainActivityはそれぞれのアクティビティに対してインターフェイスを実装します。それぞれのルーターは、内部のフラグメント間のナビゲーションを制御します。したがって、そのようなアクティビティの各フラグメントには、同じルーターを使用するプレゼンターが必要です：これが、BaseMainPresenterが生まれた方法であり、MainActivityで作業するすべてのプレゼンターが継承する必要があります。

 public abstract class BaseMainPresenter<View extends BaseMainView> extends BasePresenter<View, MainRouter> { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MainActivityでフラグメントを変更すると、ツールバーとFloatingActionButtonの状態が変化するため、各フラグメントはアクティビティで必要な状態パラメーターを報告できる必要があります。 このような対話インターフェイスを実装するには、BaseMainFragmentを使用します。

 public abstract class BaseMainFragment extends BaseFragment implements BaseMainView { public abstract String getTitle(); //  Toolbar @DrawableRes public abstract int getFabButtonIcon(); // FloatingActionButton //    FloatingActionButton public abstract View.OnClickListener getFabButtonAction(); @Override public void onActivityCreated(Bundle savedInstanceState) { super.onActivityCreated(savedInstanceState); MainActivity mainActivity = (MainActivity) getActivity(); //   getPresenter().setRouter(mainActivity); // MainActivity    Toolbar  FloatingActionButton mainActivity.resolveToolbar(this); mainActivity.resolveFab(this); } @Override public void onDestroyView() { super.onDestroyView(); //    getPresenter().setRouter(null); } …. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BaseMainViewは、MainActivityでフラグメントを作成するためのもう1つの基本エンティティです;これは、MainActivityのすべてのプレゼンターが知っている対話インターフェイスです。 BaseMainViewを使用すると、エラーメッセージを表示してアラートを表示できます。このインターフェイスはBaseMainFragmentを実装します。

 ... @Override public void showError(@StringRes int message) { Toast.makeText(getContext(), getString(message), Toast.LENGTH_LONG).show(); } @Override public void showNewMessagesNotification() { Snackbar.make(getView(), R.string.new_message_comming, Snackbar.LENGTH_LONG).show(); } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような基本クラスの形式で準備を行うことで、MainActivityの新しいフラグメントを作成するプロセスが大幅に加速されます。



ルーター

そして、MainRouterの結果は次のとおりです。

 public interface MainRouter { void showMessages(Contact contact); void openContacts(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Interactractor

各プレゼンターは、1つ以上のインターアクターを使用してデータを操作します。 Interactorには、executeとunsubscribeの2つのパブリックメソッドしかありません。つまり、Interactorは、実行中のプロセスから起動およびサブスクライブ解除できます。

 public abstract class Interactor<ResultType, ParameterType> { private final CompositeSubscription subscription = new CompositeSubscription(); protected final Scheduler jobScheduler; private final Scheduler uiScheduler; public Interactor(Scheduler jobScheduler, Scheduler uiScheduler) { this.jobScheduler = jobScheduler; this.uiScheduler = uiScheduler; } protected abstract Observable<ResultType> buildObservable(ParameterType parameter); public void execute(ParameterType parameter, Subscriber<ResultType> subscriber) { subscription.add(buildObservable(parameter) .subscribeOn(jobScheduler) .observeOn(uiScheduler) .subscribe(subscriber)); } public void unsubscribe() { subscription.clear(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エンティティ

Interactorは、1つ以上のDataProviderを使用してデータにアクセスし、後続の実行のためにrx.Observableを生成します。



この例の問題ステートメントには、サーバーへの定期的な要求の必要性が含まれていました。これは、RXを使用して簡単に実装できました。

 public static long PERIOD_UPDATE_IN_SECOND = 3; @Override public Observable<List<Message>> getAllMessages(Scheduler scheduler) { return Observable .interval(0, PERIOD_UPDATE_IN_SECOND, TimeUnit.SECONDS, scheduler) .flatMap(this::getMessages); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコード例は、3秒ごとにメッセージのリストを要求し、サブスクライバーに通知を送信します。



おわりに

アーキテクチャはアプリケーションの骨組みであり、それを忘れると、異常な結果に終わる可能性があります。 レイヤーとクラスのタイプ間の責任の明確な分割により、サポート、テスト、プロジェクトへの新しい人の紹介が容易になり、プログラミングの統一スタイルが確立されます。 基本クラスはコードの重複を避けるのに役立ち、rxは非同期性を考慮しません。 理想的なアーキテクチャと理想的なコードは実際には達成できませんが、それらに努力することは専門的に成長することを意味します。



PS一連の記事を続けるためのアイデアがあり、実装の興味深い事例について詳しく説明します。

プレゼンテーション層-フラグメントの状態保存、複合ビュー。

ドメイン層-複数のサブスクライバーのインタラクター。

データ層-キャッシングの組織。

興味があれば、プラス記号を入れてください:)