UI Component life cycle in Flex

The Flex Component LifeCycle is a set of methods and events that Flex uses to set up components. In our own components, that extend the UIComponent class, we can listen to these events or override these methods to do stuff that is specific to our component.

I'll add that updateDisplayList() is a method, not an event, just in case their is any confusion.

These are the main overridable methods:

• createChildren(): This is used to create a component's children.
• commitProperties(): This is a wild card method. You use it to coordinate multiple property changes in a single place. What you use it for depends on the component you're creating and the properties.
• measure(): This is used to set the "ideal" height and width of the component, based on the children. You set the measuredHeight and measuredWidth.
• updateDisplayList(): This is used to do anything display related, most commonly position and size the component's children.

All of these methods will running during the initial component creation. However, three of these methods--commitProperties(), measure(), and updateDisplayList()--can be set up to run during the next render event. To prep them for run, just invalidate them using the appropriate invalidation method:

• invalidateProperties() forces commitProperties() to rerun.
• invalidateSize() forces measure() to rerun.
• invalidateDisplayList() forces updateDisplayList() to rerun.

How often a render events fires depends on your application's frame rate. I think the default Flex frame rate is 24 frames per second, so there is one render event every 1/24th of a second.

I defined the component lifecycle as being a collection of methods and events. So, these are the events, in the order they fire:

• preinitialize
• initialize
• childAdd
• updateComplete
• creationComplete

updateComplete will fire after every renderer event, I believe. But the others are part of the component creation.

You should read the Flex documentation on this

The Spark Component Lifecycle adds different hooks to accommodate the two class approach; with one class for business logic and one for skinning. But, it sill extends the MX/Halo component Lifecycle.