Managing your views with commands vs. a mediated contextView
I think I've implemented a number of different solutions to this problem but I'd really like to hear how other people go about it.
Basically how do you manage the creation and adding of your views to the stage?
I think one solution is to have commands tied to states/actions. So, for instance, the LoginCommand might create and add the LoginView to stage. This makes me think about how controllers/views work in something like CodeIgniter for PHP. You hit a controller method and it decides which view to show. And perhaps your other view mediators listen for some kind of notification that says what state the app is in and they choose to hide/destroy their view if it doesn't belong in that state.
Another solution would be to mediate your contextView and have this mediator listen for state changes. When it hears a state change it can tell its view (ApplicationView, for instance) to run a method which creates a child. For instance:
(in the ApplicationMediator)
view.login();
(in the ApplicationView)
function login():void
{
var loginView:LoginView = new LoginView();
addChild(loginView);
}
Of course, the problem with this second solution is that you have a view which now knows about all of your other views, which might be ok if you consider the ApplicationView to be kinda special in a sense. One bonus is that instead of all the mediators handling their own view's removal from stage, the ApplicaitonView can choose how to remove its children (which is nice if you need to do an elaborate outro animation of some kind).
Anyway I would really love to hear how others deal with this problem.
Thanks!
- rob
Comments are currently closed for this discussion. You can start a new one.
2 Posted by Abel de Beer on 05 Feb, 2011 01:03 PM
I would always go for some form of the first option, because that way your application will be more flexible. It would be bothersome to have to update your ApplicationView and ApplicationMediator every time you add another view. The nice thing about Mediators is that they have the possibility to 'decide' themselves what to do in a certain situation. It also gives them a nice SRP (Single Responsibility Principle) approach. So the bottom line: try to avoid 'big' managers as much as possible. Delegate the event handling to the components in question.
3 Posted by rob on 05 Feb, 2011 03:31 PM
@Abel
I get what you're saying. I actually stumbled across a cool library last night while I was looking through GitHub: https://github.com/MrDodson/navigator-as3
Maybe some folks here use it?
However I'm still wondering how you would manage to sequence your outtro animations if each mediator was handling the process of removing its view from stage.
Support Staff 4 Posted by Stray on 19 Feb, 2011 11:03 PM
I tend to do what you were describing with the events. The app moves through various states (I have a separate module that is just a state machine really) and various view mediators are set up to listen for the relevant events to show / hide their view (using the view api).
If you need to vary the view-transition animations for different apps then I'd always suggest adding the transition animation by composition, then you can easily switch it in/out (also saves a lot of code duplication!)
Stray
5 Posted by rob on 20 Mar, 2011 02:48 AM
So if view A needs to transition out completely before view B starts to transition out, does view A trigger a command of some kind to tell view B to start animating out? Furthermore, does view B trigger a command to inform the state machine that the whole sequence is complete?
Support Staff 6 Posted by Stray on 24 Mar, 2011 12:13 PM
When you say "trigger a command" - I would say "dispatch an event".
But - generally I would say that both respond to an application event.
So - for example "AppStatusChangeEvent.OPEN_LIBRARY" causes my normal view to transition out, and my library view to transition in. If required, the library view can delay their response.
Stray closed this discussion on 02 May, 2011 03:23 PM.