長い間、私はRxPMパターンについて考えており、「プロダクション」でそれをうまく適用しさえしていました。 私はこのトピックについて最初にMobiusと話す予定でしたが、プログラム委員会は拒否したので、Androidコミュニティと新しいパターンのビジョンを共有するための記事を今公開しています。

誰もがMVPとMVVMに精通していますが、MVVMがプレゼンテーションモデルパターンの論理的な開発であることを知っている人はほとんどいません。 結局、MVVMとPMの唯一の違いは、自動データバインディング（ databinding ）です。

この記事では、リアクティブビニングを使用したプレゼンテーションモデルパターンに焦点を当てます。 誤ってRxMVVMと呼ぶ人もいますが、これはプレゼンテーションモデルテンプレートの修正であるため、RxPMと呼ぶのが正しいでしょう。

このパターンは、 Rxを使用するプロジェクトで使用すると便利です。これにより、アプリケーションの応答性が向上するためです。 また、他のパターンの問題は多くありません。 次の図は、プレゼンテーションテンプレートのさまざまなオプションと分類を示しています。

RxPMパターンの説明に進む前に、最も人気のあるMVP（パッシブビュー）とMVVMを見てみましょう。 すべてのパターンとその違いの詳細な説明は、前の記事に記載されています 。

MVP vs PM vs MVVM

パターンの一般的なパターンは、ダイアグラムの形式で表すことができます。

一見したところ、基本的な違いはないように思えるかもしれません。 しかし、これは一見しただけです。 違いは、再販業者の責任と、ビューとの通信方法にあります。 モデルはすべてのパターンで同じに見えます。 その設計は複雑で広範なトピックであるため、ここでは説明しません。 最も一般的なパターンであるパッシブビューのMVPから始めましょう。 その主な問題を考慮してください。

MVP

従来のMVPでは、UIの状態を維持および復元する責任はViewにあります。 Presenterはモデルの変更のみを監視し、インターフェイスを介してビューを更新します。反対に、Viewからコマンドを受け取り、モデルを変更します。

ただし、モデルのデータ状態に加えて、複雑なインターフェイスを実装する場合、データに関連しない追加のUI状態があります。 たとえば、画面で強調表示されているリストアイテムや、入力フォームに入力されているデータ、ダウンロードプロセスの進行状況に関する情報、ネットワークへの要求などです。 ビューのUI状態の復元と保存は、ビューが「死ぬ」傾向があるため、大きな問題です。 また、ネットワーク要求に関する情報の表示は、基本的に保存できません。 ビューがプレゼンターから切断されている限り、リクエストはおそらく何らかの結果で終了します。

したがって、UIの状態を復元する作業はプレゼンターに送信されます。 これには、プレゼンターの現在の状態に追加のデータとフラグを保存し、ビューがアタッチされるたびにそれを再生する必要があります。

2番目の問題は、たとえば画面が回転しているときなど、Viewをプレゼンターからいつでも切断できるという同じ条件に起因します。 したがって、プレゼンターのViewインターフェイスへのリンクはリセットされます。 したがって、ビューを更新する必要がある場合は、常にnullチェックを実行する必要があります。 これは非常に面倒で、コードが煩雑になります。

3番目の問題：Viewインターフェースはできるだけ馬鹿げているはずなので、Viewインターフェースをある程度詳細に記述する必要があります。 また、プレゼンターは、ビューを目的の状態にするために多くのメソッドを呼び出す必要があります。 これにより、コードの量が増えます。

午後

Martin Fowlerが説明した Presentation Modelと呼ばれる別のパターンがあります。 このパターンの本質は、「プレゼンテーションモデル」と呼ばれる、UIの状態を格納し、UIロジックを含む特別なモデルが導入されることです。 PresentationModelは、GUIフレームワークに依存しない抽象的なプレゼンテーションと見なされる必要があります。 PresentationModelは状態をプロパティとして保存し、Viewによって読み取られて画面に表示されます。 このパターンの主な問題は、PresentationModelとView状態の同期です。 「Observer」パターンを適用することで、これを自分で処理する必要があります。 ほとんどの場合、UI全体を更新しないように、各プロパティの変更を追跡する必要があります。 退屈で繰り返しの多いコードがたくさんあります。

MVVM

お気づきかもしれませんが、MVVMはプレゼンテーションモデルに非常によく似ています。 驚くべきことではありません、それはその開発だからです。 PresentationModelのみがViewModelと呼ばれ、ViewModelとView状態の同期は、自動データバインディング、つまりデータ化によって実行されます。 しかし、このパターンには欠陥がないわけではありません。 たとえば、アニメーションを「純粋に」実装したり、コードからビューを使用して何かを実行したりするのは問題です。 このことについては 、同僚のJeevuzの 記事を ご覧ください 。

