RxJava

Overview

RxJava is described officially as "a library for composing asynchronous and event-based programs by using observable sequences". But what does this actually mean? Let's put this library into context.

One of the challenges in writing robust Android apps is the dynamic nature of changing inputs. In traditional imperative programming models, values have to be explicitly set on variables for them to be updated. If one dependent value changes, the value will not be updated without adding another line of code. Consider the following example:

State variables such as k intrinsically may not reflect the current value of its inputs. Traditional asynchronous programming approaches tend to rely on callbacks to update these changes, but this way can lead to a problem known as callback hell. Reactive programming (see an intro here) addresses these issues by providing a framework to describe outputs to reflect their changing inputs. RxJava, which is a port of the Reactive Extensions library from .NET, enables Android apps to be built in this style.

Advantages

Here are a few advantages of using RxJava on Android:

Simplifies the ability to chain async operations. If you need to make an API call that depends on another API call, you will likely end up implementing this call in the callback of the first one. RxJava provides a way to avoid the need to create layers of callbacks to address this issue. For this reason, RxJava became popular within Netflix in 2014 for abstracting away the complexities of performing dependent API calls.

Exposes a more explicit way for declaring how concurrent operations should operate. Although RxJava is single-threaded by default, RxJava helps enable you to define more explicitly what type of threading models should be used for both background and callback tasks. Since Android only allows UI updates on the main thread, using RxJava helps make the code more clear about what operations will be done to update the views.

Surfaces errors sooner. One issue with AsyncTask is that errors that occur on the background thread are hard to pass along when updating the UI thread using the onPostExecute() method. In addition, there are limitations in how many AsyncTasks can be dispatched concurrently as described in this blog post. RxJava provides a way to enable these errors to be surfaced.

Helps reduce the need for state variables that can introduce bugs. One mindset shift need in using RxJava is thinking about everything in terms of describing how data flows in the system. Click events generated by the user, network calls, data updates from external sources all can all be described as asynchronous streams of data. The power of RxJava is that it enables these streams to be transformed, filtered, or used to create new streams of data with only a few lines of code while also minimizing the need for storing state variables.

Setup

If you plan to use RxJava, it is highly recommended that you setup lambda expressions to reduce the verbose syntax usually needed. The guide includes instructions about how to update your existing Android Studio projects to leverage it.

Observables and Observers

The basic building blocks of reactive code are Observables and Observers. An Observable emits items; an Observer consumes those items. An Observablemay emit any number of items (including zero items), then it terminates either by successfully completing, or due to an error.

An Observable can then have any number of observers. For each Observer attached, an Observable calls Observer#onNext() for every item, followed by either Observer#onComplete() or Observer#onError(). Keep in mind that Observables often don't start emitting items until there's at least one subscriber.

Defining Observables

Let's take the most basic example to understand how this is structured. First, let's define an Observable which is an object that can emit any number of items to be processed:

// Observables emit any number of items to be processed// The type of the item to be processed needs to be specified as a "generic type"// In this case, the item type is `String`Observable<String>myObservable=Observable.create(newObservable.OnSubscribe<String>(){@Overridepublicvoidcall(Subscriber<?superString>sub){// "Emit" any data to the subscribersub.onNext("a");sub.onNext("b");sub.onNext("c");// Trigger the completion of the eventsub.onCompleted();}});

This observable event emits the data "a", "b", "c" and then completes.

Defining Observers

Now let's create a Observer to consume this emitted data from the Observable:

