Best practices setting onSubscribe thread from an API - rx-java2

Question

Let's say I have an API that exposes two methods, each returns an observable
import org.assertj.core.util.VisibleForTesting;
import java.util.Random;
import java.util.concurrent.TimeUnit;
import io.reactivex.Observable;
import io.reactivex.Scheduler;
class SomeApiClass {
private static final String[] doOnSubscribeThread = new String[1];
static Observable<Integer> immediatelyDoWork() {
return Observable.just(1, 2)
.doOnSubscribe(ignore -> doOnSubscribeThread[0] = Thread.currentThread().getName())
.flatMap(ignore -> doWork());
}
static Observable<Integer> periodicallyDoWork() {
// interval is using default computation scheduler
return Observable.interval(1, TimeUnit.SECONDS)
.doOnSubscribe(ignore -> doOnSubscribeThread[0] = Thread.currentThread().getName())
.flatMap(ignore -> doWork());
}
#VisibleForTesting
static String getSubscribedOnThread() {
return doOnSubscribeThread[0];
}
private static Observable<Integer> doWork() {
return Observable.create(emitter -> {
Random random = new Random();
emitter.onNext(random.nextInt());
emitter.onComplete();
});
}
Most APIs would just let the calling application set the subscribeOn thread (imagine these tests are my application):
import org.junit.Test;
import io.reactivex.Observable;
import io.reactivex.android.schedulers.AndroidSchedulers;
import io.reactivex.observers.TestObserver;
import io.reactivex.schedulers.Schedulers;
import static com.google.common.truth.Truth.assertThat;
public class ExampleTest {
#Test
public void canSetSubscribeOnThread() {
Observable<Integer> coloObservable = SomeApiClass.immediatelyDoWork()
.subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread());
TestObserver<Integer> testObserver = coloObservable.test();
testObserver.awaitCount(2); // wait for a few emissions
assertThat(SomeApiClass.getSubscribedOnThread()).contains("RxNewThreadScheduler");
}
#Test
public void canSetSubscribeOnThreadIfApiUsesInterval() {
Observable<Integer> coloObservable = SomeApiClass.periodicallyDoWork()
.subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread());
TestObserver<Integer> testObserver = coloObservable.test();
testObserver.awaitCount(2); // wait for a few emissions
assertThat(SomeApiClass.getSubscribedOnThread()).contains("RxNewThreadScheduler");
}
}
IIUC in the immediate example all subscription side-effects (including just()) will happen on a new thread. Karnok explains well here.
But in the periodic example, interval will use the default (computation) scheduler. What do most APIs do in this case? Do they let the caller set subscribeOn thread for all subscription side-effects except interval itself? In the periodic test above, we are still able to set subscribeOn thread for everything but interval. Or do they add an argument to set this subscribeOn too:
/**
* Works like {#link #periodicallyDoWork()} but allows caller to set subscribeOnSchedueler
*/
static Observable<Integer> periodicallyDoWork(Scheduler subscribeOnScheduler) {
return Observable.interval(1, TimeUnit.SECONDS, subscribeOnScheduler)
.doOnSubscribe(ignore -> doOnSubscribeThread[0] = Thread.currentThread().getName())
.flatMap(ignore -> doWork());
}
And then allow callers to omit the subscribeOn() method:
#Test
public void canSetSubscribeOnThreadIfApiUsesInterval() {
Observable<Integer> coloObservable = SomeApiClass.periodicallyDoWork(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread());
TestObserver<Integer> testObserver = coloObservable.test();
testObserver.awaitCount(2); // wait for a few emissions
assertThat(SomeApiClass.getSubscribedOnThread()).contains("RxNewThreadScheduler");
}
Is this overkill? As long as the caller also calls subscribeOn() is there any danger in just letting interval use the default computation scheduler?

Answer 1

In my opinion, an API that creates observer chains must provide ways of injecting schedulers. Without that capability, unit testing becomes almost impossible to manage.
I have quite a bit of experience writing tests for real time systems. Simply being able to supply a TestScheduler or two to the unit under test makes the difference between being able to test reasonably and not bothering. Consider a subsystem that has a debounce() method period of 1 second. It is not feasible to write unit tests of several dozen cases without being able to use a TestScheduler and using advanceTimeBy() to control the clock. This means unit tests can be done in 10s of milliseconds that would take minutes if using a regular scheduler.