しかし、上記のすべてのパターンの最も重要で決定的な欠点は、Viewと仲介者の相互作用が命令的なスタイルで実行されることです。 一方、目標はリアクティブアプリケーションを作成することです。 UIレイヤーは、特に動的インターフェイスでは、データフローのかなり大きなソースであり、モデルでの非同期作業にのみRxを使用するのは無意味です。

リアクティブプレゼンテーションモデル

プレゼンテーションモデルパターンの主な問題は、プレゼンテーションモデルとビューの間の状態の同期であることは既にわかっています。 明らかに、変更可能なことを通知できるプロパティである監視可能なプロパティを使用する必要があります。 RxJavaはこの問題を解決するのに役立ち、同時にリアクティブアプローチのすべての利点を得ることができます。

まず、パターンスキームを見てみましょう。次に、実装の詳細を理解します。

したがって、RxPMの重要な要素はリアクティブプロパティです。 Rx-propertyの役割の最初の候補はBehaviorSubjectです。 最後の値を保存し、サブスクライブするたびに値を渡します。

一般に、 サブジェクトは本質的に一意です。一方で、それらはObservableの拡張であり、他方では、Observerインターフェイスを実装します。 つまり、 サブジェクトをビューの発信データストリームとして使用でき、PresentationModelでは着信データストリームのコンシューマになります。

しかし、 被験者には私たちに受け入れられない欠陥があります。 Observableコントラクトでは、 onCompleteおよびonErrorイベントで終了できます 。 したがって、 サブジェクトが失敗した何かにサブスクライブされた場合、チェーン全体が停止します。 ビューはイベントの受信を停止し、再度サブスクライブする必要があります。 さらに、Rxプロパティは定義上、 onCompleteおよびonErrorイベントを送信できません。これは、ビューの単なるデータ（状態）ソースであるためです。 ここで、Jake Whartonが彼のRxRelayライブラリで救助に来ます。 彼なしで私たちは何をしますか？ リレー 」と記載された欠陥を欠いています。

武器庫には、いくつかのサブクラスがあります。

• BehaviorRelay-最後に受信した値を保存し、サブスクライブするたびに送信します。 状態の保存と変更に最適です。

  
  

• PublishRelayは単なる注目に値するものです。 Viewのコマンドまたはイベントに適しています。 たとえば、ダイアログを表示したり、アニメーションを開始したりします。 Viewからのコマンド（イベント）の受信にも使用されます。

  
  
• ReplayRelay-受信したすべてのアイテムをバッファに保存し、購読時にすべて再生します。 非常にまれにしか使用されませんが、複合条件に役立つ場合があります。 描画の例が思い浮かびます：線を引き、次に円を引きます。

ただし、 Relayの表示アクセスを直接提供することはできません。 誤ってプロパティに値を入力したり、Viewからコマンドを受信するように設計されたRelayをサブスクライブしたりする可能性があるためです。 したがって、プロパティをObservableとして提示し、ViewからのイベントリスナーをConsumerとして提示する必要があります。 はい、カプセル化にはさらに多くのコードが必要になりますが、一方で、プロパティの場所とコマンドの場所はすぐにわかります。 PresentationModel（pm）のダウンロードの進行状況の例：

 //State private val progress = BehaviorRelay.create<Int>() //    property val progressState: Observable<Int> = progress.hide() //    ,      fun progress(): Observable<Int> = progress.hide() //Action private val downloadClicks = PublishRelay.create<Unit>() //    property val downloadClicksConsumer: Consumer<Unit> = downloadClicks //    ,      fun downloadClicks(): Consumer<Unit> = downloadClicks 

状態とアクションを定義したので、ビューでのみそれらにアタッチできます。 これを行うには、別のJake Wortonライブラリ-RxBindingが必要です 。 彼はいつ寝ますか？

 pm.progressState.subscribe { progressBar.progress() } //    downloadButton.clicks().subscribe { pm.downloadClicksConsumer } //    PM 

適切なObservableがない場合は、 consumer.accept()呼び出すことができます-ウィジェットリスナーから直接。

 pm.downloadClicksConsumer.accept(Unit) 

そして今、実際に

次に、上記のすべてをヒープに収集し、例を使用して分析します。 PresentationModelの設計は、次の手順に分類できます。

