Java enum-based state machine (FSM): Passing in events

Question

I'm using several enum-based state machines in my Android application. While these work very well, what I am looking for is a suggestion for how to elegantly receive events, typically from registered callbacks or from eventbus messages, into the currently active state. Of the many blogs and tutorials concerning enum-based FSMs, most of them give examples of state machines that consume data (e.g. parsers) rather than show how these FSMs may be driven from events.

A typical state machine I'm using has this form:

private State mState;

public enum State {

    SOME_STATE {


        init() {
         ... 
        }


        process() {
         ... 
        }


    },


    ANOTHER_STATE {

        init() {
         ... 
        }

        process() {
         ... 
        }

    }

}

...

In my situation, some of the states trigger a piece of work to be done on a particular object, registering a listener. That object asynchronously calls back when the work is done. In other words, just a simple callback interface.

Similarly, I have an EventBus. Classes wanting to be notified of events again implement a callback interface and listen() for those event types on the EventBus.

The basic problem therefore is that the state machine, or its individual states, or the class containing the enum FSM, or something has to implement those callback interfaces, so that they can represent events on the current state.

One approach I have used is for the entire enum to implement the callback interface(s). The enum itself has default implementations of the callback methods at the bottom, and the individual states can then override those callback methods for events they're interested in. For this to work, each state must register and unregister as it enters and exits, otherwise there is risk of the callback happening on a state that isn't the current state. I will probably stick with this if I find nothing better.

Another way is for the containing class to implement the callbacks. It then has to delegate those events on to the state machine, by calling mState.process( event ). That means I'd need to enumerate event types. For example:

enum Events {
    SOMETHING_HAPPENED,
    ...
}

...

onSometingHappened() {

    mState.process( SOMETHING_HAPPENED );
}

I don't like this however because (a) I'd have the uglyness of needing to switch on the event types within the process(event) of each state, and (b) passing through additional parameters looks awkward.

I would like a suggestion for an elegant solution for this without resorting to using a library.

Answer 1

Why not have events call the right callback on state directly?

public enum State {
   abstract State processFoo();
   abstract State processBar();
   State processBat() { return this; } // A default implementation, so that states that do not use this event do not have to implement it anyway.
   ...
   State1 {
     State processFoo() { return State2; }
     ...
   },
   State2 {
      State processFoo() { return State1; }
      ...
   } 
}

public enum  Event {
   abstract State dispatch(State state);
   Foo {
      State dispatch(State s) { return s.processFoo(); }
   },
   Bar {
      State dispatch(State s) { return s.processBar(); }
   }
   ...
}

This addresses both of your reservations with the original approach: no "ugly" switch, and no "awkward" additional parameters.