Single live event android

Android SingleLiveEvent (of LiveData) for UI Event

Aug 8, 2020 · 3 min read

SingleLiveEvent:-

SingleLiveEvent is a subclass of MutableLiveData with a single Observer Observing it at a time, hence it is aware of view’s lifecycle.

The problem

The problem is started since LiveData promises some advantages where you can find them in its documentation. I list them here by the way:

Ensures your UI matches your data state LiveData follows the observer pattern. LiveData notifies Observer objects when the lifecycle state changes. You can consolidate your code to update the UI in these Observer objects. Instead of updating the UI every time the app data changes, your observer can update the UI every time there’s a change.

No memory leaks Observers are bound to Lifecycle objects and clean up after themselves when their associated lifecycle is destroyed.

No crashes due to stopped activities If the observer’s lifecycle is inactive, such as in the case of an activity in the back stack, then it doesn’t receive any LiveData events.

No more manual lifecycle handling UI components just observe relevant data and don’t stop or resume observation. LiveData automatically manages all of this since it’s aware of the relevant lifecycle status changes while observing.

Always up to date data If a lifecycle becomes inactive, it receives the latest data upon becoming active again. For example, an activity that was in the background receives the latest data right after it returns to the foreground.

Proper configuration changes If an activity or fragment is recreated due to a configuration change, like device rotation, it immediately receives the latest available data.

Sharing resources You can extend a LiveData object using the singleton pattern to wrap system services so that they can be shared in your app. The LiveData object connects to the system service once, and then any observer that needs the resource can just watch the LiveData object. For more information.

But some of these advantages cannot be useful in all scenarios and there is no way to disable them when you instantiate a LiveData. For instance, the property of “always up to date data” cannot be disabled and the main problem which this article wants to tackle is a way to disabling it.

H o wever, I have to thank Google for the “proper configuration changes” property, which is so so useful. But still, we need to be able to disable it when we want. I have no scenario where I need to disable it but please let people choose.

Why use SingleLiveEvent:-

• For propagation of UI event, such as Click. E.g. Handle RecyclerView Click Event With SingleLiveEvent.
• Why not use LiveData ? Because LiveData will trigger again upon configuration change/screen rotation. We want to handle UI events such as click once only.

So, What is the Solution here?

For these types of tasks, SingleLiveEvent class came for the rescue. It is nothing but an extension of the MutableLiveData class but it emits the data only once whenever required.

We need to create a class file called SingleLiveEvent in our project and the SingleLiveEvent class looks like,

and to use it in ViewModel you just need to use it similarly how we use LiveData,

and in the Activity/Fragment file, we will use similarly how we used in the above code,

The above code will only emit the data only once whenever it is required and then will stop observing.

To read more about Event Observer, We will discuss in part-2… or until you can read from below link-

Источник

LiveData with SnackBar, Navigation and other events (the SingleLiveEvent case)

2021 Update: Working with Kotlin? I recommend you move to Channels! While we write official guidance, check out this👌 post .

A convenient way for a view (activity or fragment) to communicate with a ViewModel is to use LiveData observables. The view subscribes to changes in LiveData and reacts to them. This works well for data that is displayed in a screen continuously.

However, some data should be consumed only once, like a Snackbar message, a navigation event or a dialog trigger.

Instead of trying to solve this with libraries or extensions to the Architecture Components, it should be faced as a design problem. We recommend you treat your events as part of your state. In this article we show some common mistakes and recommended approaches.

❌ Bad: 1. Using LiveData for events

This approach holds a Snackbar message or a navigation signal directly inside a LiveData object. Although in principle it seems like a regular LiveData object can be used for this, it presents some problems.

In a list/detail app, here is the list’s ViewModel:

In the View (activity or fragment):

The problem with this approach is that the value in _navigateToDetails stays true for a long time and it’s not possible to go back to the first screen. Step by step:

1. The user clicks the button so the Details Activity starts
2. The user presses back, coming back to the list activity
3. The observers become active again, after being inactive while activity was in the back stack
4. The value is still true so the Details activity is incorrectly started again

A solution would be to fire the navigation from the ViewModel and immediately set the flag to false:

However, one important thing to remember is that LiveData holds values but doesn’t guarantee to emit every value that it receives. For example: a value can be set when no observers are active, so a new one will just replace it. Also, setting values from different threads could lead to race conditions that would only generate one call to the observers.

But the main problem with this approach is that it’s hard to understand and plain ugly. How do we make sure the value is reset after the navigation event has happened?

❌ Better: 2. Using LiveData for events, resetting event values in observer

With this approach you add a way to indicate from the View that you already handled the event and that it should be reset.

Usage

With a small change to our observers we might have a solution for this:

Adding the new method in the ViewModel as follows:

Issues

The problem with this approach is that there’s some boilerplate (one new method in the ViewModel per event) and it’s error prone; it’s easy to forget the call to the ViewModel from the observer.

✔️ OK: Use SingleLiveEvent

The SingleLiveEvent class was created for a sample as a solution that worked for that particular scenario. It is a LiveData that will only send an update once.

Usage

Issues

The problem with SingleLiveEvent is that it’s restricted to one observer. If you inadvertently add more than one, only one will be called and there’s no guarantee of which one.

✔️ Recommended: Use an Event wrapper

In this approach you manage explicitly whether the event has been handled or not, reducing mistakes.

Usage

The advantage of this approach is that the user needs to specify the intention by using getContentIfNotHandled() or peekContent() . This method models the events as part of the state: they’re now simply a message that has been consumed or not.

In summary: design events as part of your state. Use your own Event wrapper in LiveData observables and customize it to fit your needs.

