Flex component lifecycle and event flow explained

Learned something new from Ted today
Read original post by Ted here

Flex is an event driven programming model and everything happens due to an event. Looking at the MXML code can confuse most of the developers unless they haven’t looked at the internal class of flex components. If we were to compare Flex, HTML and FLASH in terms of component instantiation.

• HTML instantiates top to bottom
• Flash executes across frames starting at Frame zero.
• Flex on the other had is a bit different.

When I started  learning Flex, I struggled with understanding event flow and instantiation in MXML. I was puzzled because I really didn’t understand how event chain started and what happened inside a component to make it finally render on screen. Initially I used to run into numerous runtime  null point exception since i used to think i could access a property of  an object  thinking it would have been created.

Anyhow the key is understanding the event basics and seeing the initialization and event flow, Lets look at a sample application that i have written to explain this. The structure of the application cann be understood by the following diagram.

With this Demo app there is no visual clue that you will get  as an output to understand the event flow and instantiation step. its the TRACE statements that are important to explain  how the event  flow and instantiation happens. Below is the code for the same.

Call the following functions in a dummy APP

• preinitialize = “preinit(event)”
• initialize = “init(event)”
• creationComplete = “handlecc(event)”

Download the source here
I have also Monkey-patched the following classes

• VBox
• HBox
• Button

In all the above classes I have added a trace statement at  measure() updateDisplayList() and createChildren(). you can see get these files in the source attached.

The component lifecycle  happens  in the following order. Note: i am not explaining what these methods do, but in what order are they executed to give you the final result.

1. preInitialize()
2. createChildren()
3. initialize()
4. measure()
5. updateDisplayList()
6. creationComplete()

The order of instantiation can be understood by the trace log   if you compiled and  debugged the demoApp

1. 250ms  >> preinitialize test0
2. 259ms  >> preinitialize test0.hbox
3. 262ms  >> preinitialize test0.hbox.can
4. 265ms  >> preinitialize test0.hbox.can.cbt1
5. 266ms  >> create Children – test0.hbox.can.cbt1
6. 273ms  >> initialize test0.hbox.can.cbt1
7. 275ms  >> preinitialize test0.hbox.can.cbt2
8. 276ms  >> create Children – test0.hbox.can.cbt2
9. 277ms  >> initialize test0.hbox.can.cbt2
10. 278ms  >> initialize test0.hbox.can
11. 279ms  >> create Children – test0.hbox.can
12. 281ms  >> preinitialize test0.hbox.vbox
13. 283ms  >> preinitialize test0.hbox.vbox.btn1
14. 284ms  >> create Children – test0.hbox.vbox.btn1
15. 285ms  >> initialize test0.hbox.vbox.btn1
16. 287ms  >> preinitialize test0.hbox.vbox.btn2
17. 288ms  >> create Children – test0.hbox.vbox.btn2
18. 289ms  >> initialize test0.hbox.vbox.btn2
19. 290ms  >> initialize test0.hbox.vbox
20. 291ms  >> create Children – test0.hbox.vbox
21. 292ms  >> initialize test0.hbox
22. 293ms  >> create Children – test0.hbox
23. 294ms  >> initialize test0
24. 310ms  >> measure – test0.hbox.can.cbt1
25. 312ms  >> measure – test0.hbox.can.cbt2
26. 313ms  >> measure – test0.hbox.vbox.btn1
27. 313ms  >> measure – test0.hbox.vbox.btn2
28. 315ms  >> measure – test0.hbox.can
29. 315ms  >> measure – test0.hbox.vbox
30. 317ms  >> measure – test0.hbox
31. 344ms  >> updateDisplayList – test0.hbox
32. 348ms  >> updateDisplayList – test0.hbox.can
33. 350ms  >> updateDisplayList – test0.hbox.vbox
34. 351ms  >> updateDisplayList – test0.hbox.can.cbt1
35. 356ms  >> updateDisplayList – test0.hbox.can.cbt2
36. 358ms  >> updateDisplayList – test0.hbox.vbox.btn1
37. 359ms  >> updateDisplayList – test0.hbox.vbox.btn2
38. 364ms  >> creationComplete test0.hbox.can.cbt1
39. 365ms  >> creationComplete test0.hbox.can.cbt2
40. 366ms  >> creationComplete test0.hbox.vbox.btn1
41. 367ms  >> creationComplete test0.hbox.vbox.btn2
42. 368ms  >> creationComplete test0.hbox.can
43. 370ms  >> creationComplete test0.hbox.vbox
44. 371ms  >> creationComplete test0.hbox
45. 373ms  >> creationComplete test0

Just by looking at the trace log and the application structure image you can slowly start making out a pattern (preorder traversal). preInitialize() is called first  for the App then the first child(in our case only child HBOX) then its first child which is the CANVAS and finally the  first child of canvas that is C BUTTON 1  after this the createChildren() and initialize() of the  innermost left child is called  then moving on to its sibling  the preInitialize(), createChildren() and initialize() is called.  This  is followed till all the children have completed the preInitialize(), createChildren() and initialize() steps.

After this the measure() of all the child’s are called in a bottom up approach with left child priority.

After this the updateDisplayList() of all the children’s are aclled in a  top down approach with left child priority.

Finally the creationComplete() of all the children are called  again in bottom up approach with left child priority.  Thus explaining why creationComplete() of the parent component is called at the very end.  the more you look at the log trace the more you will understand the flow.  Hope this effort of my explaining the instantiation process helped you out.

Download the source here

Tags: components, event flow, flex, lifecycle