Understanding MVVM on Android Tutorial 05 – Introduction to Reactive Programming with RxJava

So far in the series, we have defined our model and retrieved the model data using networking calls with Retrofit2. Then we created our views using standard Android components. But before we create the last piece of our M-V-VM pattern, the viewmodel, it is worth discussing reactive programming. I am introducing reactive programming at this stage because I will be making use of reactive programming techniques to propagate changes between my Views and the ViewModels. In particular I will be making use of RxJava library.

Let’s have another look at our MVVM pattern diagram, we can see that 2-way communication is required between the Model – ViewModel and the ViewModel-Views. In particular, we would like our ViewModel to react to everything that happens on the Views and the Views to react to everything that happens in the ViewModels, i.e we would like our views to be “bound” to our Viewmodel and our Viewmodel to be “bound” to our view. We will achieve this 2-way “data-binding” effect using the RxJava library. *You could achieve the same using Google’s official Data Binding library. but RxJava is my preference.

MVVMEven if you end up not using the MVVM, it is still worth learning about Reactive programming to help you create event-driven, smooth-running and fast mobile applications.

What is Reactive Programming?
According to Wikipedia: “Reactive programming is an asynchronous programming paradigm oriented around data streams and the propagation of change.”

Simply put, reactive programming manages data flows between sources of data and components that need to react to that data using the key concept of “events“. Real life is event-driven, for example if it is too hot inside our home, we open a window or if our self-driving car senses an obstacle, we want it to stop etc. Reactive programming enables us to create software that models the real world more closely. For example, if we change some values in our spreadsheet, we would like the totals to change immediately. Or if a change occurs in our network, we would like the data displayed in our apps to change and reflect the new state of information. Without reactive programming, we would have to poll our servers continuously checking for any changes on the network.

In reactive programming we do not wait for the results of a network call, database query or for functions to return. We simply request to be notified when these “events” occur and carry on with our lives. Because every moment spent waiting is time that could be spent doing other things in parallel thus providing a better user experience.

For example, if an application asks a user to log in and submit a form with his username and password. We know that once the network call is made, two results are possible: success or error. Using reactive programming, we can request to be notified when the result of the network call arrives and in the meantime we could do the following:

  • Show a progress dialog
  • Preload important data that may take some time once user is logged in

Design Patterns
In our first post in the series, we defined a software architecture pattern as, “a set of rules to be applied when developing a software application“. These rules include a list of objects to be used in the application and most importantly some constraints about how these objects will interrelate and interact with each other.

Now, let’s have a look at software design patterns. In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Design patterns can speed up the development process by providing tested, proven development paradigms to a broad range of problems. Design patterns provide general solutions, documented in a format that doesn’t require specifics tied to a particular problem. Reusing design patterns helps to prevent errors that can cause major problems and improves code readability for coders and architects familiar with the patterns. In addition, design patterns allow developers to communicate using well-known, well understood names for software interactions.

In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (collectively known as “Gang of Four”) published a book titled Design Patterns – Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. The book named 23 design patterns categorised into :

  • Creational Patterns
  • Structural Patterns
  • Behavioral Patterns

The Observer Pattern
Behavioral patterns are those patterns that are most specifically concerned with communication between objects and the “Observer” pattern is probably one of the most famous in this group. The intent of the Observer pattern is to define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. We are interested in the Observer pattern because this is the pattern used by the RxJava library for implementing reactive programming.

The Observer pattern consists of a Subject and Observers. A Subject is a particular object that keeps a list of objects that want to be notified when the subject changes. These objects are called Observers and they register themselves with the Subject as they are created. Whenever the Subject changes, it broadcasts to all registered Observers that it has changed, and each Observer can query the Subject that it is monitoring. A subject can have an infinite number of observers.

The Observer Pattern in RxJava
In RxJava, the Subject and Observer objects of the Observer pattern are known as Observables (which emit events) and Subscribers/Observers (which consume those events). An Observable may have any number of Subscribers/Observers attached to it. If you are just learning RxJava, I would recommend focusing first on learning about the Observable, as arguably the rest of RxJava is mainly concerned manipulating the data returned from the observables. There are 5 different types of Observables in RxJava:

  • Observable
  • Flowable
  • Single
  • Maybe
  • Completable

In the next post, I will be refactoring our tutorial’s existing codebase with RxJava and RxAndroid.

Upcoming posts in the series:
Understanding MVVM on Android Tutorial 06 – Refactoring our code with RxJava
Understanding MVVM on Android Tutorial 07 – More Tips and Tricks for RxJava

Leave a Reply

2 Comments

  1. peterson

    excellent tutorial. im looking forward to the next one!