The recent release of kotlinx-coroutines added the concept of shared flow which made broadcast channels obsolete. Here's the background story https://medium.com/@elizarov/shared-flows-broadcast-channels-899b675e805c

suspend fun postEvent(event: Event) {
        _events.emit(event) // suspends until subscribers receive it
    }

Does is suspend until all subscribers receive it, or just the first one? Is that configurable?

all.

With the shared flow, events are broadcast to an unknown number (zero or more) of subscribers. In the absence of a subscriber, any posted event is immediately dropped.

There really isn't a way to add functionality to

SharedFlow

do such a thing without channels? Will it be added in the future, or is it some kind of limitiation of

SharedFlow

?

To do what thing?

To suspend on emit for 0 subscribers for something like a SingleShotEventBus

But that's what Channel already does perfectly. There's no need to duplicate this feature in SharedFlow.

But isn't it much heavier and low-level? Such a requirement isn't common enough to be implemented more high level?

No. Channel perfectly fits there both conceptually and from the implementation standpoint. We don't currently see any need to reimplement it. That was the whole point of the post.

Thanks! The post was very good at clarifying where Flow and its variants play their role in replacing some of the Channel's functions, but I didn't really see the conceptual boundary where Channel is required. The SingleShotEventBus is just brought as an example of when a Channel should be used instead because SharedFlow can't do such a thing, but not WHY Channel SHOULD do that and NOT SharedFlow...

It is a conceptual difference between a flow and channel. A channel is a channel -- it is a well known concept in software engineering, it does it thing well, and there's no need to reinvent/reimplement it.

So

BroadcastChannel

will be removed or renamed?

BroadcastChannel

will be deprecated and removed in the future.

So a

SingleShotEventBus

for multiple listeners needs to use

receiveAsFlow().shareIn(..)

... I guess all this is starting to make sense now.. thanks alot!

No. No

shareIn

. Just

receiveAsFlow()

Slightly tangential question - why did you pick delicious cherry tomatoes as a header image for the story?

Great dish for sharing! ❤️