Demo - Flex / Slacker

This demo illustrates techniques for handling Flex's Deferred Instantiation of View Components.

Discussion

The simplest startup scenario for a Flex or AIR app is that the MXML application creates itself first (the view components), then the PureMVC apparatus we build attaches itself to the MXML app by registering Mediators with references to the already constructed view components in the display hierarchy.

However a powerful feature of Flex is deferred instantiation of view components, and the default behavior of Flex with regard to this feature is something you must understand in order to reliably create Flex applications, regardless of whether you're using PureMVC.

• In a ViewStack or TabNavigator, for instance, although several children may be defined in the MXML, only the first visible child will be instantiated by default (creationPolicy="auto"). The other children will be instantiated only when you navigate to them.

This is nice because avoiding the unnecessary object creation helps the startup go faster, feeling more responsive to the user. And since the user may not navigate to all the children, both time memory is conserved. The user may encounter a small delay when navigating to a child for the first time, as he incurs this deferred object creation cost. Unfortunately, now our simple PureMVC startup scenario described above is no longer enough, because at startup time, we don't have references to all the view components that will eventually need mediation.

Although we could register the Mediators and later give them references to the view components as they are created, that sort of defeats the point of deferred instantiation.

• We usually want to defer the creation and registration of the Mediator until its corresponding view component exists.

This demo illustrates show to create and register Mediators for those deferred children when they are eventually created.

---

HERES WHAT HAPPENS:

---

1. The Main MXML Application (Slacker) gets the ApplicationFacade instance *during* its creation.

2. This initializes the Model, View, Controller and Facade instances, and registers STARTUP/StartupCommand with the controller.

3. Slacker completes its MXML creation process, instantiating an ApplicationControlBar with several buttons, as well as an instance of the MainDisplay component with the id 'mainDisplay'. The creation of MainDisplay led to the creation only of its first child SplashView.

4. On creationComplete, Slacker calls facade.startup(this);

5. The ApplicationFacade.startup method sends the STARTUP notification, passing the reference to Slacker, the app.

6. The StartupCommand registers the ApplicationMediator passing it the reference to the app.

7. Once registered, the ApplicationMediator registers the MainDisplayMediator passing it the reference to app.mainDisplay. It also adds event listeners to the app for Slacker.SHOW_GALLERY, Slacker.SHOW_EDITOR and Slacker.SHOW_PROFILE. It doesn't listen for or handle any Notifications, the ApplicationMediator merely relays your button presses into the system.

8. When MainDisplayMediator is registered, its interests are listed as ApplicationFacade.GALLERY_MODE, ApplicationFacade.EDITOR_MODE and ApplicationFacade.PROFILE_MODE. It also adds event listeners to the mainDisplay for MainDisplay.GALLERY_CREATED, MainDisplay.EDITOR_CREATED and MainDisplay.PROFILE_CREATED

9. The system now awaits your input.

10. You click one of the buttons on Slacker's ApplicationControlBar (Gallery, Editor or Profile)

11. Slacker sends the corresponding event; Slacker.SHOW_GALLERY, Slacker.SHOW_EDITOR or Slacker.SHOW_PROFILE.

12. The ApplicationMediator responds by sending a corresponding system notification ApplicationFacade.GALLERY_MODE, ApplicationFacade.EDITOR_MODE or ApplicationFacade.PROFILE_MODE

13. The MainDisplayMediator handles the Notification by setting the mainDisplay.currentViewSelector to the corresponding selector value: MainDisplay.GALLERY, MainDisplay.EDITOR or MainDisplay.PROFILE

14. Inside MainDisplay, the selectedIndex of the ViewStack is bound to the currentViewSelector property, and so it changes to display the child you have selected by button press.

15. If this is the first navigation to the selected child, it will be instantiated at this time, and on creationComplete, it will send MainDisplay.GALLERY_CREATED, MainDisplay.EDITOR_CREATED and MainDisplay.PROFILE_CREATED.

16. Regardless if it was the first navigation, Flex binding inside the MainDisplay component will set its activeView property to the selectedChild of the ViewStack.

17. The MainDisplayMediator will respond by calling its checkForMediator method, which will register the appropriate mediator for the selected child mainDisplay.activeView only if it doesn't already exist.

18. The Mediators for the children (GalleryViewMediator, EditorViewMediator or ProfileViewMediator) all do the same thing for the purposes of this demo.

19. Once registered, the child's Mediator will set its child's message property to 'Hello from the newly created SomethingMediator'. It will also set an event listener on its child for the FlexEvent.HIDE event. Since the Mediator's just been registered, we'd like this initial message to show the first time, we'll change it when you navigate away so that when you come back, it displays a different message.

20. When you click on a different button this child's HIDE event is fired, and its Mediator sets its message to 'Hi again from your old friend SomethingMediator'. It removes the event listener for the HIDE event, as we only wanted to capture it the first time to change this message.

21. Another child is displayed, with its 'Hello from the newly created SomethingMediator' message if it is the first time for that child.

22. You click the first button again, displaying a child you've already selected.

23. Again, steps 10-16 are executed, only this time its not the first time that child was selected. The child is still displayed and now shows the message that was written to it when it was hidden.