Managing View States with StateMachine

[orensol]

Hi all,

I have just started out coding as3 using PureMVC, and it's brilliant!

I have a question regarding the StateMachine. I wanted to know what is the best practice of hiding view components which are not needed in a state. I thought about the following options:

1. Have each view component mediator interested in all specific-state-changed notifications, and by default (literally, in the "default" section of the switch in handleNotification) hide its component.

2. Have each view component mediator interested in the global StateMachine.CHANGED notification, and examine its value when received. It should then by default hide its view component, or show it if the state dictates showing it.

Both methods, however, seem cumbersome. I wanted to know if there's a recommended way to handle this.

Thanks,
Oren

[puremvc]

Just as Mediators 'translate' events into notifications and visaversa, they can also translate app-wide state to view component state.

You could make Mediators interested in the StateMachine.CHANGED note (or state-specific changed announcements) and translate those into appropriate view states for their view components.

If you're using Flex/AIR, this ties through nicely because you can just set the currentState property of the view component in reaction to a StateMachine state change.

Consider for instance, a GalleryViewMediator with a GalleryView that has three states: HIDDEN, BROWSING (full page) or MINIMIZED (an to an icon on the main app's toolbar area).

An app state of GALLERY might cause the GalleryMediator to set view component to the BROWSING state,
An app state of STORE_LOCATOR might cause the GalleryView Mediator to set its view component to the MINIMIZED state
An app state of CHECKOUT might cause he GalleryMediator to set its GalleryView view component to the HIDDEN state.

Let the view component implement Flex view states, and the component itself will take care of any hiding or showing of internal componentry and can even do visual transitions all on its own, like shrinking/growing from the toolbar area to the full screen, or fading / sliding out when going from any state to hidden and fading/sliding in when going from hidden to any other state.

So the mediator isn't responsible for reorganizing the details of what's visible or what size it is, only for translating app state to view state. It makes the component more portable and less reliant on the framework it's attached to.

If you're not using Flex/AIR and can't take advantage of built in view states, you can still make your view components encapsulate their own behavior based on the setting of a 'currentState' property.

-=Cliff>

[orensol]

Hi Cliff,

Thanks for the detailed response. I am actually using Flash so I can't take advantage of a built in view states mechanism.

So would you suggest the mediator be interested in the global state notification or the state-specific notifications (in the context of passing the state to the view component)? I can see pros and cons for both approaches...

Thanks,
Oren

[puremvc]

So would you suggest the mediator be interested in the global state notification or the state-specific notifications (in the context of passing the state to the view component)? I can see pros and cons for both approaches...

If you have a Mediator that needs to respond to a majority of the states in the system, then be interested in the global CHANGED note. Many birds, one stone.

But if your Mediator only needs to respond to a fraction of the states, then subscribe to the individual State-specific announcements so that the Mediator isn't being notified on every state change.

-=Cliff>