The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.


Rx Basics

A programming model that has been gaining substantial ground in recent years is reactive programming. In Android, much of the attention has been on RxJava, the “reactive extensions for Java”. Many libraries offer the ability to be consumed using RxJava, and many Android experts have latched onto RxJava as a way to reduce certain types of complexity in Android app development.

In this chapter, we will review what reactive programming is, what RxJava is, and how you can apply RxJava in your Android app.

However, please understand that reactive programming is a very large topic. Just a complete explanation of RxJava would entail its own book. This chapter should be seen as a launching pad for further explorations of your own, more so than a definitive reference on the subject.

Prerequisites

Understanding this chapter requires that you have read the core chapters of this book.

Life is But a Stream

In order to understand reactive programming, we first need to think about streams.

When a Java programmer hears the term “stream”, what often pops into mind is InputStream and OutputStream. Those offer access to a stream of bytes, for input and output, respectively. Here, “stream” means that the bytes are available one at a time (though are often retrieved in a clump, such as an 8192-byte buffer), and that once removed from the stream the bytes are considered to be “consumed” and are no longer available from the stream itself.

When Java programmers think of InputStream and OutputStream, what often pops into mind is FileInputStream and FileOutputStream. With FileInputStream, the source of the bytes is fixed: the contents of a designated file. With FileOutputStream, the destination of the bytes is fixed: once again, a designated file.

However, there are many other sources of InputStream and OutputStream. Some that you encounter in the book are:

Particularly in the HTTP case, the source of the bytes is “live”, insofar as there does not have to be some specific file that is the source of those bytes. Those bytes could represent a generated Web page, or a live audio stream, or anything else.

Hence, more generally, a stream represents a flow of data, where we can pull data off of the stream and do something with it. That “flow of data” could be bytes from a file, as we see with InputStream. But lots of other things could be modeled as flows of data. Pretty much anything where the data would come to us asynchronously could be modeled this way, such as:

You could even model some things that might not feel like a “stream” as a stream if you wanted to. For example, querying a database or ContentProvider gives you a Cursor back, and you could model that as being a stream of rows.

Action and Reaction

The preview of this section was lost due to a rupture in the space-time continuum.

A Rx For What Ails You

The preview of this section was abducted by space aliens.

Rx and Lambdas

The preview of this section was eaten by a grue.

A Simple Stream

The preview of this section was abducted by space aliens.

Be Your Own Stream

The preview of this section was fed to a gremlin, after midnight.

Removing the AsyncTask

The preview of this section was lost due to a rupture in the space-time continuum.

Lambdas and Lifetimes

The preview of this section was abducted by space aliens.

Streaming from a Resource

The preview of this section was fed to a gremlin, after midnight.

Error Handling

The preview of this section was lost due to a rupture in the space-time continuum.

Transmogrification

The preview of this section is en route to Mars.

Rx-Enabled Libraries

The preview of this section may contain nuts.

Further Reading

The preview of this section was last seen in the Bermuda Triangle.

What About LiveData?

The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.