Can someone please tell why.. I have a shared flow that emits a value when user taps a button:

sharedFlow.collect { println("first") }

sharedFlow.collect { println("second") }

But actually 10 taps results in 10 prints of "first" message and never prints the "second" one. Does the shared flow accept only one collector, or could it's behavior widely depend on configuration and usage?

Because

collect

is a suspend function, which returns only when upstream flow is completed, which is never the case if you use StateFlow (it never completes)

Thank you for your response but (if I got you right) I tried to do smth like this:

MainScope().launch {
    sharedFlow.collect { println("value #1") }
    sharedFlow.collect { println("value #2") }
}

But still only first collector gets called..

If I understand correctly, those two collects are still in the same scope, so to be able to get those two collect called you would need to write:

MainScope().launch {
    sharedFlow.collect { println("value #1") }
}
MainScope().launch {
    sharedFlow.collect { println("value #2") }
}

it would launch two coroutines without blocking each other

@KamilH so the

collect()

blocks the logical coroutine (not a physical thread), and we can just create several logical coroutines within single physical thread to get each

collect()

working within its own coroutine? I mean: "Physical" by operating system, not by CPU; and "logical" as just callbacks-driven system

Yes, exactly. Also this is what

launchIn

operator does under the hood. Creates a new coroutine and it blocks only “itself”

Thank you very much, you saved me several hours I still have an unknown behavior in another place but first will try to resolve it knowing the details above

two collects are still in the same scope

To be precise, it’s not an issue of the same scope, it’s perfecly fine to have many coroutines on the same scope, problem that second collector not even start collecting, because first suspend and never return

So.. as I understand, the words above should look like:

two collects are still in the same coroutine

it’s kinda tricky explanation %)

"two collects are still in the same scope", this scope means os thread or another scope that I should learn? Currently I do understand the

collect()

inside any coroutine like a detached loop with its own separate mini life

inside any coroutine like a detached loop with its own separate mini life

It’s not detached, this is the point, it’s the same as any other loop

But the coroutine converts to complex logic that contains switch/callback, right?

right

And so it can't go to following commands within the coroutine as it's already busy 100% by

collect()

infinite (in theory) callbacks?

it’s not really busy, it’s just waits and do not proceed to the next call

Well, the callback firing does not cause this coroutine to go to the next command

Isn’t this the whole point of coroutines? 🙂

I agree, but you said:

it’s not really busy, it’s just waits and do not proceed to the next call

And I want to modify my answer so I don't understand it like thread blocking (busy), I do understand it like callbacks waiting

yep, correct, this is the main advantage of coroutines, Threads.sleep doesn’t do any work, but it makes thread busy and prevents using this system resource (mostly RAM), coroutines do not have such problem, yes coroutine is suspended, but it’s light-weight object, not a system resource like thread

And... sorry, how can I

launch()

coroutine within the current scope without having specify in hard manner

MainScope

,

DefaultScope

? Just "do this here in place"?

how can I 

launch()

 coroutine within the current scope without having specify in hard manner

I don’t understand your question. You already can use launch directly if you are inside of another coroutine scope block, launch is an extension function for CoroutineScope

Yep, it should be better then using your attention for a while And I'm working on multi-platform part of code between iOS and Android

anyway, in case of code related to UI you need some owner for the scope, which will handle lifecycle of this scope for you