Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Multiple StateMachine instances  (Read 7619 times)
shanestevens
Jr. Member
**
Posts: 17


View Profile Email
« on: September 26, 2011, 11:51:24 »

Hi Cliff,

I've modified my local version of the StateMachine utility to support multiple instances:

1. StateMachine constructor takes a name, with a null default.  The default lets it act as it does now.
2. Changed FSMInjector to support a name in the XML definition, which is passed to the StateMachine constructor.

e.g.
:
<fsm name="GameFSM" initial={AppFacade.STATE_BOOT}>
Works well.  The only gotcha is that the user has to be careful to keep the actions/states exclusive to each FSM.  If they do, then each FSM will ignore the states and actions of other FSMs.  I haven't found this an issue, but just thought I'd throw it out there.  One way around this could be to mangle a namespace into each set of actions/states.

What do you think?  Sound ok?

Cheers,
Shane



Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: September 27, 2011, 09:22:24 »

The StateMachine is intended to manage application state across the whole core. You can run one inside each core of a MultiCore app. I'm curious how you're using the multiple instances in the same core.

-=Cliff>
Logged
shanestevens
Jr. Member
**
Posts: 17


View Profile Email
« Reply #2 on: September 28, 2011, 04:29:34 »

Sure, it's great at application state, however there is nothing fundamentally wrong with it being used for any state related activities.  For instance, at a macro level, managing Core state and application flow, but at a finer grained level, it can be used for UI/Dialog state mediation.

In other words, it's possible to have a set of states and their associated actions for the application as a whole, with another FSM managing a subset of a particular state.  Not exactly a HSM, but a simple hybrid.

- Shane
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: September 28, 2011, 07:30:10 »

The current arrangement of the UI on the screen might be an extension of the current application state, but view state is different. It is possible, but not advisable to do view state management with the StateMachine. Dialogs and other view components should really maintain their own state internally without requiring aid from the framework. Without an example to look at its difficult to tell exactly how much responsibility is being offloaded to the framework, though. Can you show us a simple example?

-=Cliff>
Logged
Pages: [1]
Print