The recent release of kotlinx-coroutines added the...

# feed

[elizarov]

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

[dave08]

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?

[elizarov]

all.

[dave08]

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?

[elizarov]

To do what thing?

[dave08]

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

[elizarov]

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

[dave08]

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

[elizarov]

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.

[dave08]

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...

[elizarov]

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.

[elizarov]

A BroadcastChannel, in essence, was a misnomer. We invented this name before we had sketched out the concept of a flow. As soon as we did it, we immediately saw that it is, conceptually, a flow, not a channel.

[dave08]

So BroadcastChannel will be removed or renamed?

[elizarov]

BroadcastChannel will be deprecated and removed in the future.

[dave08]

So a SingleShotEventBus for multiple listeners needs to use receiveAsFlow().shareIn(..)... I guess all this is starting to make sense now.. thanks alot!

[elizarov]

No. No shareIn. Just receiveAsFlow()

[psh]

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

[elizarov]

Great dish for sharing! ❤️