The life cycle that the component framework provides is an important aspect of the Flex framework. By understanding the component life cycle, you will be able to build better components more quickly.
Note
Most of the Flex framework—and the built-in component in particular—is based on the same component life cycle discussed in this chapter. As such, not only is it helpful to learn the component life cycle for building custom components, but it is also helpful for understanding the Flex framework as a whole for building applications.
The component life cycle comprises three phases: initialization,
update, and destruction. The initialization phase consists of three main steps: construction, attachment, and
initialization (the latter is not to be confused with the initialization
phase of which it is a part). The initialization step is composed of its
own steps. For instance, during the initialization step, the component
dispatches the preinitialize event,
calls the createChildren() method, dispatches the initialize event, goes through a full invalidation and validation, and finally
dispatches the creationComplete event.
At this point, the component has completed the
initialization step. Figure 19-2 outlines the
initialization phase and its steps.
The update phase comprises everything that occurs between the initialization
and destruction phases, and it is the phase during which the component
responds to changes. The update phase begins right after the
initialization phase and goes through a repeated set of steps to keep the
component updated. Typically in the update phase, the component is
initially in the waiting step, during which it awaits a request to change.
If a component is initialized and never changes, it will stay in the
waiting step. If the component receives a request to change—for example,
if it receives a request to set a new value for Button.label—it goes through an invalidation
step, then through validation, and finally back to the waiting
step.
Note
Flash Player renders on a frame-by-frame basis. Because of this, it is important to merge the rendering updates together rather than process them immediately.
The invalidation and validation steps in the update phase are the same steps as those in the initialize phase. Also important to note is that a component can go through an update phase many times throughout its lifetime. If many updates to a component are requested at different times, the component will go through the same cycle each time and return to the waiting step. That is why, for performance considerations, you will need to ensure that the validation step is optimized to handle many calls, and you will need to reduce the processing required to satisfy this step. Figure 19-3 outlines the update phase and the repeated cycle of validation. In the next section, you will learn more about the details of each step in the life cycle of a component.
In this step of the life cycle, the component is instantiated, the constructor is called,
and the component begins its life cycle. The component is instantiated
either by being declared in MXML or through the new operator in ActionScript. The component
constructor typically does not contain any implementation other than
calling super(), and sometimes it
adds event listeners to application events that your component needs to
be aware of. Typically you will want to do very little during this step
because it is early in the component’s life, and most parts of the
component are not ready yet. Instead, you will perform the other
functions in other methods, as we will see later.
During this step, which occurs only during the initialization phase, component properties are set internally to be processed later in the component’s life cycle. The values are set using the setter functions of the defined component. We will cover how to handle setter functions within components later in this chapter.
When a component is instantiated, it does not automatically
complete the entire initialization phase until it's added to the display
list, and it has a parent. Once a component is attached using addChild or addChildAt, or is declared via MXML (which
internally calls addChild
automatically), this step of the cycle begins and the internal initialize() function of the
component is called.
This step occurs after attachment. In this step, the preinitialize event is dispatched, the
createChildren() method is called,
the initialize event is dispatched,
invalidation and validation occur, and finally the creationComplete event is fired. After this
step, the component has finished the initialization phase and will enter
the update phase.
This step occurs both the first time a component is initialized and during the update phase. Invalidation is a key concept in the component framework. Invalidation is a mechanism by which changes made to a component are queued and processed simultaneously. Flash Player internally renders on a frame-by-frame basis. Therefore, there is no benefit to immediately updating values that will affect the rendered view of a component. With invalidation, all changes are noted within the component, and the component is marked for validation. In the validation step, the values that were noted are actually rendered. This occurs when the next frame is reached in Flash Player.
When a component is first initialized, it is automatically marked
for full validation. But after a component is initialized, it is marked
for validation during the update phase by calling the invalidateProperties(), invalidateSize(), or invalidateDisplayList() method. Later in this
chapter, we will examine the role these methods play and how to
implement proper invalidation.
When a component is being initialized, the last step before
the creationComplete event is
dispatched is the validation step. This step also occurs when a
component is invalidated using one of the invalidate methods. The
validation phase is where the commitProperties(), measure(), or updateDisplayList() method of the component is
called. During initialization all three methods are called. We will
cover how to implement the validation methods properly later in this
chapter.
The destruction phase (also sometimes referred to as the detachment phase) occurs when a component is removed from the display list. At this point, the component no longer participates in the layout events, and if it is no longer referenced anywhere, it will be garbage-collected and removed from memory.