RxJava Ninja: Hot and Cold Observables

Photo by Easton Oliver 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).

In today’s article, we will be talking about 2 types of observable, hot and cold observables.

Cold Observables

Cold observables are sequences that only emits item upon subscription. Each observer will have its own set of items emitted to them and depending on how the observable was created, will have different instances of emitted items. Let’s see what this looks like by example.

An interval observable was subscribed upon by two observers at a different time. Let’s see what this actually does.

Observer 1: 0
Observer 1: 1
Observer 1: 2
Observer 1: 3
Observer 2: 0
Observer 1: 4
Observer 2: 1
Observer 1: 5
Observer 2: 2
Observer 1: 6
Observer 2: 3

Regardless of whether the same observable instance is used, both observers started from 0. This is a cold observable. This happens because a different observable source is being created for each observer. Most convenience factories are by default cold observable factories.

In reality, data-driven observables are most likely cold. Even those cases wherein the same observable yields different results (like HTTP GET, database query). The idea here is that, the data or operation is being “replayed” to every observer. For those familiar, some real-world examples of cold observables are Retrofit and Room queries.

Hot Observables

In contrast to cold observables, hot observables emit items regardless of whether there are observers. In a hot observable, there is a single source of emission and depending on when observers subscribe, they may miss some of those emissions.

Most common examples of this are UI events. For example in Android, a click event can be represented as an observable. And it is only logical for observers to receive only the events after they subscribed, so the click observable has no need to cache them for replay.

There are many ways to implement hot observables. One of them is Subjects and we will discuss them in the future when we discuss Multicasting in detail. For now we will use a special type of observable called ConnectableObservable.

ConnectableObservable

A ConnectableObservable is a single observable source for different observers. The main difference aside from being a single observable source is that calling subscribe on a ConnectableObserver will not trigger emission, but connect will.

To convert an observable to a connectable one, you can use the publish operator. Publishing the observable will make it hot and will not replay the items for observers after activation.

The above code demonstrates how to publish an observable. However, running the code will not emit anything. That is because a connectable observer requires the connect method to be invoked to begin emission. Let’s try subscription at two different time.

Let’s observe it in action.

Observer 1: 0
Observer 1: 1
Observer 1: 2
Observer 1: 3
Observer 2: 3
Observer 1: 4
Observer 2: 4
Observer 1: 5
Observer 2: 5
Observer 1: 6
Observer 2: 6
Observer 1: 7
Observer 2: 7

Notice that the observer 2 received the same emission as observer 1 upon subscription. This observable behavior of emitting to all observers simultaneously is called Multicasting and we will visit this feature again in the future. Note that emission will start after connect invocation so it is perfectly valid to setup multiple observers beforehand to synchronize them.

Calling connect will return a subscription that can be disposed. This implies that individual unsubscription of observers does not affect the connectable observable. Only the disposal of the subscription from connect can actually stop the emission. Now, how do we automate this connect on observer subscription and dispose if there are no active observers anymore?

There is a method in ConnectableObservable class called refCount that will do just that. refCount returns an observable that will be connected at subscription of an observer and will terminate if there are no more observers. Let’s demonstrate that.

Two observers will subscribe at different times and unsubscribe later. Then a third observer will subscribe right after that. Based on the defined behavior of refCount, the observable should have been disposed after unsubscription of the 2 observers. In the 3rd subscription, the observable should be a fresh one already. Let’s verify.

Observer 1 subscribed
Observer 1: 0
Observer 1: 1
Observer 1: 2
Observer 2 subscribed
Observer 1: 3
Observer 2: 3
Observer 1: 4
Observer 2: 4
Observer 1 unsubscribed
Observer 2 unsubscribed
Observer 3 subscribed
Observer 3: 0
Observer 3: 1

So far so good. Also, there are different variants of refCount such as tracking a minimum observer count, timeout before disposal, etc, so choose one to your liking.

That’s it for hot and cold observables. Remember, data-driven is cold, event-driven is hot.

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