1. ビューに保存する必要があるPresentationModelの状態（データ、ロードステータス、表示する必要があるエラーなど）を決定します。
2. ビューで発生する可能性のあるイベントを判別します。ボタンのクリック、入力フィールドへの入力など。
3. PresentationModelを作成する場合、Rxが許可するように、宣言型スタイルで状態、コマンド、およびモデルを関連付けます。
4. ビューをPresentationModelにバインドします。

たとえば、テキスト内の単語を見つけるタスクを考えてみましょう。

• 検索するテキストの入力フィールドがあります。
• 検索する単語/部分の入力フィールドがあります。
• ボタンをクリックして、検索を開始します。
• 検索中に進行状況を表示します。今回はボタンをブロックします。
• 回答を受け取った後、見つかった単語のリストを表示します。

インタラクターのファサードの背後に検索アルゴリズムを非表示にします。

 data class SearchParams(val text: String, val query: String) interface Interactor { fun findWords(params: SearchParams): Single<List<String>> } class InteractorImpl : Interactor { override fun findWords(params: SearchParams): Single<List<String>> { return Single .just(params) .map { (text, query) -> text .split(" ", ",", ".", "?", "!", ignoreCase = true) .filter { it.contains(query, ignoreCase = true) } } .subscribeOn(Schedulers.computation()) } } 

具体的な例では、SingleとRxがまったくなくてもかまいませんが、インターフェイスは均一に保ちます。 特に実際のアプリケーションでは、 Retrofitを介したネットワークへの要求があります。

次に、PresentationModelを設計します。

ビューの状態：見つかった単語のリスト、読み込みステータス、検索ボタンのアクティビティフラグ。 ボタンの有効状態はPresentationModelのロードフラグにバインドできますが、ビューの場合は個別のプロパティを提供する必要があります。 ビューのロードフラグにスナップするだけではどうですか？ ここでは、ロードと有効化という2つの状態があることを確認する必要がありますが、この場合、PresentationModelがそれらを接続していることが一致しました。 一般的な場合、それらは独立している場合があります。 たとえば、ユーザーが最小文字数を入力するまでボタンをロックする場合。

ビューからのイベント：テキストの入力、検索クエリの入力、ボタンのクリック。 ここではすべてが簡単です。テキストをフィルター処理し、テキストと検索文字列を1つのオブジェクトSearchParamsに結合します。 ボタンをクリックして、検索クエリを作成します。

