The main difference between SharedFlow and StateFlow

Question

What are the differences between SharedFlow and StateFlow?

And how to use these in MVI architecture? is it better to use simple Flow or these as states and events?

Answer 1

Flow is cold!, means it emits data only when it is collected. Also Flow cannot hold data, take it as a pipe in which water is flowing , data in flow only flows , not stored(no .value function).

Unlike flow , stateflow and sharedflow are hot streams means they emit data even when there is no collector. Also if there are multiple collectors ,a new flow will be run for each collector, completely independent from each other. SharedFlow and StateFlow are Flows that allows for sharing itself between multiple collectors, so that only one flow is effectively run for all of the simultaneous collectors. If you define a SharedFlow that accesses databases and it is collected by multiple collectors, the database access will only run once, and the resulting data will be shared to all collectors.

What are the differences between SharedFlow and StateFlow?

StateFlow

Stateflow takes an initial value through constructor and emits it immediately when someone starts collecting. Stateflow is identical to LiveData. LiveData automatically unregisters the consumer when the view goes to the STOPPED state. When collecting a StateFlow this is not handled automatically , you can use repeatOnLifeCyCle scope if you want to unregister the consumer on STOPPED state. If you want current state use stateflow(.value).

SharedFlow

StateFlow only emits last known value , whereas sharedflow can configure how many previous values to be emitted. If you want emitting and collecting repeated values , use sharedflow.

Answer 2

StateFlow is a subtype of SharedFlow that has more restricted configuration options (making it simpler to set up and better performing), but it has the addition of a value property.

StateFlow's value property represents its current value and can be checked from anywhere, including outside of a coroutine. In a MutableStateFlow, you can also emit values from the flow by setting this value property, even from outside any coroutine. MutableSharedFlow has a tryEmit() function that can be used from outside coroutines, but its success when called depends on current state and buffer configuration. On the other hand, setting MutableStateFlow.value always succeeds.

The existence of this concept of a single current value means some of the configurable features of a SharedFlow are not available, because they would break the concept. Here are some of the restrictions:

1. The replay has to be 1, because there is only 1 current value.
2. There cannot be any buffer aside from the 1 current value, because there is only 1 value. The one current value cannot be dropped, but old values are always dropped and never seen by a collector if it takes a while to collect the previous value.
3. It only determines the current value to be changed if you change it to a functionally inequivalent value. This is like enforcing the distinctUntilChanged() operator on a base SharedFlow.
4. A StateFlow must have an initial value, because it always has a current value. Base SharedFlow doesn't need an initial value.

Hot flows like SharedFlow and StateFlow are useful if your flow logic must monitor something or do IO, and you want to avoid repeating that time-consuming work when there are multiple possible collectors. On Android, it can be used to preserve the flow during a screen rotation, during which collectors might be destroyed and new collectors created to collect the same flow.