Hi Julian,
There are a number of ways of dealing with deferred instantiation in the View. Here are a few ways, and the pros and cons of each.
1) Creating Mediators ahead of time with dummy View Components, then later passing the real View Components to them in Notification bodies.
Pros:
Easy because you can use a startup command to handle all the Mediator creation/registration at once, even though some of the View Components aren't created yet.
Cons:
Defeats the purpose of deferred instantiation, which is to avoid incurring the object creation cost until you need it.
Makes the Mediator have to work differently than other Mediators, because instead of setting listeners on the view component immediately in the constructor, we have to do it in handleNotification or a method invoked from within handleNotification.
2) Defer instantiation of the Mediator until its View Component is created. (Recommended). The View Component who will have children dynamically created at runtime must arrange a way to alert its Mediator of child creation. This can be done with a custom event class that the Mediator listens for and which has a property that is a reference to the new child. Or you can send a regular event that alerts the Mediator that it should check a 'lastChildCreated' property that would hold a reference to this newly created child (hint:bind to the tab navigator's selectedItem property). When the Mediator hears this event, it gets the reference to the new child and based upon its id property or some other discriminator, determines the appropriate Mediator to instantiate and register. If the process of determining which Mediator to create is very involved, you might want to move this part of the process out to a Command, and have the Mediator respond to the event at the view simply sending a notification with the new View Component as the body and let the Command figure it out.
Pros:
Defers instantiation of the Mediator until it is required, meaning faster startup and lower memory footprint.
Cons:
More involved from an 'understanding the system' perspective. Deferred instantiation is automagical in Flex, we don't have to do anything to reap its benefits. But on a framework that manages a running Flex UI, we do have to think about it a bit and understand what's happening.
3) Turn off deferred instantiation for these children altogether. In the case of a normal ViewStack, TabNavigator or Accordion you can simply set creationPolicy="all'. This means that all the children will be created at startup, nothing will be deferred. (usually
not recommended)
Pros:
If you have a very simple interface where the creation time isn't greatly affected by creating all the children to begin with, then this can remove the issue of dealing with deferred instantiation from the PureMVC side of things altogether. You create all Mediators to start with because all the children are already there.
Cons:
This can impact startup performance and memory footprint. It should only be done if you are sure that all the children will be used during the session, and the startup time is acceptable.
Purists will laugh at you and malign your ways.
Hope this helps,
-=Cliff>
