Nate on Tech

Day 3. Session 4. Alex Harui talks about the innards of building Flex components, from construction to interaction, and then detachment.

These are the steps that a Flex component undergoes during its lifetime:

1. Construction – You should attach event handlers, and do not create children objects here. If it’s going to be extended by MXML, do not require any constructor arguments.
2. Configuration – MXML tags set properties on your component. Sub-components are not created yet, so you need to store any dependent properties for later use via private or protected properties. Use invalidateProperties() in any of these setters to accommodate this.
3. Attachment – Parent gets addChild() called, which then calls your component’s initialize() method.
4. Initialization – The default behavior fires a preinitialize event, calls createChildren, fires initialize event, invalidates everything. Don’t typically need/want to override initialize(), instead just override createChildren(). Defer creating dynamic or data-driven components until commitProperties().
5. Invalidation - marks a portion of the component as “dirty”:
   1. invalidateProperties() – calculations, child management
   2. invalidateSize() – measurements: width & height
   3. invalidateDisplayList() – changes to appearance: color, internal positions, etc.
6. Validation – at the end of the frame’s cycle, if any portion of a component is marked as “dirty”, the corresponding function is called:
   1. commitProperties() – before measurement & layout, calculate changes to properties, create and destroy sub-components
   2. measure() – calculate how big we want the component to be; not called if explicit size is used, and should also decide how to deal with minimum width/height values.
   3. updateDisplayList() – move and resize sub-components, redraw graphics (using unscaled width/height).  Make sure you use move() and setActualSize() instead of directly accessing the x, y, width, height properties, or else these property changes will result in Flex automatically calling invalidateDisplayList() again.
   4. “render” event – this event fires whenever flash decides it will be re-rendering this component. Not very reliable for visual updates, for example if the component is off-stage or hidden, will probably not be called.
7. Interaction – this deals with events, whether from a user or data feed. Events are made up of a name (ie: click), a target (ie: button1), and are of a specific Actionscript class. To handle events, you create a function and pass it to addEventListener(). Note: functions retain their scope automatically in Actionscript 3, even inline functions do!
8. Detachment – Flex components can be un-parented and re-parented, though this has a much higher overhead than simply hiding and showing using visibility. If a component is detached at the end of a frame, and there are no other references to it, it is eligible for garbage collection.
9. Garbage Collection – only if there are no references anywhere, though references to a parent do not count. The garbage collector starts at the top-level of the application, and moves down the tree.

Last-minute performance tips:

• Use factories (IFactory interface) for your components that could generate multiples of a single component, like lists.
• Use styles instead of a property if you expect a single app to use the same style across (mostly) all instances of your component.
• Skins are useful for defining bitmaps or vector images for specific uses in your component.
• Specify binding event names instead of forcing the compiler to define them.

Update 2008-06-24:  #6c now includes notes on move() and setActualSize().  Added relevant tags to the post.

Tags:commitProperties» custom components» Flex» measure» updateDisplayList»