Timers, Keyboard Events, and State Machines

Imagine a button in a program that you press repeatedly. Sometimes pressing it opens a menu, and at other times the same press closes it. Nothing about the press itself has changed. What has changed is the program's memory of what it is currently doing. Computer scientists have a name for anything that remembers a condition of its own and changes that condition when something happens to it: a state machine.

As you read the rest of this article, keep one question in mind. When an event arrives, what information must the program consult before it decides how to respond? The answer to that question is the central idea of this article, and it applies equally to a light switch, a game, a timer, or a graphical user interface.

Two parts of that definition matter most. The first is the state, which is the remembered condition of the thing. The second is the event, which is something that arrives from outside, such as a key press, a mouse action, or a timer firing. A state machine does not respond to an event in isolation. It responds to the event together with whatever state it is already in. The same event can therefore produce different results at different times, and the difference is entirely explained by the state.

To practice the idea outside the source's own examples, consider a simple wall light controlled by a single button. The light has two states, on and off, and it has one kind of event: a button press. The state can be stored in a boolean variable named lightIsOn. The response to a press depends on that variable. If the light is off, a press turns it on. If the light is on, a press turns it off. The button is identical in both cases. Only the stored state differs.

The diagram below shows the wall light as a state machine. Each box is a state, and each arrow is a response to an event. Both arrows carry the same label, which tells you that the event is identical in both cases. Only the starting state differs, and that difference alone determines where the light ends up.

Follow the trace step by step. Start with the light off, so lightIsOn holds false. A button press arrives. The machine checks the state, finds it off, and follows the arrow to the on state, so lightIsOn becomes true. Now take the same button press while the light is on. The event is identical, but the state is not. The machine follows the other arrow and turns the light off. Nothing in the button itself distinguishes the two cases. The state variable is what makes the difference.

In an object-oriented program, the information stored in an object's instance variables is called the state of that object. The state is the collection of values that describe the object at a given moment, and those values determine how the object looks or behaves.

Two consequences follow. First, when one of the object's methods is called, the action the object takes can depend on its state. The method can read the instance variables and decide what to do based on what it finds there. Second, the state can change. The method can assign new values to the instance variables, so the next call may behave differently from the last one. Reading and writing the same instance variables is how an object remembers across calls.

The state machine viewpoint is especially useful in event-oriented programming, the style required by graphical user interfaces. In such a program, nothing runs from top to bottom in one fixed sequence. Instead, the program waits for events, such as key presses or mouse actions, and each event triggers a handler that runs in response.

Because a handler runs at an arbitrary moment, the program must know its own condition whenever an event arrives. The diagram below shows the cycle that repeats for the life of the program. The program waits, an event arrives, a handler runs and updates the state variables, the display is repainted from that state, and then the program returns to waiting.

The source contrasts this approach with top-down, step-wise refinement, which it says does not apply to the overall design of an event-oriented program. Rather than planning one long sequence of steps, you plan a collection of states, the events that can occur, and the responses that depend on each combination. When building a GUI program, the source suggests asking several design questions: what information about state must be tracked, which events can change that state, how the response to a given event depends on the current state, whether the appearance of the interface should change to reflect a state change, and how the drawing code should take the state into account.

The comparison above shows the point of this whole article in one picture. The event column is identical in both groups. The outcome column differs. Tracing the machine means naming the starting state first, then following the transition that state allows for the event that arrived.