Manage the Lifetime of GUI States

Question

I am designing a program responsible for a GUI (with the graphics and user input being managed within a typical update loop) which has several states:

• The default state is an animation which continuously runs despite any user input.

• A notification state can be invoked which displays a notification instead of the animation. Notifications have a timeout which should-self close after that time and return to the default animation, it could also be closed prematurely by user input or by another notification of greater priority.

• There is also a presentation mode which plays a video clip and should self-close and return to the default state after it ends. However, an important notification can also pause the video and be displayed, after which the video should resume, and return to the default animation once it ends.

More states are envisioned in the future although their requirements have not yet been defined. But as you can see, the architecture should be extensible with the ability for more states being added in. Therefore, each state should be able to control it's own lifecycle and invoked state changes for the GUI. For each state transition the screen should also fade out the current state and face in the next one.

My question is what kind of OOP architecture can be used to achieve this (as opposed to if/then statements in the update loop)? Are there any design patterns (perhaps state pattern) that can achieve this?

Note: It is being developed with SFML and c++.

Answer 1

You could use the state pattern but as it is now this looks like a simple app with a couple of views - im not sure implemening an explicit state machine is worth it but this is depending on the capabilities of your GUI framework.

If it really is bare-bones and you have a render loop for drawing etc then yes it might be worth it but if the framework is higher level and facilitates swapping views etc I wouldn't bother.

Answer 2

State pattern certainly looks like a candidate for the different "screens" and their transitions. As you need to cross-fade, you'd have to vary it slightly, having an "active" state and an "obsolete" (or previous) state during the fade-out (both would animate, but only the active would have a behaviour or reaction to the UI events).

I'd seriously reconsider having a loop running continuously. That will probably put the CPU use to a 100%. Even with a loop, the best option seems to "sleep" the process some milliseconds and issue updates at regular intervals (you'd still get nice and smooth animations, but reducing the CPU usage greatly). Then, for both the "animation tick" and other UI events, the Observer pattern will help. One of the advantages you'd get is that you can even decide to animate or not to animate certain elements dynamically by just subscribing or unsubscribing them to the "animation tick" events. You can ignore the animation of a hidden widget in its redraw function, but there's no need to even call that function in the first place! ;)