Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
An event wrapper for data that is exposed via a LiveData that represents an event.
/**
* Used as a wrapper for data that is exposed via a LiveData that represents an event.
*/
open class Event<out T>(private val content: T) {
var hasBeenHandled = false
private set // Allow external read but not write
/**
* Returns the content and prevents its use again.
*/
fun getContentIfNotHandled(): T? {
return if (hasBeenHandled) {
null
} else {
hasBeenHandled = true
content
}
}
/**
* Returns the content, even if it's already been handled.
*/
fun peekContent(): T = content
}
@feinstein

This comment has been minimized.

Copy link

commented Sep 3, 2018

I read your article here, but I don't think this code can provide some of the benefits you talk about, please correct me if I am wrong.

1 - You say that SingleLiveEvent isn't a perfect solution because:

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.

But I can't see how this Event class is going to be much different than that. It will indeed be sent to all the Observers that register to observe this Event, but as soon as the first Observer calls getContentIfNotHandled(), all others will lose track if they have received this Event before, or not.

If the Observer choose to use peekContent() instead, it can retreive the Event value, but still it has no clue if it did catch this Event in the past, or didn't.

So how's this the recommended solution for multiple Observers?

I think a better suited option would be to have a Map holding a boolean for each key, whereas the key can be a String or the Class of the Observer (I think that using the Observer himself could lead to memory leaks maybe? I am not sure), and the boolean just informs if this Observer has got the content or not. This way, the Observer will have to pass it's key to get the content.

2 - Shouldn’t hasBeenHandled be atomic for thread safety?

@nicol-ograve

This comment has been minimized.

Copy link

commented Sep 13, 2018

This approach avoid cases in which multiple observers exists but only one is the effective consumer. With SingleLiveEvent other observers like a Logger, could prevent the main consumer to access the event. In this way there is a separation between consuming observers (that in the majority of cases will be just one) and non-consuming ones

@feinstein

This comment has been minimized.

Copy link

commented Sep 18, 2018

Yes, but this separation was never the point of this class, at least not according to his article.

@ghost

This comment has been minimized.

Copy link

commented Sep 24, 2018

Same question as @feinstein

@rvdsoft

This comment has been minimized.

Copy link

commented Oct 10, 2018

@feinstein @raiytu4
I have created an improved version of @JoseAlcerreca's SingleLiveEvent that supports multiple observers. No need for a custom observer class or value wrapper.

public class SingleLiveEvent<T> extends MutableLiveData<T> {

    private LiveData<T> liveDataToObserve;
    private final AtomicBoolean mPending = new AtomicBoolean(false);

    public SingleLiveEvent() {
        final MediatorLiveData<T> outputLiveData = new MediatorLiveData<>();
        outputLiveData.addSource(this, currentValue -> {
            outputLiveData.setValue(currentValue);
            mPending.set(false);
        });
        liveDataToObserve = outputLiveData;
    }

    @MainThread
    public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<T> observer) {
        liveDataToObserve.observe(owner, t -> {
            if(mPending.get()) {
                observer.onChanged(t);
            }
        });
    }

    @MainThread
    public void setValue(T value) {
        mPending.set(true);
        super.setValue(value);
    }
}
@ipcjs

This comment has been minimized.

Copy link

commented Oct 19, 2018

@rvdsoft you code have a bug.
if i observe the singleLiveEvent after send event. i can't receive the event.

@RajaParikshit

This comment has been minimized.

Copy link

commented Oct 24, 2018

This SingleLiveEvent class gives error for androidx

'observe(LifecycleOwner, Observer)' in 'com.busisoft.ezeeoffice.helpers.SingleLiveEvent' clashes with 'observe(LifecycleOwner, Observer<? super T>)' in 'androidx.lifecycle.LiveData'; both methods have same erasure, yet neither overrides the other

@hvsimon

This comment has been minimized.

Copy link

commented Nov 21, 2018

@rvdsoft you code have a bug.
if i observe the singleLiveEvent after send event. i can't receive the event.

This is intended behavior. It is base on Google's android-architecture sample.

A lifecycle-aware observable that sends only new updates after subscription, used for events like navigation and Snackbar messages.

https://github.com/googlesamples/android-architecture/blob/todo-mvvm-live/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/SingleLiveEvent.java

@schildbach

This comment has been minimized.

Copy link

commented Nov 21, 2018

This SingleLiveEvent class gives error for androidx

'observe(LifecycleOwner, Observer)' in 'com.busisoft.ezeeoffice.helpers.SingleLiveEvent' clashes with 'observe(LifecycleOwner, Observer<? super T>)' in 'androidx.lifecycle.LiveData'; both methods have same erasure, yet neither overrides the other

@RajaParikshit Simply adapt to the new signature by adding the ? super.

@ArthurCideron

This comment has been minimized.

Copy link

commented Dec 12, 2018

@rvdsoft but in your implementation, the event will be consumed just once, by the first observer that gots hold of it.
I believed that what @feinstein wanted was to be abled to have multiple observers, that each consume the Event once ?

I made up (quickly) something like that below, based on your code and @feinstein suggestion. It seems to work fine but I have to say, it does feel a bit like a hack...

class SingleLiveEvent<T> : MutableLiveData<T>() {

    private val liveDataToObserve: LiveData<T>
    private val pendingMap: MutableMap<Int, Boolean>

    init {
        val outputLiveData = MediatorLiveData<T>()
        outputLiveData.addSource(this) { currentValue ->
            outputLiveData.value = currentValue
        }
        liveDataToObserve = outputLiveData
        pendingMap = HashMap()
    }

    override fun observe(owner: LifecycleOwner, observer: Observer<T>) {

        pendingMap[observer.hashCode()] = false

        // Observe the internal MutableLiveData
        liveDataToObserve.observe(owner, Observer { t ->
            if (pendingMap[observer.hashCode()] == true) { // don't trigger if the observer wasn't registered
                observer.onChanged(t)
                pendingMap[observer.hashCode()] = false
            }
        })
    }

    override fun setValue(t: T?) {
        pendingMap.forEach { pendingMap[it.key] = true }
        super.setValue(t)
    }
}
@OssamaDroid

This comment has been minimized.

Copy link

commented May 3, 2019

@feinstein By using this event wrapper for data, it's possible for multiple observers to observe the live data and they will all get notified with any live data change. What you only have to make sure is creating a new Event object for each Live data's value.

If we consider the example being given in the article, it would be something like:

private val _navigateToDetails = MutableLiveData<Event<String>>()

val navigateToDetails : LiveData<Event<String>>
    get() = _navigateToDetails

private val _navigateToHome = MutableLiveData<Event<String>>()

val navigateToHome : LiveData<Event<String>>
    get() = _navigateToHome

fun userClicksOnItem(itemId: String) {
    _navigateToDetails.value = Event(itemId)
}

fun userClicksOnHomeButton(itemId: String) {
    _navigateToHome.value = Event(itemId)
}
@MrTheGood

This comment has been minimized.

Copy link

commented May 10, 2019

If you want to use nullable content:

open class Event<out T>(
    private val content: T
) {
    val hasBeenHandled = AtomicBoolean(false)

    fun getContentIfNotHandled(handleContent: (T) -> Unit) {
        if (!hasBeenHandled.get()) {
            hasBeenHandled.set(true)
            handleContent(content)
        }
    }

    fun peekContent() = content
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.