OReilly PureMVC Book

PureMVC Book



PureMVC on the Web

PureMVC Blog-o-Sphere
PureMVC on LinkedIn
How do I handle deferred instantiation of view components?
Saturday, 16 August 2008


I am having some difficulties loading views components in a Flex ViewStack.
See the steps:

- MainApp load
- ViewStack default view: A
- I login
- ViewStack Changes view to: B
- View B have more two components inside (B.1,B.2)
- When i tried send data for components B.1 and B.2 their are unavaible it sends an error that object is null

I have done some research and find maybe it's creationPolicy, the default is "auto" and I changed it to "all" and the objects are now avaliable.

My question is how to handle this without the creationPolicy=all, because now my App just have 2 views and 3 components, but when I have 50 components this will take a long time to start will it not? What is the best practice to do this?



 This is the cannonical deferred instantiation problem. 

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


However a feature of Flex is deferred instantiation of view components. In a ViewStack, 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 it helps startup go faster, and the user may not navigate to all the children, so time and memory is conserved.


Unfortunately, now our simple scenario 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. So we need to defer the creation and registration of the Mediator as well.


One thing to note here: Deferred instantiation is great, but OPTIONAL.
If the children of this ViewStack are pretty simple, as I imagine from your description they are, then instead of jumping through hoops trying to deal with it in the framework, simply set creationPolicy=all in your viewstack and be done with it.

Remember this is a simple case. Deferred instantiation is the default behavior because it is expected that you want the most optimal startup experience. And if you have a ViewStack with a ton of stuff in it that will take a long time to instantiate and so the perceived load time is longer. So...

Inevitably, you will have an app complex enough that you have to deal with this problem. Then you need to study the release notes and source code for the Slacker demo.

Furl it!
Copyright (c) 2006-2012 Futurescale, Inc.