In the context of Android and replacing SingleLive...

# coroutines

[luke_c]

In the context of Android and replacing SingleLiveEvent. can anyone explain why a BUFFERED Channel seems to be preferred to the default RENDEZVOUS Channel?

[William Reed]

keep in mind Channel is a considered a low level primitive compared to StateFlow and SharedFlow . Those two might also be worth checking out

[William Reed]

are you referring to the default Channel constructor?

[William Reed]

i would think

MutableSharedFlow(0, 0, onBufferOverflow = BufferOverflow.DROP_LATEST)

is analogous to SingleLiveEvent

[luke_c]

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

[William Reed]

well i think you’ve answered your question then - the buffer retains emissions that could occur in that time

[luke_c]

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?

[William Reed]

i think that’s correct

[uli]

But it would suspend until there is a receiver (depending on how you send). so no lost events either. but potential dead locks :-)

[William Reed]

unless your using tryEmit