Reactive programming

Reactive programming can most simply be defined as asynchronous programming with observable streams.

Well, what does that mean? Let’s break it down.

Asynchronous programming

In the context of reactive programming, asynchronous programming is a complex term. In the traditional sense, it is programming in a non-blocking way such that long-running tasks are performed separately from the main application thread. In another sense, it is an event-driven style of programming where the events themselves are asynchronous and can arrive at any point in time.

Observable

Observable refers to an entity that can be subscribed to by any number of observers interested in its state. The observable entity will then push updates to its observers when the state changes or when an event arrives. This is the classic observer pattern.

Stream

A stream (or data stream) can be thought of as an ordered sequence of events. These events may arrive at any point in time, may have no defined beginning or end, and are often generated by sources external to our application.

Asynchronous programming with observable streams

By re-assembling these terms, an observable stream is a sequence of events that can be subscribed to and whose observers will be notified for each incoming event. Asynchronous programming with observable streams is a way to asynchronously handle data streams by using a push-based, observer pattern to keep the application responsive.

Forms of data streams to handle

Android developers have undoubtedly dealt with many forms of data streams. Let’s think of some examples of data streams that we might want to handle using reactive programming:

  • User-generated Events: Click events, swipe events, keyboard input, and device rotations are just a few examples of events initiated by the user. If we consider each of these events across a timeline, we can see how they would form an ordered sequence of events, or a dynamic and potentially infinite data stream.

  • I/O Operations: Network requests, file reads and writes, database accesses, and other I/O operations are probably the most common types of data streams we will apply reactive principles to in practice. I/O operations are asynchronous since they take some significant and uncertain amount of time to complete. The response, whether it be JSON, a byte array, or some plain-old Java objects, can then be treated as a data stream.

  • External System Events: Push notifications from the server, General Circulation Model (GCM) broadcasts, updates from device sensors, and events generated from external producers are similar to user-generated events in their dynamic and potentially infinite nature.

  • Just About Anything: Really, just about anything can be modeled as a data stream. That’s the reactive mantra. A single, scalar value or a list of objects, static data, or dynamic events can be made into a data stream in the reactive world.

All of the previous examples are events that we want our program to take immediate action on. The point of reactive programming is to be reactive.

With reactive programming, data is a first-class citizen. The flow of data will drive the program as opposed to the thread of execution. The library we are using, RxJava, provides a thorough set of APIs for dealing with these data streams concisely and elegantly.