Flex 101: AddChild and RemoveChild event order

Flex 3 documents in details how the component life cycle happens in terms of the instantiation process. However, it seems it lacks information about how Flex treats AddChild/RemoveChild process. Understanding the process is important for choreographing transitions on a Flex state machine.

Note that”add”/”remove” events are dispatched on calls to “addChild”/”removeChild”/”removeAllChildren”. So an “add” event is fired before the “preinitialize” event for that component.

Type 1. Under a State tag, AddChild tags that include only non-AddChild tags. Flex instantiates the components in the order of the MXML tags, from inside out, top down. Thus the innermost first target component will be the first one to be instantiated and added to the Displaylist (This is because Flex will use the dimensions of the descendants to determine the dimension of the parent component). The top AddChild target will be the last to be added. When the container’s creationPolicy is “none”, it seems that all the components are instantiated (“added” events are fired and the parent container is redrawn to accommodate the newly added descendants. This observation is on the contrary to the Flex documentation) but not drawn. If you exit the state that contains this top AddChild target, Flex simply removes the topmost component from the Displaylist and thus there are no subsequent “add” or “remove” events fired from its children components.

For the transitions of this kind of components, you can only treat them as a whole block (i.e., applying transitions to the top parent containers).

Type 2. Under a State tag, AddChild tags that include other Addchild tags. You use subsequent AddChild nodes following a top AddChild node as their container. Flex instantiates the components strictly by the order of the MXML tags, from top down, regardless of the hierarchy of the nodes. When removing the nodes, Flex follows the reverse order from which it adds these components, that is, the last component being added will be the first one to be removed, etc…; (Understandably, the innermost children will be removed before their parents are removed, also by the reverse order from which they are added, because during the instantiation process their parents are added before they are added — you cannot reattach a component to another container at compile time by MXML tags; you always create the parent containers first and then add components into them.)

Type 3. In the “base” state. In the “base” state, for a container, the top container’s “add” event is dispatched first before Flash Player drills down to reach its individual descendant components, which is different than what happens in Type 1. When exit from the “base” state, Flex simply removes the top container without worries about its descendants, which is the same as Type 1.

The above describes the order Flex dispatches events when no transitions are applied and with all the container’s creationPolicy set to “all/auto” (default).

Of all the 3 types mentioned above, Type 2 gives you the most flexibility in terms of how you can do with transitions. In Type 1 and 3, you can only apply effects on the top container, as opposed to its individual child components. So if you want to have a granular control on how individual child components inside a container component are animated, you can choose Type 2 combined with transitions.

Using transitions tags, Flex choreographs the staging of visual components at runtime. This means that you can dictate when these components appear in the order you want, which can be different than what you specified using AddChild/RemoveChild tags. A couple of test drives show that you have the freedom in the following usages of MXML tags, for any container with multiple descendants that is added by AddChild tag (applicable to Type 2 only):

  • Arbitrary order for AddChild tags (meaning you can have a different order on how transitions happen than the one that you use to create them in the State tags);
  • Arbitrary order for RemoveChild tags;
  • Arbitrary grouping on AddChildAction targets (meaning that you can group the targets in the order which is different than what you use in the State tags);
  • Arbitrary grouping on RemoveChildAction targets.
Advertisements

2 Responses to “Flex 101: AddChild and RemoveChild event order”

  1. Flex 101: AddChild and RemoveChild event order « Rich Internet Applications Says:

    […] Source […]

  2. Transitions tips and trouble shooting in Flex 3, Take 1 « :maohao: Says:

    […] :maohao: by maohao.com « Flex 101: AddChild and RemoveChild event order […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: