Implementating an EventFlow now

[ZakTaccardi]

Looking at the release notes for 1.3.6

For events you should continue to either use BroadcastChannel(1), if you put events into the StateFlow, protect them from double-processing with flags.

I see two preferred ways to publish events as a Flow<Event> to guarantee they are consumed.

1. Guaranteed delivery to a single subscriber - no multiple subscribers
2. Guaranteed delivery to at least single subscriber, but multiple subscribers can receive events

My understanding of BroadcastChannel<Event>(1) is that it will drop events if there are no subscribers at the time, which does not make it very useful in my opinion.

[OrhanTozan]

We are using Channel<Event>() for events. Is there any reason why one would use BroadcastChannel(1) over that?

Edit: Followed by channel.receiveAsFlow().

[elizarov]

We are using Channel<Event>() for events. Is there any reason why one would use BroadcastChannel(1) over that?

@NahroTo It works fine, too.

[elizarov]

My understanding of BroadcastChannel<Event>(1) is that it will drop events if there are no subscribers at the time, which does not make it very useful in my opinion.

@ZakTaccardi It depends on your use-case. With mouse-clicks, etc, you usually want to start listening to them only from the moment of subscription and onwards.

[elizarov]

I'm closing this question. See also #2034 for a configurable SharedFlow primitive that covers a wide-range of event-distribution use-cases.