In this chapter we will look at the C in SproutCore MVC or the Controller layer. As it turns out, the role of the Controller layer in SproutCore is as a proxy, and since SproutCore does so much of it automatically for us, we don't actually need a full chapter to discuss it. But just as we have discussed the Display layer alongside the View layer and the Data Interface layer alongside the Model layer, we will spend most of this chapter looking at the close companion to the Controller layer, the Application State layer.
Although the term Application State is something that I have coined for this book, it's not that the term is based on a new idea. In reality, the application state exists within all software applications, but is generally not identified as it is mixed within the other MVC or similarly themed layers. For example, in early SproutCore, developers put most of what we will discover as the Application State layer inside the Controller layer.
However, that is no longer the case and we will see how separating out the controller functions from the application state functions provides us with a powerful new approach to improving code structure, safety, and overall quality. As a part of this, we will introduce the concept of statecharts and learn how we can use SproutCore's statechart library to turn that theory into functioning code.
In this chapter we will cover the following:
- Understanding the Controller and Application State layers
- Working with SproutCore's controllers
- Designing with statecharts
- Avoiding pitfalls with statecharts
- Coding with statecharts
As I have mentioned in the opening paragraph, the Controller layer is actually a minor layer in SproutCore. This wasn't always the case; but with the addition of the statechart library to SproutCore, it became obvious that the best way to structure a SproutCore application, and likely any application, is by using statechart theory. Let me take a moment to make myself clear.
It's safe to say that every single application has (what we can call) a state. As soon as an application starts running, it will enter at least one state and likely enter and exit several other states before completion. This may include states of loading data, awaiting input, editing a record, saving to a database, being offline, or any other number of context specific states.
But while we, the developers, can easily recognize these states, this recognition doesn't always translate into the code. Unfortunately, very few frameworks provide tools to the code application states properly, and as it turns out, the inability to maintain state is the source of almost all programming problems. I'm sure this is a bold statement to make, but one that I believe plays itself out time and time again as other apps crash, freeze, or get exploited by hackers. For now, it's enough for us to agree that when an application is in a certain state, no matter how that state is defined, it should only be able to do certain actions and go to certain other states. This is like saying, when we are in an editing state, we should only be able to perform actions such as save changes and discard changes.
Of course, developers recognize this and do a number of things to try and maintain the overall application state. A common approach is to set flags such as isSaving or isReady that other pieces of code are expected to use in order to gate keep the appropriate code paths. Now I'm generally very open to alternative coding patterns, but I have seen flag setting fail so many times that I'm going to write emphatically, this does not work!
There are two huge problems with using flags to maintain application state. The first is that because the state is a combination of flags spread across the entire application, the actual real state is never very clear. But worse than this is that when flags change in multiple spots, we invariably introduce the most dreaded of all bugs, the race condition. These are the bugs that suddenly appear in production, but aren't reproducible in development or that affect one user and not the other, because they occur from seemingly negligible time differences to the order of when flags toggle that allows the application to enter invalid states that the developer had never considered.
But, enough about the wrong way to go about it; instead, we shall formalize the Application State layer separate from the other MVC layers. The Application State layer will be in charge of maintaining the real application state and will handle all of the actions and events that may alter the state of the application. Because this layer understands the overall application state, it can also coordinate and configure MVC layers as the state changes that gives us additional opportunities to fine-tune the performance of our application by doing things such as lazily adding bindings and observers or loading code through modules (more about this is in Chapter 6, Testing, Building, and Deploying).
Finally, with the state of the application no longer the responsibility of the controller layer, where does that leave the controller layer? It's simple; the Controller layer simply mediates between the View and Model layers. In the next section, we'll look at how this works.