In their most simple form, statecharts are a way to structure your application into logical states. A statechart does not need to be implemented in your application’s code; but it is easier to adhere to the statechart you lay out if you are able to create or use a framework that defines:
- what is possible to do within a state
- how the application can transition from one state to another
- and finally what needs to be set up and torn down upon state entry and state exit.
From SproutCore Version 1.5 and onwards, there is a fantastic Statechart framework built right into the library itself– conveniently called SC.Statechart.
To Statechart or Not to Statechart?
For me, there are a couple of main reasons to use statecharts. First, having to sit down and think about your application’s possible states makes you think long and hard about the actual design of your application. Second, splitting a large application into logical (and smaller) states makes it easier to break functional requirements down into manageable parts when it is time to plan and develop the application.
As a final bonus, you end up with a finished application that has one killer feature: separation of concerns between application domains. That last part alone should make you want to invest in using statecharts for your application: cleaner code and less spaghetti.
The State of the Game
There are many ways to structure a statechart application. The statechart needs to have one and only one root state, which you can think of as the initial state of your application.
There are a number of key factors that needs to be included in each state, so that the states can be combined into a statechart.
- Each state needs to have exactly one clearly defined entry point
- Each state needs to have at least one clearly defined exit point (the possible transitions available)
- Each state needs to be able to set up everything required within that state upon state entry
- Each state needs to be able to tear down anything that is state-specific upon state exit
Note that the above can be considered my guidelines. It’s most certainly possible to break any of the above requirements inside your statechart implementation– however, be prepared that the end result might be messy/spaghetti code, no clear separation of concerns, or worse, both.
An added bonus of using SC.statechart is that you will also be able to build an application where the routes that the user can travel through your application is made explicit in both design and code.
Statecharts and the MVC Model
Since Statecharts will make up a large portion of your application’s architecture, where does it fit into the SproutCore MVC model? Will a Statechart-built application really be something like an MVCS (Model-View-Controller-Statechart) model?
The answer to the first question is that Statecharts fits in beautifully with the SC MVC model. The answer to the MVCS question is: it depends on your viewpoint.
Without statecharts, the SproutCore MVC model looks like the diagram below.Tweet