Like @deividasstrioga, I'm a bit confused as well. SingleLiveEvent was originally envisioned as an output of a view model to be observed by a view. LiveEvent made a serious attempt to simplify that but again, it remained a view model output. I don't see how it can ever be replaced with SharedFlow.

The confusion here seems to be terminology.

First you define events as "...single events, which means it emits the data just once, not after configuration changes again" but then go on to reference the thing that should only be observed by the view/fragment once and once only as an effect, not an event.

I get that the view/fragment needs to observe the effects flow to see one shot actions to be taken. And, yes, I agree with you, that works well with a channel.

What I can't understand is why the view/fragment would ever observe the events flow. In the MVI world, I can see the view/fragment emitting events for the view model to in turn observe and handle. But I don't see why the fragment would observe those events or for that matter care what type of flow it is, ShareFlow or otherwise.

From the view/fragment's point of view, what does the events flow offer by being observed that the uiState and the effects flow do not offer? Why would the fragment observe and take action on the events flow differently than the other two flows?

I feel like your article, unfortunately, confuses the reader with events with effects but maybe I'm not fully understanding things.