In this blog, we are gonna do the experiment with the very 🔥hot
StateFlow as the title of this blog suggests, we have to build a utility which can help us combining multiple
StateFlows into another transformed StateFlow. Before diving into it, let's understand why we need it.
How it's used currently? 🤷
StateFlow is really a useful API for handling stateful business in any application (let's say in Android) which is a pretty simple yet powerful stream. Let's discuss some common usage.
Example 1 - UI State management
When the state of UI is represented as a single model class having immutable state members by inspired from very popular state management library i.e. Redux, this is how we achieve it with StateFlow currently 👇.
LoginState is a state model for the Login screen which has all immutable fields. In the ViewModel, three individual mutable states are created and they're combined to form an immutable
LoginState. At the end, that stream is converted to
StateFlow<LoginState> with using
stateIn(). That's how we do it, right?
Example 2 - Deriving Flow from multiple StateFlows
So assume we're building a library and exposing some API class that returns a
StateFlow which is gonna look like this 👇.
getPreferenceState() returns StateFlow of
PreferenceState and just notice the second function
getMultiplePreferenceState() which is just deriving a flow from multiple StateFlows, we'll discuss about it later.
What's the problem? 🤔
Let's understand problems/flaws in the above two examples
Problem in Example 1
In Example 1, three flows were combined and all of these flows were of type
StateFlow. Still, transformed flow becomes of type
Flow<LoginState> there. So
stateIn() is used to again make it of type
StateFlow<LoginState>. Also, the initial size is calculated twice in the example. First time when declaring individual mutable states and a second time while providing the initial state to
Problem in Example 2
In the Example 2, the method
getPreferenceState() is fine which is returning
StateFlow<PreferenceState>. But the second method
getMultiplePreferenceState() is not returning StateFlow, instead it's returning
Flow. Now, if we try to convert it into StateFlow, this is what the change will look like 👇
To convert combined flow into a StateFlow,
stateIn() is used which needs a
CoroutineScope. Thus, it ultimately restricts to ask for consumer's scope here (which we don't want some time in some use cases. Example, we don't want to control when to start collecting flow, scope it to a specific scope, etc.). Also, the initial state needs to calculate separately. That's the problem.
In both examples, what we want is:
If all the flows which are being combined are StateFlows then derived/transformed Flow should also be StateFlow.
Now, let's find out the solution for this.
On GitHub, issue is already open for this particular use case. Till an official solution is available, let's try to build our own solution. This solution is gonna be mixed learnings from the discussions that happened there.
To be able to combine multiple state flows into a derived state flow, we need to have our own implementation of
StateFlow which fulfills our needs. So the solution looks like this 👇.
Let's understand this:
- The class
TransformedStateFlowhas two properties, the first one is
getValuewhich is a lambda returning value that is provided to overriden member
value. This means whenever
.valueis accessed on StateFlow instance,
getValuelambda will be called and the value will be returned from the calculation result.
- The second parameter,
flowis used in the collector i.e. whenever
TransformedStateFlowis collected, the
flow's collector is delegated to it.
collect()method need return type as
Nothing. That's why we need to provide a collector of StateFlow itself. So
stateIn()is used with the consumer's CoroutineScope which transforms Flow into StateFlow and then it starts collecting.
- Even if
stateIn()used here is suspending function, we know that it'll be not a blocking function because the initial state will be available instantly.
combineStates()function uses it to transform StateFlows into a StateFlow.
This is a core variant of
combineStates() method and multiple variants of combineStates() can be added as per the need and number of parameters required.
Let's say in the above Example 1, we need to combine three flows so type safe function for combining three StateFlows would look like👇.
Cool, let's revisit previous examples and revamp them with this solution.
Example 1's implementation will look like this after using this utility
Looks nice, right? Let's see how well this fits with Example 2 👇.
Yeah! That's it 😎. Now it looks good and perfectly solves our problems. Similarly, we can also use this approach for other operations like mapping a StateFlow into another StateFlow.
Problems with this solution? 🤨
So after all this, there are some problems with this solution due to which it can not fit in some use cases.
- Every time
.valueis accessed, the value from all StateFlows is calculated which won't be good if heavy computation is happening while calculation.
transformis not suspending lambda, suspending tasks can't be done there which was possible in
combinemethod. We can't add support for suspending transformation because we also need to know the transformed value from
If your use case is NOT affected by these mentioned issues, you can definitely use this approach for combining StateFlows and deriving another StateFlow from it.
If you have any feedback on this approach, I've also suggested this approach in the GitHub issue.
That's all, I hope you found this helpful 😉.
"Sharing is caring"
Thank you! 😀