https://kotlinlang.org logo
Title
l

luke_c

09/28/2021, 3:30 PM
In the context of Android and replacing SingleLiveEvent. can anyone explain why a BUFFERED Channel seems to be preferred to the default RENDEZVOUS Channel?
w

William Reed

09/28/2021, 3:42 PM
keep in mind
Channel
is a considered a low level primitive compared to
StateFlow
and
SharedFlow
. Those two might also be worth checking out
are you referring to the default
Channel
constructor?
i would think
MutableSharedFlow(0, 0, onBufferOverflow = BufferOverflow.DROP_LATEST)
is analogous to
SingleLiveEvent
l

luke_c

09/28/2021, 3:45 PM
It isn’t unfortunately as any events emitted when there are no subscribers would be dropped which could happen during an Android configuration change, hence the need for a Channel which will suspend/buffer until there is a subscriber
w

William Reed

09/28/2021, 3:46 PM
well i think you’ve answered your question then - the buffer retains emissions that could occur in that time
l

luke_c

09/28/2021, 3:48 PM
So with a buffered Channel, it could still send events while there is no subscribers, whereas with a rendezvous Channel no further events would be able to be sent due to the suspending behaviour?
w

William Reed

09/28/2021, 3:49 PM
i think that’s correct
u

uli

09/28/2021, 11:06 PM
But it would suspend until there is a receiver (depending on how you send). so no lost events either. but potential dead locks :-)
w

William Reed

09/29/2021, 1:26 PM
unless your using
tryEmit