You need to elaborate a bit more what's the use case. But for short answer as long it fits your use case, why not.
f
Francesc
06/10/2022, 2:07 AM
depends on your requirements. As a
StateFlow
you get an implicit
distinctUntilChanged
and it emits the current value when a new collector starts collecting, is that what you want?
I'm a bit puzzled by the "AppState" part though, if you mean a class that represents your UI state that the UI consume, then you should not have `flow`s here.
d
DALDEI
06/10/2022, 4:39 AM
@Francesc could you elaborate on why you shouldnt have a flow in a UI State consumed by UI.
f
Francesc
06/10/2022, 5:38 AM
Well, the state is going to be consumed in the UI, how would you consume a flow in there? Every time the state is emitted you would have a new flow, you'd have a flow inside another flow or inside a mutableState
c
Colton Idle
06/10/2022, 11:39 AM
I'm not necessarily consuming it in my UI. But even if I was... why wouldn't I be able to do that?
In this case I just want to represent that my app has a user signed in or not, or if the user changes (user logs out and a new user logs in)
d
DALDEI
06/10/2022, 5:39 PM
@Francesc -- I do not understand how this relates to UI or no UI. I do see its not obvious how to handle a state flow with its value another flow -- I suspect flatten() would work but not sure.
Howeve @Colton Idle if what your looking for is a state with the current users, and a way of notifying when the user changes, its simpler. Thats is a MutableStateFlow<User> NOT MutableStateFlow<Object containing FLow<User>>
say you have a 'cold flow' , maybe from callbackFlow<>(), OR you make a plain MutableStateFlow<User>()
and have code somewhere that does a flow.value=user
now you have a state flow which you can get the current user
flow.value == Current User
And you can be notified by
flow.onEach { gotanewuser(it) }.launchIn( scope )