SingleLiveEvent
SingleLiveEvent is a subclass of MutableLiveData with one Observer Observing it at a time, therefore it is aware of the view lifecycle.
Problem
The problem starts because LiveData promises some advantages which you can find in its documentation. I list them here in the following way:
Ensuring your UI matches the state of your data, LiveData follows the observer pattern. LiveData notifies Observerobjects when their lifecycle state changes. You can wrap your code to update the UI in these Observerobjects. Instead of updating the UI every time your app data changes, your observers can update the UI every time something changes.
No memory leaks Observers are bound to Lifecycle objects and clean up after themselves when their associated lifecycle is destroyed.
No crash due to stopped activity If the observer lifecycle is inactive, as in the case of activities in the back stack, then the LiveData activity will not be received.
No more manual lifecycle handling UI components, just observe the relevant data and don't stop or resume the observation. LiveData automatically manages all of this as it is aware of relevant lifecycle state changes while observing.
Data is always up to date If a lifecycle becomes inactive, it receives the latest data once it becomes active again. For example, an activity that is in the background receives the latest data right after it returns to the foreground.
Correct configuration changes If an activity or fragment is recreated due to a configuration change, such as a device rotation, the activity or fragment will immediately receive the latest available data.
Sharing resources You can extend the LiveData object using the singleton pattern to wrap a system service so that it can be shared across your app. The LiveData object is connected to the system service once, and then any observer that needs the resource can watch the LiveData object. For more information.
But some of these benefits may not be useful in all scenarios and there is no way to disable them when you create a LiveData instance. For example, the “data is always up to date” property cannot be disabled and the main issue this article aims to address is how to disable it.
However, I have to thank Google for the "precise configuration changes" property, which is very useful. But still, we should be able to disable it when we want. I don't have a scenario where I need to disable it but please let people vote.
Why use SingleLiveEvent
For UI event propagation, like Click. For example Handling RecyclerView Click Event With SingleLiveEvent .
Why not use LiveData? Because LiveData will be triggered again on screen configuration change/rotation. We want to handle UI events like click only once.
So, What's the Solution here?
For this type of task, SingleLiveEvent class comes to the rescue. It is nothing but an extension of MutableLiveData class but emits data only once whenever required.
We need to create a class file named SingleLiveEvent in our project and to use it in ViewModel you just need to use it in the same way as we used LiveData,
private val uploadData = SingleLiveEvent<String>()
fun getUploadData (): SingleLiveEvent<String> {
return uploadData
}