Bonus! Use this EventObserver to remove some repetitive code if you end up having lots of events.

Источник

События на базе LiveData Android

LiveData – это отличный инструмент для связывания состояния ваших данных и объектов с жизненным циклом (LifecycleOwner, обычно это Fragment или Activity).

Обычно LiveData помещаются во ViewModel и используются для обновления состояния вашего UI. Часто ViewModel может пережить LifecycleOwner и сохранить состояние LiveData. Такой механизм подходит, когда вам нужно сохранить данные и восстановить их через некоторое время, например, после смены конфигурации.

Но что, если мы хотим использовать механизм событий, а не состояний? Причем обязательно в контексте жизненного цикла обозревателя (LifecycleOwner). Например, нам нужно вывести сообщение после асинхронной операции при условии, что LifecycleOwner еще жив, имеет активных обозревателей и готов обновить свой UI. Если мы будем использовать LiveData, то мы будем получать одно и то же сообщение после каждой смены конфигурации, или при каждом новом подписчике. Одно из решений, которое напрашивается, это после обработки данных в некотором обозревателе обнулить эти данные в LiveData.

Например, такой код:

Но такой подход имеет ряд недостатков и не отвечает всем необходимым требованиям.

Мне бы хотелось иметь механизм событий, который:

1. оповещает только активных подписчиков,
2. в момент подписки не оповещает о предыдущих данных,
3. имеет возможность выставить флаг handled в true, чтобы прервать дальнейшую обработку события.

Я реализовал класс MutableLiveEvent, который обладает всеми вышеперечисленными свойствами и который может работать, как обычный LiveData.

Весь код доступен на GitHub, а ниже я немного расскажу о реализации.

Идея заключается в том, чтобы внутри класса MutableLiveEvent, в методах observe и observeForever, оборачивать обозреватели в специальный внутренний класс PendingObserver, который вызывает реальный обозреватель только один раз и только если выставлен флаг pending в true, и событие еще не обработано.

В PendingObserver флаг pending выставлен в false по умолчанию. Это решает п.2 (не оповещать о старых данных) из нашего списка.

А код в MutableLiveEvent

Сначала выставляет pending в true и только потом обновляет данные внутри себя. Это обеспечивает выполнение п.1. (оповещение только активных подписчиков).

Последний момент, о котором я еще не рассказал, — это EventArgs. Это класс — обобщение, в котором есть флаг handled для прерывания дальнейшей обработки события (п.3.).

Источник

LiveData and single events

LiveData is great. You just set a value and the View will read that value whenever is needed. If the View is destroyed and then created again (e.g. when changing landscape portrait configurations) the last value will be read.

So that’s all, right? Every time we need to send something to the View we use a LiveData and we are done. Well, not exactly.

Since the latest value is read every time the View is created, what happens with things we want to send to the View exactly once? These could be messages shown in a toast, in a dialog, or navigation events. Using just LiveData for these cases would mean that the message/dialog/navigation will happen every time the View is recreated, which is not what we want.

The tricky part is that this might not be obvious because the message/dialog/navigation will work at first. But as soon as you rotate your device and see the message/dialog to re-appear, or you navigate to a screen, go back only to be navigated forward again, you will know that something goes wrong.

So how to pass to the View these single-only events?

Use a wrapper

Maybe the best approach is to wrap your actual data needed for the event (e.g. the String to show in the dialog) in a wrapper that will return the inner value only once. This is to ensure that the value is only consumed once, even if the view is recreated (e.g. on orientation change).

This approach is the official recommended one, but it’s quite verbose.

The wrapper class The ViewModel The view

Use SingleLiveEvent

Another approach is to use the SingleLiveEvent class. This is a class that was used in a Google example project and became a popular way to handle this issue, even though it was never truly recommended by Google.

The main reason is that if more than one observers are registered, only one will be called (without any way to know which one). If you can live with this, this an alternative, less verbose way, to send events from your ViewModel .

Note that you would need to copy-paste this class into your project. It’s not provided in any common library.

The ViewModel The view

Happy sending values from your ViewModel to your View! 🙂

Источник

SingleLiveEvent to help you work with LiveData and events

Have you had to deal with a Dialog or a SnackBar that after been triggered/shown or dismissed and followed by a device rotation is triggered/shown again? Probably this has to be related to the use of LiveData observables to communicate the ViewModel and the Activity/Fragment.
This is good, but the main woe here is that it will be observing continuously, however for this particular cases, need to be consumed only once.

The Anti-Pattern

Using LiveData objects for events can be taken as a bad design decision, even more when that event needs to be consumed just once. We can have a workaround using some boolean flags to help the view decide whether the Dialog/SnackBar must be triggered/shown or not. But this can lead to a solution difficult to read/maintain and ugly as well.

Using SingleLiveEvents as a solution

For his particular scenarios, SingleLiveEvent class was created to solve the problem. The updated value is sent only once, just as needed. And its use is rather easy, just like using a LiveData (in fact it’s an extension of MutableLiveData):

And that is all. Take a look of line 7 within the last snippet. auctionsViewModel.getUploadAuction().observe() will observe only once because getUploadAuction() returns only one value, then stops observing. And this solves the problem we were stating at the beginning.

For more details regarding patterns and anti-patterns while using ViewModels and LiveData as well as to have a deep explanation about SingleLiveEvent, you may want to take a look of this two resources from Android Developers:
1. ViewModels and LiveData: Patterns + AntiPatterns
2. LiveData with SnackBar, Navigation and other events (the SingleLiveEvent case)

Источник