コードでは次のようになります。

 class TextSearchPresentationModel { private val interactor: Interactor = InteractorImpl() // --- States --- private val foundWords = BehaviorRelay.create<List<String>>() val foundWordState: Observable<List<String>> = foundWords.hide() private val loading = BehaviorRelay.createDefault<Boolean>(false) val loadingState: Observable<Boolean> = loading.hide() val searchButtonEnabledState: Observable<Boolean> = loading.map { !it }.hide() // -------------- // --- UI-events --- private val searchQuery = PublishRelay.create<String>() val searchQueryConsumer: Consumer<String> = searchQuery private val inputTextChanges = PublishRelay.create<String>() val inputTextChangesConsumer: Consumer<String> = inputTextChanges private val searchButtonClicks = PublishRelay.create<Unit>() val searchButtonClicksConsumer: Consumer<Unit> = searchButtonClicks // --------------- private var disposable: Disposable? = null fun onCreate() { val filteredText = inputTextChanges.filter(String::isNotEmpty) val filteredQuery = searchQuery.filter(String::isNotEmpty) val combine = Observable.combineLatest(filteredText, filteredQuery, BiFunction(::SearchParams)) val requestByClick = searchButtonClicks.withLatestFrom(combine, BiFunction<Unit, SearchParams, SearchParams> { _, params: SearchParams -> params }) disposable = requestByClick .filter { !isLoading() } .doOnNext { showProgress() } .delay(3, TimeUnit.SECONDS) //      .flatMap { interactor.findWords(it).toObservable() } .observeOn(AndroidSchedulers.mainThread()) .doOnEach { hideProgress() } .subscribe(foundWords) } fun onDestroy() { disposable?.dispose() } private fun isLoading() = loading.value private fun showProgress() = loading.accept(true) private fun hideProgress() = loading.accept(false) } 

ビューの役割では、フラグメントがあります。

 class TextSearchFragment : Fragment() { private val pm = TextSearchPresentationModel() private var composite = CompositeDisposable() private lateinit var inputText: EditText private lateinit var queryEditText: EditText private lateinit var searchButton: Button private lateinit var progressBar: ProgressBar private lateinit var resultText: TextView override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) retainInstance = true //     pm.onCreate() } // ... onCreateView override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // ... init widgets onBindPresentationModel() } fun onBindPresentationModel() { // --- States --- pm.foundWordState .subscribe { if (it.isNotEmpty()) { resultText.text = it.joinToString(separator = "\n") } else { resultText.text = "Nothing found" } } .addTo(composite) pm.searchButtonEnabledState .subscribe(searchButton.enabled()) .addTo(composite) pm.loadingState .subscribe(progressBar.visibility()) .addTo(composite) // --------------- // --- Ui-events --- queryEditText .textChanges() .map { it.toString() } .subscribe(pm.searchQueryConsumer) .addTo(composite) inputText .textChanges() .map { it.toString() } .subscribe(pm.inputTextChangesConsumer) .addTo(composite) searchButton.clicks() .subscribe(pm.searchButtonClicksConsumer) .addTo(composite) //------------------ } fun onUnbindPresentationModel() { composite.clear() } override fun onDestroyView() { super.onDestroyView() onUnbindPresentationModel() } override fun onDestroy() { super.onDestroy() pm.onDestroy() } } //   RxKotlin /** * Add the disposable to a CompositeDisposable. * @param compositeDisposable CompositeDisposable to add this disposable to * @return this instance */ fun Disposable.addTo(compositeDisposable: CompositeDisposable): Disposable = apply { compositeDisposable.add(this) } 

GitHubで完全な例を見ることができます。

まとめると

新しいRxPMパターンに出会い、他のプレゼンテーションテンプレートの欠点を調べました。 しかし、MVPとMVVMがRxPMよりも悪いまたは優れているとはっきりと言いたくはありません。 私は、多くの人と同様に、そのシンプルさと率直さからMVPが大好きです。 また、レイアウト内のコードはアマチュアですが、MVVMは自動データバインディングに適しています。

しかし、動的なUIを備えた最新のアプリケーションには、多くのイベントコードと非同期コードがあります。 したがって、私の選択は、リアクティブアプローチとRxPMに傾いています。 Jake Wortonのプレゼンテーションからの言葉を引用します。なぜ私たちのアプリケーションはリアクティブでなければならないのでしょうか。

システム全体を同期的にモデル化できない限り、単一の非同期ソースは命令型プログラミングを中断します。
システム全体を同期的にシミュレートできない場合、非同期ソースが1つでも命令型プログラミングを中断します。

もちろん、RxPMには長所と短所の両方があります。

長所：

• Observableのリアクティブチェーンを壊さず、モデルからビューへ、またはその逆にストレッチすることはできません。 これにより、Viewとの必須の相互作用がなくなります。
• PresentationModelのロジックの宣言的な説明。
• PresentationModelはViewの抽象化であり、特定のウィジェットに関連付けられていません。
• ビューが添付されているかどうかを心配する必要はありません。 Rx-propertyの値を変更するだけです。 ビューは、サブスクライブすると自動的に状態を受け取ります。
• ビューからイベントをリアクティブスタイルで取得します。Rx演算子を使用してフィルタリング、結合などを行うと便利です。

短所：

• バインディングコードを記述する必要がありますが、Rxでは簡単です。
• Relayをカプセル化し、View as Observable and Consumerとして表示する必要があります。 これは今のところ私を悩ます唯一のものです。
• Rxの豊富さ。 マイナスとプラスの両方と考えることができます。 反応性は別のパラダイムであるため、Rxの使用を開始するときに、それをあらゆる場所で使用しなければならないことは驚くことではありません。 Javaでプログラミングする場合、多くのオブジェクトをだます人はいません。これがOOPパラダイムです。

これはおそらく完全なリストではありません。 あなたが見る賛否両論をコメントに書いてください。あなたの意見を知ることは興味深いでしょう。

したがって、Rxに自信があり、リアクティブアプリケーションを作成する場合、databindingを使用したMVPおよびMVVMにうんざりしている場合は、RxPMを試してください。 まあ、あなたがすでに快適であれば、私はあなたを説得しません;）

PS

洗練されたAndroid開発者は、ライフサイクルについて、およびローテーション中のPresentationModelの保存については何も言わなかったことに最も気づいたでしょう。 この問題はこのパターンに固有のものではなく、個別に考慮する必要があります。 私の記事では、パターンの本質に焦点を当てたいと思いました。MVPやMVVMと比較した場合の長所と短所です。 また、 双方向のデータバインディング 、RxPMのコンテキストでの画面間のナビゲーションなど、重要なトピックはカバーされていませんでした。 次の記事では、 Jeevuzと一緒に、実際のプロジェクトでRxPMの使用を開始する方法について説明し、アプリケーションを簡素化するライブラリソリューションを紹介します。