Sounds like you need to have a look at the StateMachine utility. StateMachine is specifically for keeping the state of your application and controlling the transitions between states. Although the view can be affected by the actions of the StateMachine, it is not just for controlling View states (use Flex for that).
Search and read in forums, and check out the 'Get your FSM on!' article in the news section. The utility is evolving, though with care not to break backward compatibility. Note that the existing demo (StopWatch) works but is not indicative of the appropriate usage yet.
A recent real-world app done using the latest version is
http://seaofarrows.com. Check out the implementation at
http://seaofarrows.com/srcview.
The Sea of Arrows Music Player illustrates the use of PureMVC MultiCore, Pipes and StateMachine.
In it, the Main App/Shell talks bidirectionally via Pipes to a PlaylistModule, which in turn talks bidirectionally to a VisualsModule.
For a demonstration of how the StateMachine can be used to control the states of your application, go check out the Shell Module. Start by looking in its controller package for the InjectFSMCommand. This file defines the Finite State Machine for the Shell. You can see that it defines several states and the valid transitions away from those states.
<fsm initial={ShellFacade.STARTING}>
<!-- STARTUP THE SHELL -->
<state name={ShellFacade.STARTING}>
<transition action={ShellFacade.STARTED}
target={ShellFacade.PLUMBING}/>
<transition action={ShellFacade.STARTUP_FAILED}
target={ShellFacade.FAILING}/>
</state>
<!-- PLUMB THE CORES -->
<state name={ShellFacade.PLUMBING} changed={ShellFacade.PLUMB}>
<transition action={ShellFacade.PLUMBED}
target={ShellFacade.CONFIGURING}/>
<transition action={ShellFacade.PLUMB_FAILED}
target={ShellFacade.FAILING}/>
</state>
<!-- RETRIEVE, DISTRIBUTE and PARSE CONFIGURATION -->
<state name={ShellFacade.CONFIGURING} changed={ShellFacade.CONFIGURE}>
<transition action={ShellFacade.CONFIGURED}
target={ShellFacade.ASSEMBLING}/>
<transition action={ShellFacade.CONFIG_FAILED}
target={ShellFacade.FAILING}/>
</state>
<!-- ASSEMBLE THE VIEW -->
<state name={ShellFacade.ASSEMBLING} changed={ShellFacade.ASSEMBLE}>
<transition action={ShellFacade.ASSEMBLED}
target={ShellFacade.NAVIGATING}/>
<transition action={ShellFacade.ASSEMBLY_FAILED}
target={ShellFacade.FAILING}/>
</state>
<!-- READY TO ACCEPT BROWSER OR USER NAVIGATION -->
<state name={ShellFacade.NAVIGATING} changed={ShellFacade.NAVIGATE}/>
<!-- REPORT FAILURE FROM ANY STATE -->
<state name={ShellFacade.FAILING} changed={ShellFacade.FAIL}/>
</fsm>;
A really nice thing about a StateMachine definition like the one above is that you can immediately get an understanding of the application that you couldn't get without it.
It similar to our life in the plane of the galaxy; our perspective lends the idea that the universe around us is this incredible, uniformly random cloud of stars. But if we could fly up out of the plane of the ecliptic, tangential to it and far away from the galaxy, then we'd see an order. We'd see the arms of the galaxy, the hub, the thin parts, etc.
Within a normal PureMVC app, you see the notifications that are mapped to various commands and mediators are interested in some and you can see that you kick off some domino effect at the view, and an event will trigger a mediator to send a note that a command will pick up and talk to a Proxy, etc. And there are many of these paths all interwoven in an app. You just have to pick a thread and start following it to see what calls what and what happens then.
But with a quick read of the FSM above, you now have a high-level understanding of the life-cycle of this module. Now, within any given state, you may find that all sorts of activity has to happen, including async calls to remote services, etc. But rest assured, the StateMachine will not budge. Until it hears one of the valid actions that trigger transitions to other valid states, the current state will be held.
Note that the other modules could have their own StateMachines giving us the ability to have sub-states, although this app doesn't - yet. I'm considering making another module called Sequencer and refactoring the playback functionality into it, and it would likely have a StateMachine to keep track of ready, playing, paused states and how to respond to them when new tracks are selected or previous/next is requested, etc.
-=Cliff>
