blog kotlin



If you need a refresher on hot vs cold flows check out the first article in the series

Hot flow

StateFlow is a hot flow and that means it will be alive and running even though subscriber count is zero. It’s very useful for state management since we want the state to be up to date even if no one is observing it so that when a new subscriber comes the latest, the correct state can be shown on the screen. Another nice feature of StateFlow is the .value parameter, it’s an easy and convenient way of reading the latest value without the need for launching coroutines.

Do we need a hot flow for state management?

If we think about the state of a screen and its logic, let’s say whether a user is signed in or not, does that state depend on an observer? Should it? It should not. If a user completes the sign-in flow, it does not matter if there was an observer to that event, we should be able to persist the fact that the user signed in. Otherwise, we would always need an observer to keep the state “correct, which is not ideal. That is why we need hot flow for state management, and we need the ability to broadcast the latest state to any new subscriber. 

Do we need StateFlow?

Can we just use regular Flow and let a flow handle app states? The problem with regular flows is that they are cold, they are not active if they don’t have any observers/subscribers. This is problematic since we want our state to be up to date and be available at all times. Regular flows are not a good use case for state management. StateFlow on the other hand is the opposite, it is a hot flow which means it will hold its value no matter if there are observers or not.

When to use it?

When we need to keep any kind of state and we want the last value to be accessible directly (through .value) StateFlow is idea for that

When not to use it?

In case we need something to behave like a cold flow. One good example of that is error events, we don’t want to keep errors and show them multiple times, ideally, we would show it only if there are observers and we don’t wanna keep errors stored because that would mean we could potentially show the same error multiple times. This was a common issue with LiveData, it needed a hack (SingleLiveData) in order to show an event only once. 

In the next article, we will explore the world of SharedFlow and how we can leverage it’s API

Leave a Reply

Your email address will not be published. Required fields are marked *