Reactive programming has been around for a while and there are tons of information available online, including how to use it, the operators, functional programming aspect and threading. In this post I won’t be talking about how to use RxJava and show code examples for the things I just mentioned. Instead I will try to explain why it is a good fit for your architecture in Android. This presentation by Jake Wharton inspired me to write this post: https://realm.io/news/gotocph-jake-wharton-exploring-rxjava2-android/ . You might find that I am talking about the same thing but I will try to summarize this and tell it on my perspective.
If you are working on an Android project that deals with a lot of data and a lot of data sources then you already dealt with the problems with synchronization of data around the app and reflecting the change to UI. Android restricts network access on UI thread because it will block the user interface for a long time causing the app stop responding to the user input. For this reason you would have to use AsyncTask or a library like Retrofit to do the network request on background thread and do the UI changes on UI thread. Android has a lot of components like Application, Activity, Fragment or View that could be interested the result of the network request. Basically there are two ways to notify this interested parties. Hold reference to the classes to be notified and call methods that will reflect the changes or use an eventbus to notify subscribers.
There are also other costly operations that are allowed on the UI thread like database access or JSON serialization/deserialization. You can do these operations on UI thread but you will end up with a flaky app. If you want to do them on a background thread then you need to deal with AsyncTask or threads, which is not very convenient and introduces a lot of boilerplate code.
There are two approaches on the data flow which are pull vs push. With the pull approach the root cause of the problems is that we don’t know when the data needed will be available to us. So we don’t know when to do a pull. If you designed app in pull mentality then you would end up this problems. Android doesn’t let you implement you a pull approach fully (network requests on UI thread) and also performance problems forces you to use a push approach. With combining them we ended up a weird structures with problems with our app and code like the ones I mentioned above.
I think the main point of using reactive programming is; it forces you to think in a push approach. Instead of reaching data without knowing when it would be available, it gives you easy to use syntax to notify and get notified when the data is available or it is changed with easy threading and functional programming capabilities.
If you feel the pain I described and thinking that you need to learn further about Reactive programming, I encourage you to watch the presentation by Jack Wharton I linked above. It could be a little bit challenging to change your mind to a Reactive approach but don’t give up. It will worth the effort.
