Hi, Everyone Can anyone please explain why we need SingleLiveEvent with example i didn`t understand,...

# android

[Asad Mukhtar]

Hi, Everyone Can anyone please explain why we need SingleLiveEvent with example i didn`t understand, i have seen the same implementation working with MutableLiveData and SingleLiveEvent ?

[Adam Powell]

You don't. SingleLiveEvent was created as a band-aid for design flaws that are better addressed in other ways. See https://developer.android.com/jetpack/guide/ui-layer/events

[Nemanja Mladenović]

Depending on what you believe you might want events in general. I, personally, don't buy the whole narrative in the new guideline of modeling events as state looks weird to me.

[Nemanja Mladenović]

This lib can be useful for pure events
https://github.com/Zhuinden/event-emitter

[Adam Powell]

it's not modeling events as state, it's reducing state in longer-lived locations. Important distinction. 🙂

[Adam Powell]

There are indeed cases where sometimes you want events published from a longer-lived entity and consumed by a shorter-lived entity, but if you are in that situation then you by definition have multiple consumers. Multiple consumers of events adds significant complexity to your system and most of the time it's simpler to avoid it altogether by restructuring the design a bit.

[Adam Powell]

Multiple consumers of state does not introduce the same ambiguities and edge cases. You don't have to worry about what happens when an event is fired before consumers are listening. You don't have to worry about what happens when multiple consumers are present and you expect exactly-once processing. You don't have to worry about what happens when the wrong consumer among multiple "claims" an event instead of the "right" or intended consumer.

[Adam Powell]

SingleLiveEvent attempts to solve some of those things, and it does at most a halfway job of it

[Adam Powell]

If you've ever written a test where you're playing with launch(start = CoroutineStart.UNDISPATCHED) to get the timing of a hot flow collection just right, or a set of waitForIdle-like calls to set up a test harness in exactly the right way, you've experienced this problem space.

[Adam Powell]

If you really have multiple consumers of hot events where the event stream is stateless and it doesn't matter if 0-N consumers see and act on the same event, then sure, use events, you're good to go. As soon as you start adding store-and-forward mechanisms for when no one is listening yet, you're off to the races with all of the error-prone situations above because it says something about the nature of your event stream.

[Adam Powell]

Those are the cases where reducing to state at the producer is going to be a lot less error-prone.

[Nemanja Mladenović]

Tnx for the detailed answer I cannot understand half of it 😃 but in reality events always emerged in my projects as a way to send navigation command from viewmodel to fragment and/or snackbar/toast events I don't care that much about multiple listeners or that I trigger event and worry about listeners not being attached or similar. The lib above is a perfect example of what I need events for in general since we cannot have nav controller directly inside viewmodels which would be perfect like in simple stack lib.