Reactive Programming on Android with RxJava

Scheduler Behavior Details
As you can see, using
.subscribeOn()
and
.observeOn()
make threading trivially easy, but there
are some intricacies to these operators that need to be called out.
As pointed out earlier, where in the operator chain the
.subscribeOn()
call appears does not
matter. However, it’s important to note that only the
first
.subscribeOn()
call will be applied; any
subsequent
.subscribeOn()
calls will have no effect. Oftentimes,
Observable
s are created as part
of a library or API and provided to a client via some interface. This interface documentation should
clearly state if the returned
Observable
will have already been relegated to some
Scheduler
via
.subscribeOn()
because, if it has, the client will no longer be able to make its own
.subscribeOn()
call. In general, it is recommended that the creator of the
Observable
not
call
.subscribeOn()
to
allow for flexibility by the client. For example, the client may already be operating on a background
thread and has no need for the
Observable
to create yet another thread to perform its work. If, for
some reason, you do
not
want the caller to be able to modify the
Scheduler
where the
Observable
executes, simply add a
.subscribeOn()
call to the
Observable
that you pass back.
Only the first
.subscribeOn()
call—-no matter where it is in the operator chain—-will
be applied to the source
Observable
at the time
.subscribe()
is called; any subsequent
.subscribeOn()
calls will have no effect.
It is advised for
.subscribeOn()
to be placed first in the operator chain. Doing this will
be clearer for a human reader since
.subscribeOn()
applies to the start of data stream.
.observeOn()
, on the other hand, is the dual of
.subscribeOn()
in many ways. Whereas
.sub-
scribeOn()
affects the upstream source
Observable
,
.observeOn()
affects the downstream opera-
tors. And whereas only the first
.subscribeOn()
takes effect,
.observeOn()
can be called multiple
times, with each call switching the thread for downstream operators (until another
.observeOn()
call is encountered). For common use cases (e.g. where the
Observer
is updating the UI), it is
¹²
https://github.com/ReactiveX/RxAndroid

---

Chapter 4: Multithreading
53
recommended to put the
.observeOn()
call as close to the
.subscribe()
call (i.e. as late in the
Operator
chain) as possible. This will ensure the computation performed by the
Operator
s does
not occur on the main UI thread, which we generally want to keep unburdened. And since thread
switches bear some performance cost, we also don’t want to perform them early on in the stream
for items that may just get filtered out later on.
To reinforce the previous points, let’s take a look at a completely-non-real-world example. To help
show which thread each operator is running on, let’s define the following
print()
method:
1