Intro to RxのScheduling and Threadingセクションでは、次のように述べています。
SubscribeOn と ObserveOn の使用は、最終的なサブスクライバーによってのみ呼び出される必要があります
また、UI アプリケーションでは、通常は最終サブスクライバーであるプレゼンテーション レイヤーが、これらのメソッドを呼び出す必要があるとも述べています。
これが不便な状況がいくつか見られるため、アドバイスがしっかりしているかどうか疑問に思っています。
- まず第一に、プレゼンテーション レイヤーが、データ レイヤーからの Observable をサブスクライブする場所を決定する必要があるとは思いません。私の意見では、データがデータベースから来ているのか、REST API から来ているのか、メモリから来ているのか、プレゼンテーション層は認識しないはずです。このため、
subscribeOn()
Observable を返す前にデータ層が呼び出し、IO スケジューラまたは直接のスケジューラを都合のよいように渡すと便利です。 - プレゼンテーション レイヤーが何らかのサービスまたはユース ケースから Observable を取得し (データ レイヤーから取得)、このサービスが何らかの計算スケジューラでストリームを処理する必要があると判断した場合、なぜプレゼンテーション レイヤーはこれを気にする必要があるのでしょうか?
- 元は UI からのストリームはどうでしょうか。そのため、UI スレッドでサブスクライブする必要があります。次に、何らかのサービスに送信されて何らかの作業が行われ、最終的にプレゼンテーション層に戻って UI スレッドで観察されます。これには、UI ストリームが
subscribeOn()
UI スケジューラ、次にobserveOn()
他のスケジューラ、最後observeOn()
に UI スケジューラである必要があります。この場合、最後のサブスクライバーsubscribeOn()
でobserveOn()
のみ呼び出すことができるということは、ストリームを UI スレッドでのみ処理できることを意味します。
アプリケーションのアーキテクチャを犠牲にし、最終的なサブスクライバーのみがこれら 2 つのメソッドを呼び出すことでスレッドを簡単に切り替える Rx の機能を無視する正当な理由はありますか?