FSM Uses & Limitations / Async transitions

[trevorhartman]

I've been reading a few discussions on the forums regarding the state machine utility, and have left possibly more confused than when I started:


I see how FSM provides nice exiting/entering/changed notifications, but it looks like they're synchronous - in real life that sequence would happen nearly instantaneously, correct?  From StateMachine.as -> transitionTo:

:

// Exit the current State
if ( currentState && currentState.exiting ) sendNotification( currentState.exiting, data, nextState.name );

// Check to see whether the transition has been canceled
if ( canceled ) {
canceled = false;
return;
}

// Enter the next State
if ( nextState.entering ) sendNotification( nextState.entering, data );
currentState = nextState;

// Send the notification configured to be sent when this specific state becomes current
if ( nextState.changed ) sendNotification( currentState.changed, data );

// Notify the app generally that the state changed and what the new state is
sendNotification( CHANGED, currentState, currentState.name );


In my app, I need to handle transitions visually by tweening properties over time.  This means exiting the current state could take 1.2 seconds, entering the next state takes 1.5 seconds, and maybe I want them to overlap by 0.4 seconds.  And maybe I want "changed" to fire .2 seconds before the entering transition is done. Possible with FSM or not?

thanks.

[Jason MacDonald]

I think the point of confusion for you is that you are equating "Visual" states with "Application" states. They are quite different. A visual state is where you are in one screen and move to another (usually with transitions - think Flex States). An application state is more things like "saved" or "editing", as an example. Now that's not to say that application states don't have visual representations, its just not what FSM is trying to handle.

You need to use visual states in conjunction with application states.

[trevorhartman]

That makes sense.  But it still stands that my app has a visual state, and requires time to move from one state to another.  Does FSM have a role at all in this case?  Or would it make sense to use my own notification system on top of FSM?  I need some kind of state management either way..

[willw]

(I do think Jason's comment is to the point. This is a confusing area. To minimise confusion, I will refer to app-states and vis-states to distinguish the two kinds.)

You can map FSM app-states to visual change vis-states.

For example, you could treat your periods of tweening as app-states in themselves, and give them names like 'XXXChanging'. You enter XXXChanging when you start the tweening effect, and exit it when it finishes. You end up with three app-states (XXXBefore, XXXChanging and XXXAfter) mapping to two vis-states (XXXBefore and XXXAfter).

Or you could decide that mapping these transitional periods to FSM app-states serves no particular purpose, and consider the transitional tweening period to be part of either the starting or, more likely, finishing app-state.

Which technique you use depends on how you intend to use you FSM. The point of the FSM is to orchestrate different parts of you application. If you need to do extra things on both starting and finishing a vis-transition, then you need to consider the more fine-grained approach. If (say) nothing else needs to know when the tweening finishes, it would not be worth modelling... and indeed provides a useful simplification to your FSM model. (In my experience FSMs rapidly get too large and complex.)

Also, if you take the fine-grained approach, essentially you are writing code and doing work to synchronise two bits of application state. To me this has what the refactoring people call 'a smell'.

If you build your intended FSM model first, you may find this clarifies your view of this sort of detail. I think the State Machine Compiler site http://smc.sourceforge.net/ has lots of good material on the general application of state machines.

Will

[puremvc]

Jason's advice about conceptually seperating visual and application states is the key.

When defining  application states you'll almost always name them with a gerund such as VIEWING, ENTERING or SAVING, because the app can always be considered to be DOING something. You are not concerned with visual transitions while laying out your FSM, only the discrete functional States your app can be in, which States it is possible to transition to from each one, and what actions can trigger thransitions to those states.

So, let us assume your app is in the ENTERING_PRODUCT_INFO State and you click a submit button. You want the app to send the data to the server to be saved, and the data entry screen to be whisked away and and replaced by a progress bar as you app twiddles its thumbs in the SAVING_PRODUCT_INFO State ntil you get a result, after which the progress bar fades out and is replaced by a datagrrid of products when the app moves into LISTING_PRODUCTS State.

Here's the trick: don't try to make the visual transitions start and end *while* the corresponding StateMachine transitions are happening. As you said the visuals take time, and the StateMachine transitions happen right away.

Instead kick off those visuals once the StateMachine has reached its new basin of stability. There are two ways to do this:

1) Make your mediators that need to tell their view components to start tweening interested in the state-specific 'changed' note. (Not the entering or exiting notes). This is the notification name you define this in your FSM XML description as the 'changed' attribute for a given State tag, and can be different for every State. This notification will carry the optional data you may have included in the body of the StateMachine.ACTION notification that you send to trigger a transition to this State.

2) Make your mediators that need to tell their view components to start tweening interested in the StateMachine.CHANGED note. This notification is sent out after every successful State transition is completed and carries the current State object in the body, in case you just want your mediator to subscrib to one note and look at the State object to determine what to do.

Both approaches can be used in the same app. For instance a mediator that simply swaps out a header graphic for each state might use the latter approach, making maintenance of its listNotificationInterests and handleNotification methods much easier and making for shorter observer lists (and therefore more performant code).

Some mediators would be more suited to the first approach if they are only interested in certain States and should never be notified about others. For instance the mediator for the login screen would likely never be interested when the app has changed to the manage subscriptions screen and should of course not be notified. It would instead be interested in the note name you defined in the 'changed' attribute of the ENTERING_CREDENTIALS or LOGGING_IN States.

Hope this helps to clear the fog.

-=Cliff> 

[trevorhartman]

Thanks all. That helps clarify a bit.  What I'm trying to do is develop Cliff's suggestion from my other post, regarding moving through states to reach a destination. (reference: http://forums.puremvc.org/index.php?topic=1074.msg4916#msg4916 ).

Here is a simple diagram of my app states and the valid transitions:



(link) http://dl.getdropbox.com/u/113427/Application-States.png


It starts on "loading", then lands on "positive".  User can move linearly through the states, indicated by the bi-directional arrows.  You'll notice the identical states on either side - these are separate instances (I guess I should have indicated "+list" and "-list", "+content" and "-content").


So here's my plan:

1. Everything is driven by SWFAddress:
The url maps to an FSM action. When the url is changed (via an AddressChangeCommand that updates a SWFAddressProxy), the command parses out the action and desired state then sends an ACTION_REQUEST notification with desiredState in the body.

2. A DestinationStateMediator listens for ACTION_REQUEST notifications.  Let's say the user is in +content and the URL is requesting -list, so the DestinationStateMediator needs to determine a valid path to get there, then send out the StateMachine.ACTION notification to move it a step in the right direction.  I think DSM would also set a flag inTransition=true or something, and save a local requestedState var.

3. After StateMachine does its work and sends out the StateMachine.CHANGED, various mediators will respond depending on the current state to visually tween the app to reflect the current FSM state.  When the tweens are done, the same mediator would send a VISUAL_STATE_CHANGED notification which the DSM would handle by checking the current FSM state against desiredState, then moving another step in the right direction toward requestedState and so on until it arrives.

I have various bits of this coded out but I'm not there yet. Any thoughts on this plan?

[puremvc]

I think this sounds workable. I don't think you need to store a in(ransition flag or the requested state though. The DSM can be buddies with the SWFAddressProxy, keeping a local reference. That proxy knows the destination state and can expose it as a property rather than parsing, sending and forgetting. Its data property would be the destination state parsed from the url.

The DSM , responding to StateMachine.CHANGED can easily compare the two states and determin if you're there yet.

Otherwise, sounds like you're on track. Let us know how it goes.

-=Cliff>