# A note about the warmth of the share and replay operators

DevFeed: [A note about the warmth of the share and replay operators](<https://devfeed.tech/articles/a-note-about-the-warmth-of-the-share-and-replay-operators-25206.md>)

Original publisher: [Read original article](<https://kau.sh/blog/a-note-about-the-warmth-share-operator/>)

Author: Kaushik Gopal

Published: 2015-07-11T07:00:00Z

Content type: tutorial

Language: en

Sources: [Kaushik Gopal's Site](<https://devfeed.tech/sources/kaushik-gopal-s-site.md>)

Topics: [RxJava](<https://devfeed.tech/topics/rxjava.md>), [Android](<https://devfeed.tech/topics/android.md>), [Caching](<https://devfeed.tech/topics/caching.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [cache](<https://devfeed.tech/tags/cache.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [screen](<https://devfeed.tech/tags/screen.md>)

## AI overview

This tutorial explains how RxJava observables behave across Android activity rotation. It examines worker fragments and the share operator, showing why share can behave as "warm": cold for the first subscriber and hot for subsequent subscribers.

## Source excerpt

A common question most android developers have when using RxJava is: how do I cache or persist the work done by my observables over a configuration change? If you start a network call and the user decides to rotate the screen, the work spent in executing that network call would have been in vain (considering the OS would re-create your activity). There are two widely accepted solutions to this problem: store the observable somewhere as a singleton, possibly apply the cache operator and re-subscribe on activity recreation house your observable in a retained "worker" fragments 1 I whipped up a quick example on github to demonstrate the second technique (which is generally my choice of poison). Now I've used the technique of worker fragments (successfully) a bunch of times before so I was a little surprised to see the example not work. Let's go over the use case again: You have an observable that executes a long running network call. Before the call completes, you perform an activity rotation. After the activity is recreated, you continue the network call from where it left off or just use the result if it completes before your activity recreation process. Instead of simulating this network call use case I decided to just fake it with a "hot" observable instead (which makes the use case a tad bit different but would help demonstrate the solution equally well). If you're looking for a quick simple example that demonstrates the difference between a hot and cold observable, I strongly recommend watching this egghead.io video on the subject. In fact, I used the exact same concoction of operators for my example: Observable .interval(1, TimeUnit.SECONDS) .map(new Func1<Long, Integer>() { @Override public Integer call(Long aLong) { return aLong.intValue(); } }) .take(20) .share(); A little more investigation revealed that the share operator I used to fake the source stream was not really hot but "warm". This is easier explained with Marble diagrams: Here's how we expect share