Is passing Schedulers around best practice, a last resort or something in between?

[DavidMihola]

This question is a follow-up to @artem-zinnatullin's comment to my question from yesterday.

For years now I've been using the static methods like Schedulers.io() and AndroidSchedulers.mainThread() to move my Observables around. Since I've started to write more tests I've also been trying to mostly move all subscribeOns and observeOns as far "to the ends" as possible: subscribeOn immediately after the Observables I get from Retrofit and observeOn immediately before any View related stuff.

This kept all the intermediate layers Scheduler agnostic and worked quite well except for two points:

• All time sensitive operators use computation() by default - this is a problem for testing where I would like to use TestScheduler to be able to use "virtual time".
• replay() seems to replay on the main thread by default - this just cost me three hours, because other parts of the app relied on a replayed Observable to also be on io().

So, both cases could be solved by putting a few subscribeOns in several places of my code, and passing Schedulers explicitly to interval(), etc.

In these cases, especially with regards to testing, is it best practice to mostly pass Schedulers around explicitly or is that seen as a last resort to be used when the default Schedulers fail or are inappropriate?

As always, thanks for any advice!

[artem-zinnatullin]

Can't say that it's "best practice" or something, but in order to reduce amount of boilerplate ceremonies and number of parameters in the constructor we follow next practice:

class SomeViewModel { // Presenter/whatever, you got it.

  @Inject @TimeScheduler
  Scheduler timeScheduler;

  @Inject @IoScheduler
  Scheduler ioScheduler;

  SomeViewModel(ObjectGraph graph) {
    graph.inject(this);
  }
}

Then in tests we just pass test implementation of the ObjectGraph that injects required schedulers like TestScheduler/Schedulers.immediate()/Schedulers.trampoline() to execute tests synchronously.

// Finally got rid of using Schedulers hook in our test suite today because we saw some shared state problems, really happy about it.

---

Also in case if you're interested, looks like that we've finally found a good solution for dealing with ViewModel/Presenter -> View reactive interaction that solves 3 main problems:

1. MainThread should be part of View implementation.
2. Action posted to MainThread should be part of Subscription (to unsubscribe).
3. Backpressure occurred on MainThread should be detected and handled on ViewModel/Presenter layer.

Nothing published yet because (I need some free time + try it in real life project), but you can track discussion/progress here.

[akarnokd]

I'm closing this issue due to inactivity. If you have further input on the issue, don't hesitate to reopen this issue or post a new one.

[artem-zinnatullin]

@DavidMihola as promised, finished solution regarding passing around RxAndroid's main thread scheduler: RxUi, feedback is welcomed!

[westonal]

@artem-zinnatullin How do you achieve @Inject @IoScheduler where does IoScheduler come from or how is it defined?

[westonal]

@artem-zinnatullin Nevermind, custom Qualifiers I assume http://docs.oracle.com/javaee/7/api/javax/inject/Qualifier.html

[artem-zinnatullin]

Yup!

…

On Mon, Jun 12, 2017, 13:22 Alan Evans ***@***.***> wrote: @artem-zinnatullin <https://github.com/artem-zinnatullin> Nevermind, custom Qualifiers I assume http://docs.oracle.com/javaee/7/api/javax/inject/Qualifier.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3915 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7B3H70UVU0vxzcScGtEBhlhhCGE4P0ks5sDRFlgaJpZM4IY_X-> .