The Flex documentation on the UIComponent life cycle is rather difficult to understand, and so I came up with what I felt was an easier and more logical way of describing the process. I felt this might be useful for those who are interested in creating custom visual components in Flex that extend the UIComponent class. Creating custom components without having a solid understanding of the functionality that is abstracted within the Flex framework in regard to how it lays out UIComponent objects will likely result in design decisions that are inconsistent with the Flex Framework, which could potentially lead to a frustraing and seemingly uphill battle between the developer and the framework.
The following flow diagram represents the process that is abstracted within the Flex framework when the addChild() command is made to create and make a visual component visible on the stage, or when the properties of the component and/or it's parent change (like a new data update for example):
Note that if that is a little hard to read, you can click on it and it will brink up a pdf version. This is identical to what is said in the Flex documentation, it is just a lot easier to understand for those of us who appreciate visual representations of processes that are comprised of many steps. It is just easier to follow.
You will notice toward the bottom the diamond shape, which represents a decision that has to be made. The thing to understand here, is that additional components may be going through this same process simultaneously, thus affecting the layout properties of each other. An example might be the resizing of the parent window. The invalidation methods in essence, act as a sort of "queue" so to speak, so the actual stage ends up redrawing just once even though a number of things may have changed. The point at which the UIComponent makes the decision on whether or not to re-render is sort of like it is checking itself to make sure that it is ready before becoming visible. If a number of visual properties have been set on it or something else changed again that forced the invalidation methods to be called again on the components, it re-runs the commitProperties(), measure(), layoutChrome(), and updateDisplayList() methods again, and will continue to do so until it knows that it is now ready to be seen, at which point it's visible property is set to true.
The speed at which this all happens and the overall architectural decisions with regard to how the stage is drawn in a Flex app and the way the visual elements are laid out, is truly quite impressive, and worth studying in further detail if you are interested in learning more about the design patterns used in the Flex framework to make it work the way it does. Although Flex does have its flaws, this is an example of how the framework abstracts a lot of functionality quite elegantly for the developer.
from link