As introduced in Chapter 1, Thinking Reactively, the Observable is a push-based, composable iterator. For a given Observable<T>, it pushes items (called emissions) of type T through a series of operators until it finally arrives at a final Observer, which consumes the items. We will cover several ways to create an Observable, but first, let's dive into how an Observable works through its onNext(), onCompleted(), and onError() calls.

Before we do anything else, we need to study how an Observable sequentially passes items down a chain to an Observer. At the highest level, an Observable works by passing three types of events:

• onNext(): This passes each item one at a time from the...

The onNext(), onComplete(), and onError() methods actually define the Observer type, an abstract interface implemented throughout RxJava to communicate these events. This is the Observer definition in RxJava shown in the code snippet. Do not bother yourself about onSubscribe() for now, as we will cover it at the end of this chapter. Just bring your attention to the other three methods:

    package io.reactivex;

    import io.reactivex.disposables.Disposable;

    public interface Observer<T> {
      void onSubscribe(Disposable d);
      void onNext(T value);
      void onError(Throwable e);
      void onComplete();
   }

Observers and source Observables are somewhat relative. In one context, a source Observable is where your Observable chain starts and where emissions originate. In our previous examples, you could say that the Observable returned from...

There are subtle behaviors in a relationship between an Observable and an Observer depending on how the Observable is implemented. A major characteristic to be aware of is cold versus hot Observables, which defines how Observables behave when there are multiple Observers. First, we will cover cold Observables.

Cold Observables are much like a music CD that can be replayed to each listener, so each person can hear all the tracks at any time. In the same manner, cold Observables will replay the emissions to each Observer, ensuring that all Observers get all the data. Most data-driven Observables are cold, and this includes the Observable.just() and Observable.fromIterable() factories...

We already covered a few factories to create Observable sources, including Observable.create(), Observable.just(), and Observable.fromIterable(). After our detour covering Observers and their nuances, let's pick up where we left off and cover a few more Observable factories.

To emit a consecutive range of integers, you can use Observable.range(). This will emit each number from a start value and increment each emission until the specified count is reached. These numbers are all passed through the onNext() event, followed by the  onComplete() event:

    import io.reactivex.Observable;

    public class Launcher {
      public static void main(String[] args) {
        Observable...

There are a few specialized flavors of Observable that are explicitly set up for one or no emissions: Single, Maybe, and Completable. These all follow the Observable closely and should be intuitive to use in your reactive coding workflow. You can create them in similar ways as the Observable (for example, they each have their own create() factory), but certain Observable operators may return them too.

Single<T> is essentially an Observable<T> that will only emit one item. It works just like an Observable, but it is limited only to operators that make sense for a single emission. It has its own SingleObserver interface as well:

    interface SingleObserver<T> {
    void...

When you subscribe() to an Observable to receive emissions, a stream is created to process these emissions through the Observable chain. Of course, this uses resources. When we are done, we want to dispose of these resources so that they can be garbage-collected. Thankfully, the finite Observables that call onComplete() will typically dispose of themselves safely when they are done. But if you are working with infinite or long-running Observables, you likely will run into situations where you want to explicitly stop the emissions and dispose of everything associated with that subscription. As a matter of fact, you cannot trust the garbage collector to take care of active subscriptions that you no longer need, and explicit disposal is necessary in order to prevent memory leaks.

The Disposable is a link between an Observable and an active Observer,...

This was an intense chapter, but it will provide a solid foundation as you learn how to use RxJava to tackle real-world work. RxJava, with all of its expressive power, has some nuances that are entirely due to the change of mindset it demands. It has done an impressive amount of work taking an imperative language like Java and adapting it to become reactive and functional. But this interoperability requires some understanding of the implementations between an Observable and a Observer. We touched on various ways to create Observables as well as how they interact with Observers.

Take your time trying to digest all this information but do not let it stop you from moving on to the next two chapters, where the usefulness of RxJava starts to take formation. In the next chapters, the pragmatic usefulness of RxJava will start to become clear.