Mark Murphy

flow() creates a cold Flow. Nothing happens until something starts collecting the output of the Flow — in this case, the collect() call in main(). The events only exist if something is collecting them.

each Flow created by flow() can only be collected once — we cannot have multiple collectors.

These are fairly severe limitations.

SharedFlow is a hot flow that can have multiple consumers, with each consumer seeing the same sequence of emitted events as any other active consumer at the time.

There is a MutableSharedFlow() factory function that creates instances of MutableSharedFlow. You can call emit() on the MutableSharedFlow to send an object to any current subscribers — if there are no subscribers, that object is simply ignored. emit() is a suspend function, so you need to call it from inside of a coroutine.

To publish objects, you use a MutableSharedFlow. To consume, though, you only need either the Flow or SharedFlow interfaces. That way, you can better control who is able to publish

By default, MutableSharedFlow does not cache emitted objects. Everything “flows” through as it is received. However, it does have some options for caching, as part of the MutableSharedFlow() factory function.

The replay parameter represents how many objects should be cached and delivered to new subscribers. The default is 0, so a late subscriber only receives objects emitted after that subscription point. But, you can set this to a higher value if desired.

this buffer is solely for dealing with slow subscribers (or, if you prefer, fast emitters).

The default behavior of MutableSharedFlow() is to have extraBufferCapacity set to 0 and to have onBufferOverflow to be set to BufferOverflow.SUSPEND. This means that a call to emit() will suspend until all subscribers collect the object that is being emitted. This is fine if those subscribers are fairly quick or if the process of emission can wait a while. If that is a problem, extraBufferCapacity adds a buffer that will be used to allow emit() to return right away, if there is buffer space for the object that we are trying to emit.

A StateFlow, like a SharedFlow, can have multiple consumers, and it delivers objects to each consumer. And, a StateFlow is hot, existing regardless of whether there are any consumers at all. The difference comes with backpressure: while SharedFlow has a few configuration options for handling this, StateFlow offers just pure “conflation”: replacing old values with new ones.

A StateFlow has a single-element buffer. In fact, if you are using stock implementations, a StateFlow always has a value — the act of creating a StateFlow requires an initial value. If another object is sent to the flow, it replaces the previous value (including replacing the initial value for the very first sent object).

Consumers of a StateFlow will get the current value delivered to them immediately, plus any new objects sent into the flow while the consumer is active.

Also, any code with access to the StateFlow can reference a value property to get the now-current value, whether that is still the initial value or some other object that was sent into the flow.

Expose StateFlow to objects that need to consume states and also get the last-emitted state on demand
Expose Flow to objects that just need to consume states