RxJavaを初めて使用し、これをMVPアーキテクチャと共に使用しています。PresenterとRxJava、設定変更のための断片を保持
私は、保持されたフラグメントを使用して構成変更を行った際に観測値を保存する例をいくつか見つけました。私が見つけた例は、プレゼンターからではなく、アクティビティーまたはフラグメント上のオブザーバブルを直接処理することです。
私はこれをテストしたところでquick example（ReactivexのRxJavaとRxAndroidのlibのみを使用しています）を実験して設定しましたが、うまくいくようです。この例の内容は次のとおりです。
- ヘッドレスで保存されたフラグメントでアクティビティを開始します。
- プッシュボタン
- Presenterは、遅延（5秒）応答でFakeServiceを呼び出します。
- Presenterはこのオブザーバブルで.cache（）を実行します。
- Presenterは、この可観測性を保持するビューを指示します。
- ビューは、保持可能なフラグメントにオブザーバブルを保存します。
- Presenterはobservableにサブスクライブします。
- ユーザーは構成の変更を行います（デバイスのローテーション）。ユーザーは、彼が望む回数だけこれを行うことができます。
- OnPauseはプレゼンターのCompositeSubscriptionに、現在のすべてのサブスクリプションをクリアし、サブスクライブを解除するように指示します。
- アクティビティが再作成され、既存の保持されたフラグメントが再利用されます。
- アクティビティのonResumeは、保持されているフラグメントの保存されたobservableがnullかどうかをチェックします。
- nullでない場合、Presenterにサブスクライブするように指示します。
- 保持されたobservableがサブスクライブされ、.cacheが呼び出されたため、サービスを再度呼び出さずに新しいサブスクライバに結果を再生するだけです。
- プレゼンターが最終結果をビューに表示すると、保持されているフラグメントの保存されたobservableもnullに設定されます。
私はこれを正しくやっているのか、観測者のサブスクリプションがPresenterで処理されているときに、より効率的でエレガントな構成変更の処理方法があるのだろうか？
編集：フィードバックのため 感謝。 これに基づいて私はよりクリーンなソリューションだと思っており、リンクされた例を変更して更新しました。
新しい変更が加えられました。 ObservableをPresenterからActivityに渡すのではなく、configurationChangeイベントが発生したときに保存するretainFragmentに渡す代わりに、作成時にretainFragmentを2番目の「ビュー」として設定しました。
このようにして、デバイスの回転後にonResume（）が発生した場合、ObservableをretainFragmentからPresenterに戻すことを醜い配管で行う必要はありません。
プレゼンターは、この第2の「ビュー」と直接対話し、保持されている観察可能なもの自体をチェックし、必要に応じて再サブスクライブすることができます。主なアクティビティは、この観測可能性についてもう知る必要はありません。突然、はるかにシンプルなビューレイヤーです。
こんにちは、これは確かに非常に興味深いアプローチだと思います。私はあなたのプロジェクトをクローンし、私はそれを使って遊んでいます。私は、ローダーを使用する向きの変更を扱う別のアプローチに従ってきました。私はあなたが司会者の状態をどのように扱うかに興味があった。特に、サービスが終了し、アクティビティがまだプロセスを保持しているときどの部分が発表者の状態を処理しますか？その部分を少し説明していただけますか？また、このアプローチはアクティビティやフラグメントに対しても機能しますか？そして最後に、このアプローチに続く落とし穴がありますか？ありがとうございました。 –
この方法では、保持されている観測値から結果を再生することができます。つまり、データが失われることはありませんが、onResume（）からすべてのデータを再生すると、構成が変更されるたびにuiの状態が再開されます。これは、observableから受信したデータをrecyclerviewに追加してリストをスクロールするときに最もよくわかります。設定が変更されると、アダプタが再び作成され、データがアダプタに再追加されます。再びrecyclerviewの上部。 TL; DR、スクロール位置を保存できません。 – desmondtzq