Home → Problems →

Mediator onRegister happening after STARTUP_COMPLETE

• Edit

Joe

06 Jan, 2010 01:29 PM

Hi all,

I'm currently trying to convert a project (showreel app) from PureMVC to RobotLegs, as a way of teaching myself RobotLegs. I'm having a little difficulty in working out how to deal with Mediators...

In my original application, I registered all Proxies and Mediators, then ran a Command which started the thing running. In this Command it sets the ShowreelProxy to the first item and then tells the SlidesMediator to start playing.

In PureMVC, this worked because the Mediator had registered and I could retrieve it in the Command and call a method on it. However, in RobotLegs it appears that the Mediator has not yet been registered. Even though I am running this Command after receiving a STARTUP_COMPLETE ContextEvent, the Mediator's onRegister has not yet been called.

Do I need to try and work it some other way? I want to be able to have access to all my model and view items at some point, but it seems at the moment that unless I listen to every Mediator to see if each one has been registered, there's no way of knowing...

Any ideas?

Thanks!

:-Joe

1. Support Staff 1 Posted by Shaun Smith on 06 Jan, 2010 04:05 PM

   

   Hi Joe,

   Mediators work a little differently in Robotlegs - when we write this:

   mediatorMap.mapView( ViewClass, MediatorClass )
   

   we are instructing Robotlegs to automatically create and register mediators when instances of ViewClass land on the stage. This means that a mediator won't exist until its corresponding view component has been added to the display list.

   You are experiencing difficulty because you are trying to access a mediator directly from a command, which is not good practice - your application should be "unaware" of its view tier. When you directly manipulate mediators from commands/models/proxies etc, you couple your application to its view tier - which is exactly what MVC is designed to avoid.

   Rather than talking directly to a mediator from your command you should dispatch an event - one that the mediator itself will respond to. Before you dispatch the event make sure that you have added the necessary view component to the display list (so that its mediator will be created, registered and ready to respond to the event).

   • Edit

2. 2 Posted by Joe on 06 Jan, 2010 04:24 PM

   

   Thanks - the problem I have is not knowing when the view is completely ready so I may access it. I think I'll probably need to create some kind of ApplicationStateModel to keep tabs on what's been set up, and also to dispatch events when things have been set up.

   One point I'm not too clear on though... You say that accessing a mediator directly from a command isn't good practice... But how about accessing the model from the command? Doesn't that make the layers just as coupled?

   • Edit

3. 3 Posted by Joe on 06 Jan, 2010 04:37 PM

   

   One other thing (sorry) :)

   I guess I've been calling the view layer directly from the command layer because I think of Events as "I've done something" information, rather than "Do this" information, if that makes sense... So I guess I need to get used to Events telling mediators to do stuff...?

   • Edit

4. Support Staff 4 Posted by Shaun Smith on 06 Jan, 2010 11:10 PM

   

   "I've done something" is actually the better way to think of events; I'm not suggesting that you create events that "tell" mediators to do things, I'm suggesting that mediators should act in response to events - the difference is pretty subtle I know.

   If you map a mediator to a view class, and then add an instance of that class to the display list, you can assume that a mediator will be constructed and ready for action immediately.

   Getting back to your original problem, I wouldn't try to access the mediator from the command directly, instead I would dispatch an event at the end of the command that the mediator would respond to. The event would describe what happened in that command, rather than a call-to-action event designed specifically for the mediator.

   Perhaps a way to think about it is:

   A view is just that - a view. One single view onto a part your application. You should be able to add another view (or even another instance of that same view) and your application should still work. Like changing the camera in a first-person shooter, or that little rear-view mirror in a racing game; just different views of the same application.

   Does that help?

   • Edit

5. 5 Posted by Joe on 08 Jan, 2010 02:04 PM

   

   Yes I think so, thanks! I guess I'd become quite lazy in my PureMVC programming ways, and so it's good to get a bit of a refresher on how to separate things properly in an MVC framework.

   One thing I am struggling with, however, is finding a point at which my view is completely set up and ready to go. I have only one Application View, and that has four custom view components in it, each with an associated mediator. However I am finding that even if I try to access the mediators from a "contentCreationComplete" action, they are not yet registered.

   But then I think again about what you said regarding the decoupling of the view... I guess what I really need to do is have the Mediators request information when they know they have been registered... Sorry I'm thinking this through as I discuss it here :-) I will go back through my set-up and see how I can alter things accordingly.

   Cheers,

   :-Joe

   • Edit

6. Support Staff 6 Posted by Shaun Smith on 08 Jan, 2010 02:14 PM

   

   Ah, with Flex a mediator's onRegister hook will only be called after creationComplete. So, the mediator gets created as soon as the view component lands on stage, but onRegister only gets called when the view component dispatches creationComplete. With plain as3, onRegister gets called sooner (immediately after the component is added to stage).

   • Edit

