I’m in the same situation as you with respect to your ActionState. It’s highly desirable for an action to be emitted only once when the observer is in the correct lifecycle state. Say to send a broadcast, perform an action that will finish an activity.

I initially implemented my version of “ActionState” with https://github.com/hadilq/LiveEvent which itself was an attempt to improve upon SingleLiveEvent.

SingleLiveEvent requires the observers to be aware of whether or not the previous event/action has been handled. That’s not terrible but it adds a lot of boilerplate to each observer.

LiveEvent also suffers from a few implementation issues. Most notably that emissions that occur prior to observers starting to observe are dropped. This can happen if events are emitted, say during initialization, prior to a view starting to observe. (Rare, but possible.) Also, since it’s backed by LiveData back to back actions step on top of each other if there are no active observers.

LiveEvent is not a bad solution but it does create yet another type of lifecycle you have to remember to deal with which is what we are trying to avoid.

I build upon the ideas of LiveEvent and made https://github.com/fergusonm/SingleLiveEventStream mostly as an experiment to see if I could remove the issues with requiring the observer to know if the event/action has been handled like SingleLiveEvent does, and also to remove the implementation issues that LiveEvent has.

My experiment is based on rxjava to provide a stream of events that only emit when all observers are in a “good” lifecycle state. And since it’s a true steam back to back emissions can’t step on each other. It’s purely an experiment so just some food for thought.