Home › Blogs › Rick Winscot's blog

Creation Policy Smackdown

Wed, 11/18/2009 - 15:46 — Rick Winscot

Code review is one of my least favorite activities... mostly due to the moments when I run across bits of ill-performing code that throw me into a fit of rage. Is it that hard to follow creation policy best practice? ...or to at least comment why you didn't?

These two words can help: deferred instantiation.

"If the number one cause of performance problems is unnecessary measurement and layout from superfluous container nesting, the number two cause is creating objects before they are needed."

Here's the skinny...

"When Flex creates the navigator containers, it does not immediately create all of their descendants, only those that are initially visible. The result of this deferred instantiation is that an MXML application with a navigator container loads quickly, but users experience a brief pause the first time they navigate from one view to another. Usability studies have shown this is a better user experience then having to wait a noticeable amount of time at application startup to create the navigator containers' child views. Also, there is always the possibility that the user may never visit some of the child views, so creating them at startup is potentially wasteful."

Every time I see creationPolicy="all" I ask whoever committed the code why it was used. The typical answer I get is that...

"I was getting this crazy runtime null-object exception and marking the creation policy as all fixed it."

This is a reason... but it isn't a good one. What does a bad approach look like?

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
  3.         creationComplete="ccomp()"
  4.         layout="absolute">
  5.  
  6.   <mx:Script>
  7.   <![CDATA[
  8.                        
  9.   private function ccomp():void
  10.   {
  11.     lblOne.text = "Hello Label One!";   // no big...
  12.     lblTwo.text = "Hello Label Two!";   // this will cause a runtime error.
  13.   }
  14.                        
  15.   ]]>
  16.   </mx:Script>
  17.  
  18.   <mx:TabNavigator width="287" height="165" horizontalCenter="0" verticalCenter="0">
  19.     <mx:Canvas label="View One" width="100%" height="100%">
  20.       <mx:Label text="Label" id="lblOne" verticalCenter="0" horizontalCenter="0"/>
  21.     </mx:Canvas>
  22.     <mx:Canvas label="View Two" width="100%" height="100%">
  23.       <mx:Label text="Label" id="lblTwo" verticalCenter="0" horizontalCenter="0"/>
  24.     </mx:Canvas>
  25.   </mx:TabNavigator>
  26.        
  27. </mx:Application>

Now for something completely different... this approach won't throw those nasty runtime errors since it supports the notion of deferred instantiation through binding (a best practice).

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
  3.         creationComplete="ccomp()"
  4.         layout="absolute">
  5.  
  6.   <mx:Script>
  7.   <![CDATA[
  8.                        
  9.   [Bindable]
  10.   private var _lblOneText:String = "Label";
  11.  
  12.   [Bindable]
  13.   private var _lblTwoText:String = "Label";
  14.                        
  15.   private function ccomp():void
  16.   {
  17.     _lblOneText = "Hello Label One!";   // huzzah!
  18.     _lblTwoText = "Hello Label Two!";   // double huzzah!
  19.   }
  20.                        
  21.   ]]>
  22.   </mx:Script>
  23.  
  24.   <mx:TabNavigator width="287" height="165" horizontalCenter="0" verticalCenter="0">
  25.     <mx:Canvas label="View One" width="100%" height="100%">
  26.       <mx:Label text="{_lblOneText}" id="lblOne" verticalCenter="0" horizontalCenter="0"/>
  27.     </mx:Canvas>
  28.     <mx:Canvas label="View Two" width="100%" height="100%">
  29.       <mx:Label text="{_lblTwoText}" id="lblTwo" verticalCenter="0" horizontalCenter="0"/>
  30.     </mx:Canvas>
  31.   </mx:TabNavigator>
  32.        
  33. </mx:Application>

More code? Yes... there is a little more code but the performance gains you get from supporting deferred instantiation far outweigh that cost. The moral of the story is, "there is nothing lazy about lazy-loading."

For more detail on creation policy I would recommend this article on ADC.

Flex Application Performance: Tips and Techniques for Improving Client Application Performance