7. 7 Posted by Joe on 08 Jan, 2010 02:22 PM

   

   That's good to know thanks. I'm probably going to be moving the project to plain AS3 so as to save on overheads, but I think it'd probably be good practice to see if I can change the code so that it will work without being PUSHED data when ready... I'm thinking I'll probably get each Mediator to dispatch a [mediatorName]_READY event when they are ready... The problem is that if the event has already been dispatched before another mediator has been created, then I guess the only ways for amediator to test to see if another mediator exists are:

   1. Inject that mediator into the other mediator (probably not good practice?)
      
   2. Create a MediatorManagerModel class which stores information about which mediators are ready and which ones aren't

   Any thoughts or suggestions?

   • Edit

8. Support Staff 8 Posted by Shaun Smith on 08 Jan, 2010 02:30 PM

   

   Hmmm.. that all sounds way too complex and fragile to me. Perhaps you could attach a simplified version of your codebase, or write up a more detailed description of what you are wanting to achieve. I'm sure there is a much simpler solution to your problem.

   • Edit

9. Support Staff 9 Posted by Shaun Smith on 08 Jan, 2010 02:47 PM

   

   Perhaps the slight delay (caused by waiting for creationComplete) is giving you trouble due to your data not being loaded asynchronously - ie, the data is ready 1 frame before the view is ready. Just a thought..

   • Edit

10. 10 Posted by Joe on 08 Jan, 2010 03:22 PM

    

    Yes, that is pretty much what the problem is. Offline, the data loads immediately and so the mdel is ready before the view. But online, the view might well be ready before the model.

    I think I need to alter the view so that it just checks the model once it is ready... I will look at the problem with a fresh pair of eyes tonight, and possibly post some of the code for scrutiny!

    Just for the record, the app is a generic showreel creator, driven by XML (images, transitions, durations, randomize etc). The model stores the XML and keeps tabs on which slide is the current one etc... The view layers include the SlideMediator (the main slide showing layer), the NavigatorMediator (for showing the thumbnails and being able to jump between slides), the TransportMediator (for play/pause) and the LoadingMediator (for showing a loading bar if the image has not yet loaded).

    • Edit

11. Support Staff 11 Posted by Shaun Smith on 08 Jan, 2010 03:31 PM

    

    In that case, here's a possible way to approach it:

    You inject the model into the mediator. In the mediator's onRegister hook you check to see if the model is ready. If it's not you add a listener for a ModelReady kind of event (remember that models should dispatch events when their state changes significantly), if it is ready, then proceed as normal.

    • Edit

12. 12 Posted by Joe on 08 Jan, 2010 03:46 PM

    

    Thanks... I think the problem is that I was using a Command for dealing with when the model is ready...

    At startup, the model is initialized, the config XML loaded, and once loaded into the model I dispatch a CONFIG_LOADED event. From there I had a ConfigLoadedCommand which then set the model to the first slide of the first album, and then told the view to start playing.

    I don't really want to put that into the model, because that's business logic, so I'm not sure exactly how to tell the view to start showing the images...

    • Edit

13. Support Staff 13 Posted by Joel Hooks on 08 Jan, 2010 04:00 PM

    

    [I tried to email this, but don't think it arrived. Hopefully it doesn't post twice!]

    Configure Services -> Configure Model -> Initialize View -> Viewing

    It's a State Machine

    http://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCli...

    It doesn't add much complexity and gives you as fine of grain of control as you could hope to have on your bootstrap process.

    http://github.com/joelhooks/robotlegs-utilities-StateMachine

    • Edit

14. Support Staff 14 Posted by Joel Hooks on 08 Jan, 2010 05:59 PM

    

    To me this sounds like a really good use case for the Loadup or StateMachine utilities. Control the bootstrapping. Like a boss.

    • Edit

15. Support Staff 15 Posted by Joel Hooks on 08 Jan, 2010 06:01 PM

    

    Configure Services -> Configure Model -> Initialize View -> Viewing

    It's a State Machine

    http://github.com/joelhooks/robotlegs-examples-UnionPlatformChatClient/blob/master/src/org/robotlegs/examples/bootstrap/controller/configuration/BootstrapApplicationCommand.as

    It doesn't add much complexity and gives you as fine of grain of control as you could hope to have on your bootstrap process.

    http://github.com/joelhooks/robotlegs-utilities-StateMachine

    • Edit

16. 16 Posted by Joe on 09 Jan, 2010 08:45 PM

    

    That looks great, thanks! Is there any documentation on how it works?

    • Edit

17. Stray closed this discussion on 10 Feb, 2011 05:02 PM.