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

Show Posts

* | |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / General Discussion / Re: FSM Uses & Limitations / Async transitions on: April 01, 2009, 09:57:00
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?
2  Announcements and General Discussion / General Discussion / Re: FSM Uses & Limitations / Async transitions on: March 31, 2009, 09:22:34
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..
3  Announcements and General Discussion / General Discussion / FSM Uses & Limitations / Async transitions on: March 31, 2009, 05:16:34
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.
4  Announcements and General Discussion / General Discussion / Re: StateMachine - crossing many states on: March 09, 2009, 10:03:45
Thanks for your detailed reply, Cliff.  I will try to implement your suggestion.
5  Announcements and General Discussion / General Discussion / StateMachine - crossing many states on: March 06, 2009, 02:43:55
Hi,

I'm attempting to use StateMachine for the first time and have a question about states and transitions.  In the open/close/lock door example I see how it's possible to limit which states are available from the current state.  However, in my app, using SWFAddress a user could conceivably go TO any state FROM any state by typing in a direct URL, BUT, it might be necessary to travel through multiple states to get there.

For simplicity sake, lets use an example of an app that moves a box to the 4 corners of your screen, each corner represented by a state.  Changing state tweens the box to the correct position, but it only moves horizontally and vertically, in a clockwise fashion.  States:

:
<fsm initial="TOP_LEFT">

<state name="TOP_LEFT">
<transition action="TO_TOP_RIGHT" target="TOP_RIGHT" />
</state>

<state name="TOP_RIGHT">
<transition action="TO_BOTTOM_RIGHT" target="BOTTOM_RIGHT" >
</state>

<state name="BOTTOM_RIGHT">
<transition action="TO_BOTTOM_LEFT" target="BOTTOM_LEFT" >
</state>

<state name="BOTTOM_LEFT">
<transition action="TO_TOP_LEFT" target="TOP_LEFT" />
</state>

</fsm>



So the site inits the box at TOP_LEFT and the user types in http://sweetboxapp.com/#/bottomright.  The box needs to move from TOP_LEFT to TOP_RIGHT, then from TOP_RIGHT to BOTTOM_RIGHT, essentially moving through states.  While this example is simple, in the app I'm developing a user could move through a maximum of 6 states.  It's important (or at least I think it is) to maintain the idea of moving through states because of the transitions that are required.  ie. TOP_LEFT can't go to BOTTOM_RIGHT directly, it must move through TOP_RIGHT.

Am I thinking about this correctly?

thanks,
Trevor

Pages: [1]