I don't agree with this solution at all. The real problem isn't LiveData but the inappropriate use of a data holder class (LiveData, kotlin StateFlow, rxjava BehaviorSubject though less so, etc) to hold critical events.

If you re-subscribe / re-observe the data holder you're going to see the previous values. That's by design and absolutely intentional.

This solution here is no different (as other commenters wrote), than SingleLiveEvent, and more verbose than the multitude of LiveEvent (https://github.com/hadilq/LiveEvent) type classes found everywhere.

Event type systems need a stream so they are observed once and handled once. Be it something from RxJava, a kotlin channel (or better yet the upcoming SharedFlow https://github.com/Kotlin/kotlinx.coroutines/issues/2034) or something else.

Furthermore, a stream is very much what you want! With some data holders (eg. LiveData or StateFlow) if you get a rapid set of events and there are no observers (say during a configuration change) it's very likely to miss events and only see the last one, since after all, the data holder can only hold one value. An observer starting to observe after a set of rapid events could very easily miss the intermediate events. That's very bad.

I would encourage anyone looking at implementing an event type system where the *observer* is responsible for checking if the event has already been processed or if the intermediate events are important (ie. missing an event is a bug) look towards better solutions than tacking a "has been handled" system on top of a data holder.

LiveData, even with this type of "has been handled" guards and checks simply won't help here.