5.
Flex Component Lifecycle
‣ What is it?
• The way the framework interacts with
every Flex component
• A set of methods the framework calls to
instantiate, control, and destroy
components
• Methods that make the most of the
elastic racetrack

6.
Elastic Racetrack: introduction
image courtesy of Ted Patrick
‣ Flex component lifecycle is built on this
frame model
‣ More on this later

13.
What does a constructor have access to?
‣ Properties on the class
‣ Methods on the class
‣ Children have not yet been created!
Birth
construction
con guration
attachment
initialization
Life
Death

14.
What does an ActionScript3
constructor look like?
public function ComponentName()
{
super();
//blah blah blah
}
‣ No required arguments (if it will be used in
MXML); zero, or all optional
‣ Only one per class (no overloading!)
‣ No return type
Birth ‣ Must be public
construction
con guration ‣ Calls super() to invoke superclass constructor; if
attachment
initialization
you don’t, the compiler will!
Life
Death

15.
What does an MXML constructor
look like?
‣ No need to de ne one. In fact, if you try
to put one in an <mx:Script> block, you’ll
get an error.
‣ Why? Remember: MXML = Actionscript. A
constructor is created by the compiler in
the Actionscript generated from the
MXML.
Birth
‣ Specify “-keep” in the Flex Builder
construction
con guration
compiler arguments and look at the
attachment generated code to verify this.
initialization
Life
Death

16.
What should a constructor do?
‣ Not much.
Since the component’s
children have not yet been created, there’s
not much that can be done.
‣ There are speci c methods (such as
createChildren) that should be used for
most of the things you’d be tempted to
put in a constructor.
Birth
‣ A good place to add event listeners to the
construction
con guration
object.
attachment
initialization
Life
Death

17.
Don’t create or attach children in
the constructor
‣ It’s best to delay the cost of createChildren
calls for added children until it’s necessary
Birth
construction
con guration
attachment
initialization
Life
Death

19.
Con guration
‣ The process of assigning values to
properties on objects
‣ In MXML, properties are assigned in this
phase, before components are attached or
initialized
<local:SampleChild property1="value!"/>
Birth
construction
con guration
attachment
initialization
Life
Death

36.
Deferment
‣ Deferment is the central concept to
understand in the component Life-cycle
‣ Use private variables and boolean ags to
defer setting any render-related
properties until the proper validation
method

47.
commitProperties() cont.
‣ ALL changes based on property and data
events go here
‣ Even creating and destroying children, so
long as they’re based on changes to
properties or underlying data
‣ Example: any list based component with
empty renderers on the screen
Birth
Life
invalidation
validation
interaction
Death

48.
measure()
‣ Component calculates its preferred
(“default”) and minimum proportions
based on content, layout rules,
constraints.
‣ Measure is called bottom up - lowest
children rst
‣ Caused by “invalidateSize()”
‣ NEVER called for explicitly sized
Birth
Life components
invalidation
validation
interaction
Death

49.
overriding measure()
‣ Used for dynamic layout containers (VBox,
etc.)
‣ Use getExplicitOrMeasuredWidth() (or
height) to get child proportions
‣ ALWAYS called during initialization
‣ Call super.measure() rst!
‣ Set measuredHeight, measuredWidth for
Birth the default values; measuredMinHeight
Life
invalidation
and measuredMinWidth for the minimum.
validation
interaction
Death

51.
updateDisplayList()
‣ All drawing and layout code goes here,
making this the core method for all
container objects
‣ Caused by invalidateDisplayList();
‣ Concerned with repositioning and
resizing children
‣ updateDisplayList() is called top-down
Birth
Life
invalidation
validation
interaction
Death

52.
Overriding updateDisplayList()
‣ Usually call super.updateDisplayList() rst
• super() is optional - don’t call it if you’re
overriding everything it does
‣ Size and lay out children using move(x,y)
and setActualSize(w,h) if possible
• I never have good luck with
setActualSize()
Birth
Life
invalidation
validation
interaction
Death

57.
How do objects know when
something happens?
‣ Events: objects passed around when
anything interesting goes on (clicks,
moves, changes, timers...)
‣ If something happens to a component, it
“ res” or “dispatches” the event
‣ If another component wants to know
when something happens, it “listens” for
events
Birth
Life ‣ Event-based architecture is loosely-
invalidation
validation coupled
interaction
Death

58.
Bene ts of Loosely-Coupled
Architectures
‣ Everything becomes more reusable
‣ Components don’t have to know anything
about the components in which they’re
used
Birth
Life
invalidation
validation
interaction
Death

66.
Stopping events from propagating
‣ stopPropagation() : Prevents processing
of any event listeners in nodes
subsequent to the current node in the
event ow
‣ stopImmediatePropagation() : Prevents
processing of any event listeners in the
current node and any subsequent nodes
in the event ow
Birth
Life
invalidation
validation
interaction
Death

67.
target vs. currentTarget
‣ target: the object that dispatched the
event (doesn’t change)
‣ currentTarget: the object who is currently
being checked for speci c event listeners
(changes)
Birth
Life
invalidation
validation
interaction
Death

71.
Detachment
‣ “Detachment” refers to the process of
removing a child from the display list
‣ These children can be re-parented
(brought back to life) or abandoned to die
‣ Abandoned components don’t get
validation calls and aren’t drawn
‣ If an abandoned component has no more
Birth
active references, it *should* be garbage-
Life
Death
collected
detachment
garbage
collection

72.
Detachment cont.
‣ Re-parenting isn’t cheap, but it’s cheaper
than re-creating the same component
twice
‣ Children do not need to be removed from
their parent before being re-parented, but
always should be
‣ Consider hiding rather than removing
• set visible and includeInLayout to false
Birth
Life
Death
detachment
garbage
collection

74.
Garbage Collection
‣ The process by which memory is returned
to the system
‣ Only objects with no remaining references
to them will be gc’d
• Set references to detached children to
“null” to mark them for GC
‣ Talk to Grant Skinner about forcing GC
Birth • http://gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html
Life
Death
detachment
garbage
collection