I have a hot flow that is being collected in multi...
# flow
c
I have a hot flow that is being collected in multiple places, but I'd only like for one of the collectors to actually get the emission. Doesn't matter if it's the first collector or last (I suppose last collector wins would work best). But is there a way to do that? I'm a flow noob. sorry if im missing something simple.
s
Sounds like you might just want a
Channel
☝️ 3
c
I looked at BroadtcastChannel and saw it was deprecated. Seems as though some folks on stackoverflow were recommending a flow instead. Let me look again!
s
If you just want one collector to get each item, you aren't looking for broadcast behavior at all
An ordinary channel can fan out values among multiple consumers, no problem
c
gotcha. mustve misunderstood the docs. Reading them again. It seems like a ConflatedChannel might be what I want. or maybe i do just want a basic Channel. hm
g
we use consumable event delivered to potentially multiple consumers (but with one who actually consumes it) with SharedFlow, though it again used for events, so we actually want it to be not lost, but if there is no such reason, MutableSharedFlow with appropriate buffer if necessary Good thing - no need to deal with channels No bad things really
c
Interesting. I tried a sharedFlow to no avail yesterday. it always seems like if there are multiple consumers... all of them will get the event.
a
Have you tried to filter out the events emitted by the hot-flow on your subscriber?
c
yep. no dice. no big deal. the channel fixed it for now. if i get more time i will try to circle back to this
g
> all of them will get the event Sure. all of them get, but with consumable event pattern, only one actually using it, other just ignore I mean like
Copy code
data class Event<out T>(internal val content: T) {
    var consumed = false
        private set

    fun consume(): T? {
        return if (consumed) {
            null
        } else {
            consumed = true
            content
        }
}
c
Oh gotcha. i wonder if theres any benefit to that vs just using a channel though.
g
No need to deal with the channel api at all (even under the hood) Also it's explicit for events, that it has to be handled with only knce One more small advantage, is that if you have multiple subscribers, which is probably a bug, you can debug it, not just silently miss event and have no idea why
The main goal is slightly different for ys, that idea to use stateflow, that event is never lost if there is no subscribers, but also not duplicate it if there are multiple or in case of re-subscrive, which one cannot achieve with shared flow, only by using channel
👀 2