Posted by: Patryk  Kosieradzki

See the original article on my website:
https://patrykkosieradzki.com/livedata-vs-sharedflow-and-stateflow-in-mvvm-and-mvi-architecture/

If you’re a Polish speaker then you can listen to a podcast I created, based on this article:

Last year kotlinx.coroutines library introduced two new Flow types, SharedFlow and StateFlow, which also have their mutable types — MutableSharedFlow and MutableStateFlow.

Android community started wondering… Which one should I use now? LiveData or the new types? Is LiveData deprecated now?

Let’s answer all of the questions.

LiveData

Most of you should already know LiveData and how it works. LiveData is a data holder class that can be observed within a given lifecycle.

Example:
You create a LiveData object in a ViewModel class to hold some ViewStateand observe it in the Fragment to update UI when ViewState changes.

LiveEvent

OK, how about some single operations. For example, how can the ViewModel tell Fragment to show a Snackbar?

By using the LiveEvent (or SingleLiveEvent), a modified LiveData to handle single events, which means it emits the data just once, not after configuration changes again. The same solution can be used to display a toast, dialog, navigate to other Fragment, etc.

So what is exactly the problem with LiveData and LiveEvents?

LiveData is an Android library

As you know, LiveData is a part of Jetpack and it is an Android library. It is has to be handled in Android classes and with their lifecycle. It is closely bound to the UI, so there is no natural way to offload some work to worker threads.

In Clean Architecture terms, LiveData is OK to be used in Presentation Layer, but it is unsuitable for other layers, like Domain for example, which should be platform-independent (only Java/Kotlin module), Network Layer, Data Layer, etc.

LiveData is OK for MVVM, but not so much for MVI

MVI stands for Model–View–Intent and it’s a design pattern that uses Unidirectional Data Flow to achieve something like we already have in Flux or Redux, etc.

For example:

Then we can use it like this:

SharedFlow and StateFlow to the rescue!

Let’s talk about SharedFlow first

SharedFlow is a type of Flow that shares itself between multiple collectors, so it is only materialized once for every subscriber. What else it can do?

1. SharedFlow in contrast to a normal Flow is hot, every collector uses the same SharedFlow, because it is shared.
2. SharedFlow has its buffer called replay cache. It keeps a specific number of the most recent values in it. Every new subscriber gets the values from the replay cache and then gets new emitted values. You can set the maximum size of the replay cache in replay parameter in the constructor. A replay cache also provides buffer for emissions to the shared flow, allowing slow subscribers to get values from the buffer without suspending emitters. A SharedFlow with a buffer can be configured to avoid suspension of emitters on buffer overflow using the onBufferOverflow parameter, which is equal to one of the entries of the BufferOverflow enum. When a strategy other than SUSPENDED is configured, emissions to the shared flow never suspend.
3. If you use the default SharedFlow constructor of MutableSharedFlow then the replay cache won’t be created.

You can also transform a normal Flow into a SharedFlow using this extension method:

fun <T> Flow<T>.shareIn(
  scope: CoroutineScope, 
  started: SharingStarted, 
  replay: Int = 0
): SharedFlow<T> (source)

Let’s see how we can use SharedFlow to handle events. The BaseViewModel and BaseFragment would look something like this:

And then in ViewModel you can handle triggered events:

onAddAddressClicked() and onRemoveAddressClicked(address: Address) are used in DataBinding, so we have to trigger events here. Can you see how simple this is? Clean, readable code that can be easily tested (tests included in the Github Repository at the end of the article)

What about StateFlow?

StateFlow is a SharedFlow with a couple other things:

1. When creating a StateFlow you have to provide its initialState.
2. You can access StateFlow’s current state by .value property, just like in LiveData.
3. If you add a new collector in the meantime then it will automatically receive current state. Also, it won’t get any info about previous states, but only the new ones that will be emitted.

You can also transform a normal Flow into a StateFlow using this extension method:

fun <T> Flow<T>.stateIn(     
  scope: CoroutineScope,      
  started: SharingStarted,      
  initialValue: T 
): StateFlow<T> (source)

Let’s see how we can use StateFlow and SharedFlow together to update state after event is handled. The BaseViewModel and BaseFragment would look something like this:

And then in ViewModel you can update state like this: