Overriding RxJava Schedulers — getting it right with RxLint

Peter Tackage
2 min readOct 14, 2017

--

My previous articles [1], [2] highlighted the importance of overriding the default Scheduler for certain RxJava operators to help ensure the validity of your tests and I also presented the Scheduler Injection pattern as a means of achieving this.

However, manually performing this can be error prone. You need to be familiar enough with the dozens of RxJava operators to know when it’s applicable and consequently, despite code reviews, mistakes can slip in and lead to flaky tests and bugs in your app.

RxLint has been around for a while and provides custom Lint checks for common RxJava mistakes. Since the recent version 1.6, it contains a check which reports a warning if an operator is using a default Scheduler.

Let’s take the example of debounce. Now when using RxLint, if we forget to override the Scheduler, a warning is reported -

Oops! We forgot to provide our own Scheduler!

RxLint works by scanning the associated @SchedulerSupport annotation value of the RxJava operator call sites in your code. If it finds an instance where the operator declaration is using its own Scheduler, such as @SchedulerSupport(SchedulerSupport.COMPUTATION), then the warning is generated.

With a little corrective action we can fix this up by providing our own injected Scheduler instance -

Fixed!

So if you’ve been following the Scheduler Injection pattern, try out the latest RxLint and hopefully it makes your life a little easier.

--

--