user-icon Stefan Nägele
20. March 2018
timer-icon 4 min

Reactive libraries for Android

In these days it seems to be impossible to not get in touch with reactive programming and reactive apps in Android. But how and where to start making your apps (more) reactive? I want to give you a quick overview which reactive libraries are a good start for common Android development tasks to gain fast benefits.

I assume that you are already familiar with RxJava (2.0). If not, I recommend you Christopher Arriola’s RxJava Android introduction about the differences of  common Android programming and how reactive programming simplifies your daily business.

As a prerequisite for all upcoming reactive libs, you need to configure RxJava and RxAndroid.

I configured RxKotlin as “on top” library on RxJava because it offers a lot of convenient extension functions for a smoother RxJava API interaction. Now let’s start which libraries enhance your reactive Android arsenal.


One of the most used library in Android development is the HTTP client library Retrofit. Due to its wide distribution and RxJava support, Retrofit is probably the (!) starting library to enter the reactive Android world.

Beside the Retrofit library itself, an adapter dependency needs to be included and a RxJava adapter needs to be attached to your former Retrofit client.

HTTP calls are IO operations which should naturally run in the IO Thread Pool and thereby dispatched to the RxJava IO Scheduler.

The interface definition can now be changed from Retrofit’s Call class to RxJava’s

  •  Single, emit one value or an error notification and close the reactive stream
  • Completable, notification that my request succeeded but I do not want to process the response and close the stream

If you are using the MVP pattern, your call could be look like this:


There is barely a wide spread app which does not use preferences to customise the app experience. Thereby using a reactive wrapper around preferences becomes quickly a huge benefit.

In our app SprIT we encapsulated our preferences in an object class and initialise it via Application (if someone has a better approach, please let me know). Preferences.kt is equipped with convenient methods to access our used preference properties.

Our app uses a map view as main view. Gas stations are depicted via markers to show current fuel price data based on the preferred gas station type.

Map showing Benzin prices

If the user changes the required gas station type in his settings, the view shall be reactively updated.

Changing preferences

Map showing now Diesel prices


Handling permission results on your own is a pain in the neck. That’s why libraries like Dexter or android-permissions were created. Thank goodness that there is already a reactive equivalent. RxPermissions reduces the boilerplate code to a minimum.

If you are wondering what the ominous “view.rxPermissions” property is about then just wait for the next paragraph where we combine RxPermissions with another powerful reactive goody 😉


RxBinding is a library to wrap UI widgets in observables to subscribe to view events like clicks. We combined RxBinding with RxPermissions to trigger a full reactive click-permission workflow.


As responsible-minded app developers, a great UX is the essential thing.  A good app is characterised by its capability to deal with bad network connections or offline states, briefly said “act globally, sync globally” by Arun Sasidharan.

A convenient way to deal with unstable network connections is ReactiveNetwork to alert a user at the right UI place at the right time.


We all now the tricky part to attach and detach the view to our presenter in MVP. RxLifecycle can simplify that by declaring RxAppCompatActivity as super activity. A bunch of lifecycle extensions are added by RxAppCompatActivity which can be refined as well, e.g. by a concise onStart() lifecycle method.

Now a presenter can subscribe and unsubscribe on specific lifecycle events, e.g. start.

If we want to cut our subscription to network events as seen in section Reactive Networks or to stop waiting for a network response via Retrofit, RxLifecycle makes that straightforward.

Further tasks like cleaning up you memory for given lifecycle events can be for sure conducted by RxLifecycle as well.


In case you had no clue about reactive Android libraries before, you now got a small insight how to make your apps for common Android tasks more reactive and thereby more efficient to embed Android SDK calls in your reactive workflow or reactive architecture.

Nevertheless, this was just the tip of the iceberg. If you want to get a full overview about reactive Android libraries, the following GitHub page is quite good: RxAndroidLibs.

Moreover, if you want to bring all of these libraries in a meaningful architectural order, I highly recommend you to learn more about the MVI pattern of Hannes Dorfmann



Comment article