Observer<String>mySubscriber=newObserver<String>(){// Triggered for each emitted value@OverridepublicvoidonNext(Strings){System.out.println("onNext: "+s);}// Triggered once the observable is complete@OverridepublicvoidonCompleted(){System.out.println("done!");}// Triggered if there is any errors during the event@OverridepublicvoidonError(Throwablee){}};

Subscribing to Observables

To implement an observer for these events, the following interface must be defined:

publicinterfaceObserver<T>{voidonNext(Tt);// called for each "emitted" itemvoidonCompleted();// will not be called if onError() is calledvoidonError(Throwablee);// called if there's an error}

Note that an Observer is a generic type. It must represent the type of value that the Observable will emit. For a subscriber to start watching an observable that will generate string types, it must subscribe to it:

Observable.just("a","b","c").subscribe(newObserver<String>(){// Triggered for each emitted value// Invoked with "a", then "b", then "c"@OverridepublicvoidonNext(Strings){System.out.println("onNext: "+s);}// Triggered once the observable is complete@OverridepublicvoidonCompleted(){System.out.println("done!");}// Triggered if there is any errors during the event@OverridepublicvoidonError(Throwablee){}});

This example above would simply print each argument ("a", "b", "c") and then exit since each item is invoked with a call to onNext. Once all items have been invoked, the onCompleted method is called.

This might seem contrived and not particularly useful in this example but as layers are built on top of these foundations, we begin to see the power of RxJava.

An Observer can be attached to an Observable in order to respond to emitted data with:

This example would simply print each emitted item and then exit since each item is invoked with a call to onNext. Once all items have been invoked, the onCompleted method of the Observer is called.

Other ways to create Observables

As demonstrated above, an Observer watches for result values emitted by the Observable. When these events occur, the role of the subscriber is to respond to these events. An Observable can be created from any type of input.

Just about anything to be considered an asynchronous stream of data. For instance, an Observable can be a set of string items that should be iterated:

// `just` generates an observable object that emits each letter and then completes the streamObservable.just("a","b","c");

See this blog post for more details.
For a complete list of the different ways of creating an Observable, check out this link.

Schedulers

RxJava is synchronous by default, but work can be defined asynchronously using schedulers. For instance, we can define that the network call should be done on a background thread, but the callback should be done on the main UI thread.

Observable.from(Arrays.asList(1,2,3,4,5)).subscribeOn(Schedulers.newThread()).observeOn(AndroidSchedulers.mainThread())).subscribe(newSubscriber<String>(){@OverridepublicvoidonCompleted(){//called on completion}@OverridepublicvoidonError(finalThrowablee){//called when error occurs}@OverridepublicvoidonNext(finalStrings){Log.d("emit",s);}});

Here are the things to note from the example code above:

subscribeOn(Schedulers.newThread()): This will make the Observable do its background work in a new thread

.observeOn(AndroidSchedulers.mainThread())): This makes the subscriber action to execute its result on Android's main UI thread. This is very important especially when change to a UI component needs to be made based on the result.

.subscribe(): Subscribes an Observer to the Observable. The ObserversonNext method is called on each emitted item, followed by either onCompletion if it runs successfully or onError if an error occurs.

Using schedulers relies on queuing the work through bounded or unbounded thread pools. Here are a few options available that come with RxJava. See this link for all the possible options.

Name

Description

Schedulers.computation()

fixed number of threads (= to # CPU's)

Schedulers.immediate()

current thread

Schedulers.io()

backed by a thread pool that can expand as needed

Schedulers.newThread()

create a new thread

Schedulers.trampoline()

schedule work on the current thread but put on a queue

These schedulers can then be used to control which thread an observable or the subscriber are operating on using subscribeOn() and observeOn().

Schedulers come out of the box with RxJava. The RxAndroid library comes with AndroidSchedulers.mainThread(), which is a convenient way to access the main UI thread on Android.

Replacing AsyncTask with Observables

We can replace any AsyncTask calls with RxJava calls instead using Observable. Similar to how AsyncTask performs the task in the background and then calls onPostExecute() on the main thread on the UI, RxJava can accomplish this same function by defining which thread to perform the task with subscribeOn(), and then where to define the callback thread with observeOn():

// This constructs an `Observable` to download the imagepublicObservable<Bitmap>getImageNetworkCall(){// Insert network call here!}// Construct the observable and use `subscribeOn` and `observeOn`// This controls which threads are used for processing and observingSubscriptionsubscription=getImageNetworkCall()// Specify the `Scheduler` on which an Observable will operate.subscribeOn(Schedulers.io())// Specify the `Scheduler` on which a subscriber will observe this `Observable`.observeOn(AndroidSchedulers.mainThread()).subscribe(newSubscriber<Bitmap>(){// This replaces `onPostExecute(Bitmap bitmap)`@OverridepublicvoidonNext(Bitmapbitmap){// Handle result of network request}@OverridepublicvoidonCompleted(){// Update user interface if needed}@OverridepublicvoidonError(){// Update user interface to handle error}});

Using this combination of Observable, Subscriber and thread scheduling, we can see the power of RxJava. But there's a lot more that can be done.

Using RxJava with Retrofit

RxJava can be used with Retrofit to provide the ability to chain multiple network calls. It also provides a basic abstraction for surfacing errors if one of these network calls should fail. The section below shows you how to setup Retrofit with RxJava.

We can then instantiate an instance of this interface and get back an Observable type:

MyApiEndpointInterfaceapiService=retrofit.create(MyApiEndpointInterface.class);// Get the observable User objectObservable<User>call=apiService.getUser(username);// To define where the work is done, we can use `observeOn()` with Retrofit// This means the result is handed to the subscriber on the main threadcall.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread()).subscribe(newSubscriber<User>(){@OverridepublicvoidonNext(Useruser){// Called once the `User` object is available}@OverridepublicvoidonCompleted(){// Nothing to do here}@OverridepublicvoidonError(Throwablee){// cast to retrofit.HttpException to get the response codeif(einstanceofHttpException){HttpExceptionresponse;intcode=response.code();}}});

The RxAndroid library includes AndroidSchedulers.mainThread() for allowing callbacks to be fired on the main UI thread.

Hot vs. Cold Observables

By default, Observables are initialized to begin executing after the first subscriber is attached. Retrofit, for instance, by default operates in this way, which are known as cold observables. You can take a look at the Retrofit source code to see that the network request is made on the first subscription.

Cold to Hot Observables

If you wish to change it so that multiple subscribers are attached before executing the request, otherwise known as converting to a hot observable, you need to convert the Observable to an ConnectableObservable. To initiate the network request, you need to call connect() on the observable:

Observable<User>call=apiService.getUser(username);// convert Observable to ConnectedObservable, get a reference so we can call connect() laterConnectableObservable<User>connectedObservable=call.publish();// define 1st observerObserver<User>observer1=newObserver<User>(){@OverridepublicvoidonCompleted(){}@OverridepublicvoidonError(Throwablee){}@OverridepublicvoidonNext(Useruser){// do work here}};// define 2nd observer hereObserver<User>observer2=newObserver<User>(){}// observer is subscribingconnectedObservable.observeOn(AndroidSchedulers.mainThread()).subscribe(observer1);connectedObservable.observeOn(AndroidSchedulers.mainThread()).subscribe(observer2);// initiate the network requestconnectedObservable.connect();

Hot to Cold Observables

You can also turn a hot observable back to a cold observable by using autoConnect(). Instead of needing to call an explicit connect() and passing around ConnectedObservable types, you can use this approach to enable the next subscriber to trigger a network request upon the next subscription:

Handling Configuration Changes

If an Activity is destroyed because of a change in screen orientation, the Observable will fire again in onCreate() and this will result in duplication of work because the same API call will be made again and all progress made initially will be lost. To solve this problem, you need to first store a reference to the Observable by using singletons or using retained fragments and use the cache() operator:

Observable<User>call=apiService.getUser(username).cache();

Future observers will get the previous emitted items from the Observables as soon as it subscribes:

Subscriptionsubscription=observable.subscribe(observer1);

If you wish to have more granular control over the buffer size or time span in which cached events will be emitted, you should use the replay() operator:

Also note that the replay() turns the observable into a hot observable, which will not emit events until connect() is called.

Avoiding Memory Leaks

The flexibility in being able to schedule observables on different threads and have them operate as long-running tasks can make it easy to contribute the memory leaks. One of the reasons is that observers are often created with anonymous classes. In Java, creating anonymous classes requires the inner class retaining an instance to the containing class as discussed in this Stack Overflow article.

An observer that is created within an Activity or Fragment therefore can hold a reference that will be unable to be garbage collected if the observable is still running. There are several different approaches suggested. Both approaches attempt to manage the subscriptions created from attaching an observer to an observable and canceling them when a lifecycle event occurs.

Composite Subscriptions

One of the simplest approach is to simply instantiate a CompositeSubscription object inside your Activity or Fragment.

RxBinding

See this guide on how to implement RxJava with Android views. The RxBinding library simply implements Observable events for many standard Android views, making it easier to turn your UI events to leverage reactive-based programming.

RxLifecycle

There is also a library called RxLifecycle which provides support for managing the lifecycle of activities and fragments. In the past RxAndroid provided this support with AndroidObservables, but a decision was made to simplify the library. See this release note for more context.

Chaining Observables

For a better understanding about how subscriptions can be chained and how RxJava works in general, it's best to first to understand what happens beneath the surfaces when this subscribe() call is made. Beneath the covers Subscriber objects are created. If we wish to chain the input, there are various operators that are available that map one Subscriber type to another.