RxJava Ninja: Marble Diagrams and Operators

“Blue sparks and flames over a piece of metal with a welder leaning over it” by Rob Lambert on Unsplash

This article is a part of the RxJava Ninja series. The complete list of the articles for this series can be found at the end of this article (and will be updated as more articles become available).

Before we go to where the action in RxJava truly is, let us familiarize ourselves with the concept of Operators and Marble Diagrams.

Operators

Operators accepts input, manipulates it, and produces an output. Most RxJava operators work with observables on one or both ends so they must be pretty special. Why you ask? Because we know that observables communicate via notifications. This means that if an operator wishes to manipulate the items, it must follow this notification mechanism as well. To demonstrate this, let us look at an example operator, the map operator.

map transforms an input. The transformation may involve a change in value or type. Calling the map operator will instantiate a ObservableMap<T, R> class. If we check at the ObservableMap<T, R> code, we can see that it inherits AbstractObservableWithUpstream<T, U> which in turn extends Observable<U>. This means that the map operator is also an observable. Since it is an observable, it should implement subscribeActual. The subscribeActual of ObservableMap<T, U> creates an instance of MapObserver<T, U> and subscribe on the original source. The MapObserver<T, U> onNext method transforms the source item based on the transformation function before sending it to the subscriber of ObservableMap<T, U>.

Based on the above observation, we can conclude the following about observable operators.

1. Operators, when chained to an observable will act as the latter’s immediate “observer”.
2. This intermediate observer will operate on each item, not on the entire observable (vertical processing).
3. Since chaining creates a unique process pipeline, order of operations matter.
4. Operators do not trigger runtime (only subscribe does).
5. Operators are also observables that can be subscribed upon.

Note that these conclusions hold true, unless otherwise proven incorrect in subsequent articles.

We will define two important terminology here.

• Upstream — The up side of the processing pipeline from an operator’s point of view.
• Downstream — The down side of the processing pipeline from an operator’s point of view.

Marble Diagrams

Marble diagrams are good visual representations of what happens to an input when passed through an operation. Below is the general structure of a marble diagram.

Image from Rx Wiki

The x-axis represents time while the y-axis is a layer with inputs on top, operations on the middle and outputs on the bottom. The different circular points on the input is an item, the triangular icons are processed items. If an error occurred, it will be denoted with x and a complete event with |. Let’s see what a map marble diagram looks like.

Image from rx docs

The line on top is our input observable. It emits 1, 2 and 3 before completing. On the middle layer we have a map operator that transforms the input value by multiplying it with a factor of 10. The bottom line is the output containing the result of the operation which is 10, 20 and 30. Sounds about right.

On the succeeding articles we will show some marble diagrams alongside the operators for easier visual understanding.

Now that we have been introduced with the concept of operators and marble diagrams, there is nothing holding us back from learning the actual factories and operators in RxJava. Stay tuned.

Check out the other articles in this series.

1. Introduction to Reactive Programming
2. Building your first Observables and Observers
3. In Depth Observables and Observers
4. Marble Diagrams and Operators
5. Observable Factories Part 1
6. Observable Factories Part 2
7. Single, Maybe and Completable
8. Hot and Cold Observables
9. Filtering Operators Part 1
10. Filtering Operators Part 2