```combine( flowOne(), flowTwo(), flow...

# coroutines

[K Merle]

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.

[K Merle]

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
)

[gildor]

First should work too

[gildor]

difference between 1 and 2 is that in 2 you start collecting flowThree() again on every flowOne and Two change

[Francesc]

These are not equivalent though, with flatmap you are restarting the third flow at each emission of first or second

[gildor]

So if you have to recollect flowThree every time, you have to use flatMapLatest version, if it’s unnecessary, option 1 is better

[K Merle]

I do want to restart as flowThree() is network request.

[Francesc]

Then use 2

[gildor]

simple collect is never restarting flow

[Francesc]

The flatmap will switch and call the method that gives you flowThree

[gildor]

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

[K Merle]

Yea, you are correct. I do have a Loading state already, having a suspend returning a single state, depending on a result seems sufficient.

[gildor]

viewModelScope + ioDispatcher

And one more point. Why do you need io dispatcher for this?

[K Merle]

Isn't viewModelScope running on main thread?

[gildor]

yes

[K Merle]

I didn't want to run it on main thread.

[gildor]

Run what?

[K Merle]

upstream of these flows?

[gildor]

do those flows are blocking?

[gildor]

because essentially only collction will run on iodistpatcher

[gildor]

with doesn’t look necessary if your flows builder/operations are not blocking

[K Merle]

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.

[gildor]

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 Merle]

I see your point Andrey, never thought of that like that, thanks.