https://kotlinlang.org logo
Title
k

K Merle

01/17/2022, 5:45 AM
combine(
    flowOne(),
    flowTwo(),
    flowThree()
) { _, _, flowThree->
    flowThree
}.stateIn(
    viewModelScope + ioDispatcher,
    SharingStarted.WhileSubscribed(NETWORK_RESULT_SHARING_TIMEOUT),
    Result.Loading
)
Should 
flowThree
 emit values here when collected? FlowThree should emit every time flowOne() or flowTwo() emit values.
This works, but I am not sure if it's optimal.
combine(flowOne(), flowTwo()) { _, _ -> }.flatMapLatest {
    flowThree()
}.stateIn(
    viewModelScope + ioDispatcher,
    SharingStarted.WhileSubscribed(NETWORK_RESULT_SHARING_TIMEOUT),
    Result.Loading
)
g

gildor

01/17/2022, 5:52 AM
First should work too
difference between 1 and 2 is that in 2 you start collecting flowThree() again on every flowOne and Two change
f

Francesc

01/17/2022, 5:53 AM
These are not equivalent though, with flatmap you are restarting the third flow at each emission of first or second
g

gildor

01/17/2022, 5:54 AM
So if you have to recollect flowThree every time, you have to use flatMapLatest version, if it’s unnecessary, option 1 is better
k

K Merle

01/17/2022, 5:55 AM
I do want to restart as
flowThree()
is network request.
f

Francesc

01/17/2022, 5:55 AM
Then use 2
g

gildor

01/17/2022, 5:55 AM
simple collect is never restarting flow
f

Francesc

01/17/2022, 5:57 AM
The flatmap will switch and call the method that gives you flowThree
g

gildor

01/17/2022, 6:00 AM
I do want to restart as 
flowThree()
 is network request.
Just a question, why do you need flow for this, wouldn’t suspend function be more clear? because you would replace flatMapLatest with mapLatest/map (depedning on your use case) and it would be clear that it require restart every time, just as any other function call
1
k

K Merle

01/17/2022, 6:01 AM
Yea, you are correct. I do have a Loading state already, having a suspend returning a single state, depending on a result seems sufficient.
g

gildor

01/17/2022, 6:05 AM
viewModelScope + ioDispatcher
And one more point. Why do you need io dispatcher for this?
k

K Merle

01/17/2022, 6:05 AM
Isn't viewModelScope running on main thread?
g

gildor

01/17/2022, 6:05 AM
yes
k

K Merle

01/17/2022, 6:05 AM
I didn't want to run it on main thread.
g

gildor

01/17/2022, 6:05 AM
Run what?
k

K Merle

01/17/2022, 6:06 AM
upstream of these flows?
g

gildor

01/17/2022, 6:06 AM
do those flows are blocking?
because essentially only collction will run on iodistpatcher
with doesn’t look necessary if your flows builder/operations are not blocking
k

K Merle

01/17/2022, 6:08 AM
I don't think they are blocking, thought it would be a good practice in general to put everything to an IO by default, but you might be right, I might have to look around, thanks.
g

gildor

01/17/2022, 6:12 AM
good practice in general to put everything to an IO by default
I think it’s depends what is everything, you do not wrap everything to io if those operations are non blocking and the only operation which will run on IO is collection of them In our code we prefer to handle all CPU heavy/IO blocking operations on level of suspend functions, flow builders, and do not allow them to leak further, otherwise you don’t really cannot believe to any suspend function to be called from main thread or even any suspend function
k

K Merle

01/17/2022, 6:15 AM
I see your point Andrey, never thought of that like that, thanks.