StateFlow<Unit?>

can't be used to represent clicks since it's conflated right (unless a new object is created for each emission...)? But

SharedFlow

will?

Why not just use a

Flow

, or an

awaitOneClick()

function that disables the button when clicked?

You're right in that case... but my actual case is returning a no-param "command" from the viewModel to the view where I need something I can set like a Subject, not just a Flow...

A click is an event, it represents a moment in time that something happens, not a persistent state. Use another type of flow. We created an

EventFlow

, extending

Flow

, for being able to share events, backed by a BroadcastChannel . We use this one mostly for navigation events emitted by the ViewModel

EventFlow

is not going to be covered by

SharedFlow

? Also, my little hack (null, Unit, null, Unit) wouldn't be more efficient than a

BroadcastChannel

implementation?

I have to closely look at the upcoming SharedFlow again. It may indeed handle the use-cases of the EventFlow