SlideShare ist ein Scribd-Unternehmen logo
1 von 76
Downloaden Sie, um offline zu lesen
Diving Deep with the Flex
  Component Lifecycle
        Joshua Jamison
          EffectiveUI
      www.effectiveui.com
       January 30, 2009
Who am I?



   ‣ Joshua Jamison
    •   Software Architect @ EffectiveUI
Who are you (hopefully)?


     ‣ Beginner to intermediate level developers
     ‣ Anyone who doesn’t currently understand
       the lifecycle
     ‣ Anyone who wants a good review of the
       basics
What’s this about, anyway?




     ‣ Flex component lifecycle
     ‣ Flex frame cycle (“elastic racetrack”)
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
Elastic Racetrack: introduction




                                       image courtesy of Ted Patrick




 ‣ Flex component lifecycle is built on this
   frame model
 ‣ More on this later
A frame in AS3




                 image courtesy of Sean Christmann
Phases of the Lifecycle

      ‣ 3 Main Phases:
      ‣ BIRTH:
        •  construction, con guration,
           attachment, initialization
      ‣ LIFE:
         • invalidation, validation, interaction
      ‣ DEATH:
         • detachment, garbage collection
Birth
Congratulations: You’re about to have a component.
Construction


Birth
   construction
   con guration
   attachment
   initialization
Life
Death
What is a constructor?




                    ‣ A function called to instantiate (create in
                     memory) a new instance of a class


Birth
   construction
   con guration
   attachment
   initialization
Life
Death
How is a constructor invoked?



                                Actionscript:
                    var theLabel : Label = new Label();


                                  MXML:
                        <mx:Label id="theLabel"/>


Birth
   construction
   con guration
   attachment
   initialization
Life
Death
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
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
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
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
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
Con guration


Birth
   construction
   con guration
   attachment
   initialization
Life
Death
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
Hooray: Sample code!


                    <mx:Application ...>
                    	 ...
                      <local:SampleChild property1="value!"/>
                    </mx:Application>


                            Output:
                             SampleChild constructor
Birth                        SampleChild.property1 setter
   construction              Adding child SampleChild4
   con guration
   attachment
   initialization
Life
Death
Con guration and Containers

                    ‣ Containers must not expect their children
                     have to be instantiated when properties
                     are set.
                    <mx:Application ...>
                    	 <local:SampleContainer property1="value!">
                    	 	 <local:SampleChild property1="value!"/>
                    	 </local:SampleContainer>
                    </mx:Application>


                    SampleContainer constructor
Birth
   construction     SampleContainer.property1 setter
   con guration     SampleChild constructor
   attachment       SampleChild.property1 setter
   initialization
Life
Death
Con guration Optimization



                    ‣ To avoid performance bottlenecks, make
                      your setters fast and defer any real work
                      until validation
                    ‣ We’ll talk more about deferment in the
                      validation / invalidation section
Birth
   construction
   con guration
   attachment
   initialization
Life
Death
Attachment


Birth
   construction
   con guration
   attachment
   initialization
Life
Death
What is attachment?



                    ‣ Adding a component to the display list
                     (addChild, addChildAt, MXML declaration)
                    ‣ The component lifecycle is stalled after
                     con guration until attachment occurs.

Birth
   construction
   con guration
   attachment
   initialization
Life
Death
Consider this component:
	   public class A extends UIComponent
	
	
    {
    	    public function A() {
                                          (It traces all of its methods.)
	   	    	    trace( "CONSTRUCTOR" );
	   	    	    super();
	   	    }
	   	
	   	    override protected function createChildren() : void {
	   	    	    trace( "CREATECHILDREN" );
	   	    	    super.createChildren();
	   	    }
	   	
	   	    override protected function measure() : void {
	   	    	    trace( "MEASURE" );
	   	    	    super.measure();
	   	    }
	   	
	   	    override protected function updateDisplayList(width:Number, height:Number) : void {
	   	    	    trace( "UPDATEDISPLAYLIST" );
	   	    	    super.updateDisplayList(width,height);
	   	    }
	   	
	   	    override protected function commitProperties():void {
	   	    	    trace( "COMMITPROPERTIES" );
	   	    	    super.commitProperties();
	   	    }
And this application:
<mx:Application ...>
	 <mx:Script>
	 	 <![CDATA[
	 	 	 override protected function createChildren() : void {
	 	 	 	 super.createChildren();
	 	 	 	 var a : A = new A();
	 	 	 }
	 	 ]]>
	 </mx:Script>
</mx:Application>
                                 Output:     CONSTRUCTOR




‣ Without attachment, the rest of the lifecycle
  doesn’t happen.
But what about this application?
<mx:Application ...>
	   <mx:Script>
	   	    <![CDATA[
	   	    	   override protected function createChildren() : void {
	   	    	   	    super.createChildren();
	   	    	   	    var a : A = new A();

                this.addChild( a );
	   	    	   }
	   	    ]]>
	   </mx:Script>
</mx:Application>                            Output:       CONSTRUCTOR
                                                           CREATECHILDREN
                                                           COMMITPROPERTIES
                                                           MEASURE
                                                           UPDATEDISPLAYLIST


 ‣ Moral of the story: don’t add components to the
   stage until you need them.
Initialization


Birth
   construction
   con guration
   attachment
   initialization
Life
Death
Initialization

                      ‣ 2 phases, 3 events:

                               1.   ‘preInitialize’ dispatched
                     Create    2.   createChildren(); called
                               3.   ‘initialize’ dispatched
                    Validate   4.     rst validation pass occurs
                               5.   ‘creationComplete’ dispatched
Birth
   construction
   con guration
   attachment
   initialization
Life
Death
createChildren()
     ‣   MXML uses the createChildren() method to add
         children to containers
     ‣   Override this method to add children using AS
         •   Follow MXML’s creation strategy: create,
             con gure, attach

                  override protected function createChildren():void
                  {
                    ...
    create          textField = new UITextField();

                      textField.enabled = enabled;

con gure              textField.ignorePadding = true;
                      textField.addEventListener("textFieldStyleChange",
                                    textField_textFieldStyleChangeHandler);
                       ...
                             ...
    attach        }
                       addChild(DisplayObject(textField));
rst validation pass

                    ‣ Invalidation is not part of initialization -
                      only Validation
                    ‣ Validation consists of 3 methods:
                      • commitProperties()
                      • measure()
                      • updateDisplayList()
                    ‣ more on these later
Birth
   construction
   con guration
   attachment
   initialization
Life
Death
Life
They grow up so fast.
Invalidation



Birth
Life
   invalidation
   validation
   interaction
Death
Invalidation / Validation cycle
     ‣ Flex imposes deferred validation on the
       Flash API
        • goal: defer screen updates until all
          properties have been set
     ‣ 3 main method pairs to be aware of:
        • invalidateProperties() ->
          commitProperties()
        • invalidateSize() -> measure()
        • invalidateDisplayList() ->
          updateDisplayList()
Invalidation / Validation theory




      ‣ First, a little theory.
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
Text-book example
Bad:
public function set text(value:String):void
{
    myLabel.text = value;
// Possible Error! during first config phase,
// myLabel might not exist!
}



Good:
private var _text:String = "";
public function set text(value:String):void     override protected function
{                                               commitProperties():void{
    textSet = true;                             {
    _text = value;                                 if(textChanged){
    textChanged = true;                               myLabel.text = _text;
                                                      textChanged = false;
    invalidateProperties();                        }
    invalidateSize();                              super.commitProperties();
    invalidateDisplayList();                    }
}
The Elastic Racetrack revisited




                         image courtesy of Sean Christmann


  Invalidation occurs here
Invalidation methods

                  ‣ invalidateProperties()
                    •  Any property changes
                  ‣ invalidateSize()
                     • Changes to width or height
                  ‣ invalidateDisplayList()
                     • Changes to child component size or
                       position
Birth
Life
   invalidation
   validation
   interaction
Death
Invalidation example 1
<mx:Application>
	 <mx:Script>
	 	 <![CDATA[
	 	 	 import mx.collections.ArrayCollection;
	 	 	
	 	 	 [Bindable]
	 	 	 public var arr : ArrayCollection = new ArrayCollection();
	 	 	
	 	 	 public function onClick() : void {
	 	 	 	 var c : int = 0;
	 	 	 	 while( c++ < 20 ) {
	 	 	 	 	 arr.addItem( c );
	 	 	 	 }
	 	 	 }
	 	 ]]>
	 </mx:Script>
	 <mx:VBox>
	      <mx:Button label="Click me!" click="onClick()"/>
	      <test:BadList id="theList" dataProvider="{arr}"/>
	 </mx:VBox>
</mx:Application>
Invalidation example 2
    public class BadList extends VBox
	    {
	    	 private var _dataProvider : ArrayCollection;
	    	 public function set dataProvider( arr : ArrayCollection ) : void {
	    	 	 this._dataProvider = arr;
	    	 	 arr.addEventListener( CollectionEvent.COLLECTION_CHANGE,
                                 dataProviderChangeHandler );
	    	 }
	    	 private function dataProviderChangeHandler( e : Event ) : void {
	    	 	 this.removeAllChildren();
	    	 	 for each( var n : Number in this._dataProvider ) {
	    	 	 	 var l : Label = new Label();
	    	 	 	 l.text = n.toString();
	    	 	 	 this.addChild( l );
    	      }
	   	   }
	   	   public function BadList() {}
	   }


           Result: dataProviderChangeHandler called 20 times
Invalidation example 3
    public class GoodList extends VBox
	    {
	    	   private var _dataProvider : ArrayCollection;
	    	   private var _dataProviderChanged : Boolean = false;
	    	   public function set dataProvider( arr : ArrayCollection ) : void {
	    	   	   this._dataProvider = arr;
	    	   	   arr.addEventListener( CollectionEvent.COLLECTION_CHANGE,
                                    dataProviderChangeHandler );
	    	   	   this._dataProviderChanged = true;
	    	   	   this.invalidateProperties();
	    	   }
	    	   override protected function commitProperties():void {
	    	   	   super.commitProperties();
	    	   	   if( this._dataProviderChanged ) {
	    	   	   	   this.removeAllChildren();
	    	   	   	   for each( var n : Number in this._dataProvider ) {
	    	   	   	   	   var l : Label = new Label();
	    	   	   	   	   l.text = n.toString();                           Result: commitProperties
	    	   	   	   	   this.addChild( l );
                                                                      called only twice (once
	    	   	   	   }
	    	   	   	   this._dataProviderChanged = false;                   during initialization)
	    	   	   }
	    	   }
	    	   private function dataProviderChangeHandler( e : Event ) : void {
	    	   	   this._dataProviderChanged = true;
	    	   	   this.invalidateProperties();
	    	   }
	    	   public function GoodList() {}
	    }
Validation



Birth
Life
   invalidation
   validation
   interaction
Death
The Elastic Racetrack revisited




              Validation occurs here
Validation

                  ‣ Apply the changes deferred during
                    invalidation
                  ‣ Update all visual aspects of the
                    application in preparation for the render
                    phase
                  ‣ 3 methods:
                     • commitProperties()
                     • measure()
Birth
Life                 • updateDisplayList()
   invalidation
   validation
   interaction
Death
commitProperties()


                  ‣ Ely says: “Calculate and commit the effects
                    of changes to properties and underlying
                    data.”
                  ‣ Invoked rst - immediately before
                    measurement and layout

Birth
Life
   invalidation
   validation
   interaction
Death
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
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
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
measure() cont.




                  ‣ Not reliable - Framework optimizes away
                   any calls to measure it deems
                   “unecessary”


Birth
Life
   invalidation
   validation
   interaction
Death
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
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
Elastic Racetrack cont.

      ‣ User Actions
       • Dispatch invalidation events
       • Interact with any non-validation events
         from this frame (mouse movements,
         timers, etc.)
Elastic Racetrack Cont.

     ‣ Invalidate Action
       • Process all validation calls
     ‣ Render Action
       • Do the heavy lifting - actually draw on
         the screen
The Elastic Racetrack revisited




     Queued Invalidation
              Deferred Validation
                            Render!
Interaction



Birth
Life
   invalidation
   validation
   interaction
Death
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
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
Who can dispatch events?


                  ‣ Subclasses of EventDispatcher
                   •  EventDispatcher inherits directly from
                      Object
                  ‣ Simply call dispatchEvent(event) to re off
                    an event when something happens

Birth
Life
   invalidation
   validation
   interaction
Death
How to tell events apart?



                  ‣ Event class
                    • Different classes allow for customized
                      payloads
                  ‣ “type” eld: a constant



Birth
Life
   invalidation
   validation
   interaction
Death
Common Events


                  ‣ Event.CHANGE
                  ‣ MouseEvent.CLICK
                  ‣ FlexEvent.CREATION_COMPLETE
                  ‣ Event.RESIZE
                  ‣ MouseEvent.ROLL_OUT


Birth
Life
   invalidation
   validation
   interaction
Death
Handling Events



                  ‣ <mx:Button id=”theButton”
                    click=”callThisFunction(event)”/>
                  ‣ theButton.addEventListener( MouseEvent
                    .CLICK, callThisFunction )


Birth
Life
   invalidation
   validation
   interaction
Death
Event Propagation
       ‣   Three phases: Capturing, Targeting, Bubbling



             Application                  Application

           Capturing                          Bubbling
           Phase                              Phase
                              Target
                             Targeting
Birth                        Phase
Life
   invalidation
   validation
   interaction
Death
Event Propagation
          ‣   Three phases: Capturing, Targeting, Bubbling
          <mx:Application 	initialize="onInitialize()">
          <mx:Script>
          	    <![CDATA[
          	    	      public function onInitialize() : void {
          	    	      	    this.addEventListener( MouseEvent.CLICK, clickHandler, true );
          	    	      	    this.addEventListener( MouseEvent.CLICK, clickHandler, false );
          	    	      	    outer.addEventListener( MouseEvent.CLICK, clickHandler, true );
          	    	      	    outer.addEventListener( MouseEvent.CLICK, clickHandler, false );
          	    	      	    inner.addEventListener( MouseEvent.CLICK, clickHandler, true );
          	    	      	    inner.addEventListener( MouseEvent.CLICK, clickHandler, false );
          	    	      	    button.addEventListener( MouseEvent.CLICK, clickHandler, true );
          	    	      	    button.addEventListener( MouseEvent.CLICK, clickHandler, false );
          	    	      }
          	    	
          	    	      public function clickHandler( e : Event ) : void {
          	    	      	    trace("----------------------------------------------------------");
          	    	      	    trace("TARGET: " + e.target.id );
          	    	      	    trace("CURRENT TARGET: " + e.currentTarget.id );
          	    	      	    trace("PHASE: " + ( e.eventPhase == 1 ? "CAPTURE" : ( e.eventPhase == 2 ? "TARGET" : "BUBBLE" ) ) );
          	    	      }
          	    ]]>
          </mx:Script>
              <mx:VBox>
                  <mx:Panel id="outer">
          	         	 <mx:TitleWindow id="inner">
          	         		     <mx:Button id="button"/>
          	         	 </mx:TitleWindow>
Birth     	        </mx:Panel>
              </mx:VBox>
Life      </mx:Application>

   invalidation
          ‣


   validation
   interaction
Death
Event Propagation
                  ----------------------------------------------------------
                  TARGET: button
                  CURRENT TARGET: eventTest
                  PHASE: CAPTURE
                  ----------------------------------------------------------
                  TARGET: button
                  CURRENT TARGET: outer
                  PHASE: CAPTURE
                  ----------------------------------------------------------
                  TARGET: button
                  CURRENT TARGET: inner
                  PHASE: CAPTURE
                  ----------------------------------------------------------
                  TARGET: button
                  CURRENT TARGET: button
                  PHASE: TARGET
                  ----------------------------------------------------------
                  TARGET: button
                  CURRENT TARGET: inner
                  PHASE: BUBBLE
                  ----------------------------------------------------------
                  TARGET: button
                  CURRENT TARGET: outer
                  PHASE: BUBBLE
                  ----------------------------------------------------------
Birth             TARGET: button
                  CURRENT TARGET: eventTest
Life
                  PHASE: BUBBLE
   invalidation
   validation
   interaction
Death
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
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
Dispatching events from custom
   components
        ‣ MXML:
           <mx:Metadata>
               [Event(name="atePizza", type="flash.events.JoshEvent")]
           </mx:Metadata>


        ‣ Actionscript:
           [Event(name="atePizza", type="flash.events.JoshEvent")]
           public class MyComponent extends UIComponent
           {
               ...
           }

Birth
Life
   invalidation
   validation
   interaction
Death
Death
All good things come to an end.
Detachment



Birth
Life
Death
   detachment
   garbage
   collection
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
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
Garbage Collection



Birth
Life
Death
   detachment
   garbage
   collection
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
Conclusion



     ‣ Defer, Defer, DEFER!
     ‣ Use validation methods correctly
     ‣ Remember the elastic racetrack
References
    ‣   Ely Green eld: “Building a Flex Component”
        •   http://www.on ex.org/ACDS/
            BuildingAFlexComponent.pdf


    ‣   Cha c Kazoun, Joey Lott: “Programming Flex 2” by
        O’Reilly
        •   http://oreilly.com/catalog/9780596526894/


    ‣   Colin Moock: “Essential Actionscript 3.0” by O’Reilly
        •   http://oreilly.com/catalog/9780596526948/
            index.html

Weitere ähnliche Inhalte

Andere mochten auch

Accessibility in Flex
Accessibility in FlexAccessibility in Flex
Accessibility in FlexEffectiveUI
 
Drukvoorbereiding
DrukvoorbereidingDrukvoorbereiding
DrukvoorbereidingDries
 
Indian Act
Indian Act Indian Act
Indian Act Taxmann
 
Social Media in a Corporate Context Manchester 2010 - Marc Campman, Webjam
Social Media in a Corporate Context Manchester 2010 -  Marc Campman, WebjamSocial Media in a Corporate Context Manchester 2010 -  Marc Campman, Webjam
Social Media in a Corporate Context Manchester 2010 - Marc Campman, WebjamCommunicate Magazine
 
Conventions and forms new
Conventions and forms newConventions and forms new
Conventions and forms newHanaEllis
 
GST - 24 Things you should know about Draft GST Rules & Forms
GST - 24 Things you should know about Draft GST Rules & FormsGST - 24 Things you should know about Draft GST Rules & Forms
GST - 24 Things you should know about Draft GST Rules & FormsTaxmann
 
Your queries on service tax
Your queries on service taxYour queries on service tax
Your queries on service taxTaxmann
 
Car tuning
Car tuningCar tuning
Car tuningDries
 
Communicate magazine - Marc Cloosterman
Communicate magazine - Marc CloostermanCommunicate magazine - Marc Cloosterman
Communicate magazine - Marc CloostermanCommunicate Magazine
 
Charla AERCO Segovia
Charla AERCO SegoviaCharla AERCO Segovia
Charla AERCO Segoviaivanprado
 
Transform: implementantion, Stuart Youngs
Transform: implementantion, Stuart YoungsTransform: implementantion, Stuart Youngs
Transform: implementantion, Stuart YoungsCommunicate Magazine
 
Transform: Cultural & Language Considerations, Sarah Mrowicki
Transform: Cultural & Language Considerations, Sarah MrowickiTransform: Cultural & Language Considerations, Sarah Mrowicki
Transform: Cultural & Language Considerations, Sarah MrowickiCommunicate Magazine
 
Rome stuff you should know
Rome stuff you should knowRome stuff you should know
Rome stuff you should knowRachel Collishaw
 
Evolution of the annual report - lessons from a first strategic report
Evolution of the annual report - lessons from a first strategic reportEvolution of the annual report - lessons from a first strategic report
Evolution of the annual report - lessons from a first strategic reportCommunicate Magazine
 
Mund te mos te ta them gjithmone
Mund te mos te ta them gjithmoneMund te mos te ta them gjithmone
Mund te mos te ta them gjithmoneeni45654
 
Bonometti_Pratiche di formazione indice e intorduzione
Bonometti_Pratiche di formazione indice e intorduzioneBonometti_Pratiche di formazione indice e intorduzione
Bonometti_Pratiche di formazione indice e intorduzionegueste8fd95
 
Book Exceprts Covers
Book Exceprts CoversBook Exceprts Covers
Book Exceprts Coverscarleenpalmer
 
Test-Driven Development
Test-Driven DevelopmentTest-Driven Development
Test-Driven DevelopmentEffectiveUI
 

Andere mochten auch (20)

Accessibility in Flex
Accessibility in FlexAccessibility in Flex
Accessibility in Flex
 
Drukvoorbereiding
DrukvoorbereidingDrukvoorbereiding
Drukvoorbereiding
 
Indian Act
Indian Act Indian Act
Indian Act
 
Social Media in a Corporate Context Manchester 2010 - Marc Campman, Webjam
Social Media in a Corporate Context Manchester 2010 -  Marc Campman, WebjamSocial Media in a Corporate Context Manchester 2010 -  Marc Campman, Webjam
Social Media in a Corporate Context Manchester 2010 - Marc Campman, Webjam
 
Conventions and forms new
Conventions and forms newConventions and forms new
Conventions and forms new
 
GST - 24 Things you should know about Draft GST Rules & Forms
GST - 24 Things you should know about Draft GST Rules & FormsGST - 24 Things you should know about Draft GST Rules & Forms
GST - 24 Things you should know about Draft GST Rules & Forms
 
Your queries on service tax
Your queries on service taxYour queries on service tax
Your queries on service tax
 
Car tuning
Car tuningCar tuning
Car tuning
 
Communicate magazine - Marc Cloosterman
Communicate magazine - Marc CloostermanCommunicate magazine - Marc Cloosterman
Communicate magazine - Marc Cloosterman
 
Charla AERCO Segovia
Charla AERCO SegoviaCharla AERCO Segovia
Charla AERCO Segovia
 
Transform: implementantion, Stuart Youngs
Transform: implementantion, Stuart YoungsTransform: implementantion, Stuart Youngs
Transform: implementantion, Stuart Youngs
 
Transform: Cultural & Language Considerations, Sarah Mrowicki
Transform: Cultural & Language Considerations, Sarah MrowickiTransform: Cultural & Language Considerations, Sarah Mrowicki
Transform: Cultural & Language Considerations, Sarah Mrowicki
 
Rome stuff you should know
Rome stuff you should knowRome stuff you should know
Rome stuff you should know
 
Evolution of the annual report - lessons from a first strategic report
Evolution of the annual report - lessons from a first strategic reportEvolution of the annual report - lessons from a first strategic report
Evolution of the annual report - lessons from a first strategic report
 
Mund te mos te ta them gjithmone
Mund te mos te ta them gjithmoneMund te mos te ta them gjithmone
Mund te mos te ta them gjithmone
 
Sourcefinance
SourcefinanceSourcefinance
Sourcefinance
 
Roadmap SharePoint
Roadmap SharePointRoadmap SharePoint
Roadmap SharePoint
 
Bonometti_Pratiche di formazione indice e intorduzione
Bonometti_Pratiche di formazione indice e intorduzioneBonometti_Pratiche di formazione indice e intorduzione
Bonometti_Pratiche di formazione indice e intorduzione
 
Book Exceprts Covers
Book Exceprts CoversBook Exceprts Covers
Book Exceprts Covers
 
Test-Driven Development
Test-Driven DevelopmentTest-Driven Development
Test-Driven Development
 

Ähnlich wie Diving Deep with the Flex Component Life Cycle

杜增强-Flex3组件生命周期
杜增强-Flex3组件生命周期杜增强-Flex3组件生命周期
杜增强-Flex3组件生命周期增强 杜
 
Building Components In Flex3
Building Components In Flex3Building Components In Flex3
Building Components In Flex3Tikal Knowledge
 
Flex Building User Interface Components
Flex Building User Interface ComponentsFlex Building User Interface Components
Flex Building User Interface ComponentsAhmad Hamid
 
Flex component lifecycle
Flex component lifecycleFlex component lifecycle
Flex component lifecycleYaniv Uriel
 
Advanced Memory Management on iOS and Android - Mark Probst and Rodrigo Kumpera
Advanced Memory Management on iOS and Android - Mark Probst and Rodrigo KumperaAdvanced Memory Management on iOS and Android - Mark Probst and Rodrigo Kumpera
Advanced Memory Management on iOS and Android - Mark Probst and Rodrigo KumperaXamarin
 
Salesforce lwc development workshops session #6
Salesforce lwc development workshops  session #6Salesforce lwc development workshops  session #6
Salesforce lwc development workshops session #6Rahul Gawale
 
Objective c runtime
Objective c runtimeObjective c runtime
Objective c runtimeInferis
 
Invalidation Routines Pounded Into Your Cranium
Invalidation Routines Pounded Into Your CraniumInvalidation Routines Pounded Into Your Cranium
Invalidation Routines Pounded Into Your Craniumsakrirosenstrom
 
Artdm170 Week5 Intro To Flash
Artdm170 Week5 Intro To FlashArtdm170 Week5 Intro To Flash
Artdm170 Week5 Intro To FlashGilbert Guerrero
 
Coldbox developer training – session 4
Coldbox developer training – session 4Coldbox developer training – session 4
Coldbox developer training – session 4Billie Berzinskas
 
谷歌 Scott-lessons learned in testability
谷歌 Scott-lessons learned in testability谷歌 Scott-lessons learned in testability
谷歌 Scott-lessons learned in testabilitydrewz lin
 
Continuous Integration using Cruise Control
Continuous Integration using Cruise ControlContinuous Integration using Cruise Control
Continuous Integration using Cruise Controlelliando dias
 
The Theory Of The Dom
The Theory Of The DomThe Theory Of The Dom
The Theory Of The Domkaven yan
 
2007 Max Presentation - Creating Custom Flex Components
2007 Max Presentation - Creating Custom Flex Components2007 Max Presentation - Creating Custom Flex Components
2007 Max Presentation - Creating Custom Flex Componentsmichael.labriola
 
Creating and destroying objects
Creating and destroying objectsCreating and destroying objects
Creating and destroying objectsSandeep Chawla
 
ARTDM 170, Week 5: Intro To Flash
ARTDM 170, Week 5: Intro To FlashARTDM 170, Week 5: Intro To Flash
ARTDM 170, Week 5: Intro To FlashGilbert Guerrero
 
Virtual events in C#: something went wrong
Virtual events in C#: something went wrongVirtual events in C#: something went wrong
Virtual events in C#: something went wrongPVS-Studio
 
Oop Constructor Destructors Constructor Overloading lecture 2
Oop Constructor  Destructors Constructor Overloading lecture 2Oop Constructor  Destructors Constructor Overloading lecture 2
Oop Constructor Destructors Constructor Overloading lecture 2Abbas Ajmal
 
Flex4 component lifecycle
Flex4 component lifecycleFlex4 component lifecycle
Flex4 component lifecycleRJ Owen
 

Ähnlich wie Diving Deep with the Flex Component Life Cycle (20)

杜增强-Flex3组件生命周期
杜增强-Flex3组件生命周期杜增强-Flex3组件生命周期
杜增强-Flex3组件生命周期
 
Building Components In Flex3
Building Components In Flex3Building Components In Flex3
Building Components In Flex3
 
Flex Building User Interface Components
Flex Building User Interface ComponentsFlex Building User Interface Components
Flex Building User Interface Components
 
Flex component lifecycle
Flex component lifecycleFlex component lifecycle
Flex component lifecycle
 
Advanced Memory Management on iOS and Android - Mark Probst and Rodrigo Kumpera
Advanced Memory Management on iOS and Android - Mark Probst and Rodrigo KumperaAdvanced Memory Management on iOS and Android - Mark Probst and Rodrigo Kumpera
Advanced Memory Management on iOS and Android - Mark Probst and Rodrigo Kumpera
 
Salesforce lwc development workshops session #6
Salesforce lwc development workshops  session #6Salesforce lwc development workshops  session #6
Salesforce lwc development workshops session #6
 
Objective c runtime
Objective c runtimeObjective c runtime
Objective c runtime
 
Invalidation Routines Pounded Into Your Cranium
Invalidation Routines Pounded Into Your CraniumInvalidation Routines Pounded Into Your Cranium
Invalidation Routines Pounded Into Your Cranium
 
Artdm170 Week5 Intro To Flash
Artdm170 Week5 Intro To FlashArtdm170 Week5 Intro To Flash
Artdm170 Week5 Intro To Flash
 
Coldbox developer training – session 4
Coldbox developer training – session 4Coldbox developer training – session 4
Coldbox developer training – session 4
 
谷歌 Scott-lessons learned in testability
谷歌 Scott-lessons learned in testability谷歌 Scott-lessons learned in testability
谷歌 Scott-lessons learned in testability
 
Continuous Integration using Cruise Control
Continuous Integration using Cruise ControlContinuous Integration using Cruise Control
Continuous Integration using Cruise Control
 
The Theory Of The Dom
The Theory Of The DomThe Theory Of The Dom
The Theory Of The Dom
 
2007 Max Presentation - Creating Custom Flex Components
2007 Max Presentation - Creating Custom Flex Components2007 Max Presentation - Creating Custom Flex Components
2007 Max Presentation - Creating Custom Flex Components
 
Creating and destroying objects
Creating and destroying objectsCreating and destroying objects
Creating and destroying objects
 
ARTDM 170, Week 5: Intro To Flash
ARTDM 170, Week 5: Intro To FlashARTDM 170, Week 5: Intro To Flash
ARTDM 170, Week 5: Intro To Flash
 
Frontend training
Frontend trainingFrontend training
Frontend training
 
Virtual events in C#: something went wrong
Virtual events in C#: something went wrongVirtual events in C#: something went wrong
Virtual events in C#: something went wrong
 
Oop Constructor Destructors Constructor Overloading lecture 2
Oop Constructor  Destructors Constructor Overloading lecture 2Oop Constructor  Destructors Constructor Overloading lecture 2
Oop Constructor Destructors Constructor Overloading lecture 2
 
Flex4 component lifecycle
Flex4 component lifecycleFlex4 component lifecycle
Flex4 component lifecycle
 

Mehr von EffectiveUI

Design essentials For Executives
Design essentials For ExecutivesDesign essentials For Executives
Design essentials For ExecutivesEffectiveUI
 
Designing an App: From Idea to Market
Designing an App: From Idea to MarketDesigning an App: From Idea to Market
Designing an App: From Idea to MarketEffectiveUI
 
Flash and Flex in an HTML5 / App Store World
Flash and Flex in an HTML5 / App Store WorldFlash and Flex in an HTML5 / App Store World
Flash and Flex in an HTML5 / App Store WorldEffectiveUI
 
Design Essentials for Developers 08.31.11
Design Essentials for Developers 08.31.11Design Essentials for Developers 08.31.11
Design Essentials for Developers 08.31.11EffectiveUI
 
Flex4 Component Lifecycle
Flex4 Component LifecycleFlex4 Component Lifecycle
Flex4 Component LifecycleEffectiveUI
 
The Art of Interaction
The Art of InteractionThe Art of Interaction
The Art of InteractionEffectiveUI
 
Design Essentials for Developers
Design Essentials for DevelopersDesign Essentials for Developers
Design Essentials for DevelopersEffectiveUI
 
Git for the Android Developer
Git for the Android DeveloperGit for the Android Developer
Git for the Android DeveloperEffectiveUI
 
Microsoft Kinect and Molehill
Microsoft Kinect and MolehillMicrosoft Kinect and Molehill
Microsoft Kinect and MolehillEffectiveUI
 
Reasons for Flash: Flash Development in an HTML5 and App Store World
Reasons for Flash: Flash Development in an HTML5 and App Store WorldReasons for Flash: Flash Development in an HTML5 and App Store World
Reasons for Flash: Flash Development in an HTML5 and App Store WorldEffectiveUI
 
Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...
Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...
Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...EffectiveUI
 
Design Essentials for Developers
Design Essentials for DevelopersDesign Essentials for Developers
Design Essentials for DevelopersEffectiveUI
 
Your Mom Has an iPad
Your Mom Has an iPadYour Mom Has an iPad
Your Mom Has an iPadEffectiveUI
 
Human-Centered Design and the Intersection of the Physical and Digital Worlds
Human-Centered Design and the Intersection of the Physical and Digital WorldsHuman-Centered Design and the Intersection of the Physical and Digital Worlds
Human-Centered Design and the Intersection of the Physical and Digital WorldsEffectiveUI
 
From the Trenches: Building the Accessible Web
From the Trenches: Building the Accessible WebFrom the Trenches: Building the Accessible Web
From the Trenches: Building the Accessible WebEffectiveUI
 
An Opinionated Introduction to Mate
An Opinionated Introduction to MateAn Opinionated Introduction to Mate
An Opinionated Introduction to MateEffectiveUI
 
Flex 360 Rules Engine
Flex 360 Rules EngineFlex 360 Rules Engine
Flex 360 Rules EngineEffectiveUI
 
Flex 4 Deep Dive
Flex 4 Deep DiveFlex 4 Deep Dive
Flex 4 Deep DiveEffectiveUI
 
The ROI of User Experience:
The ROI of User Experience: The ROI of User Experience:
The ROI of User Experience: EffectiveUI
 

Mehr von EffectiveUI (20)

Design essentials For Executives
Design essentials For ExecutivesDesign essentials For Executives
Design essentials For Executives
 
Designing an App: From Idea to Market
Designing an App: From Idea to MarketDesigning an App: From Idea to Market
Designing an App: From Idea to Market
 
Flash and Flex in an HTML5 / App Store World
Flash and Flex in an HTML5 / App Store WorldFlash and Flex in an HTML5 / App Store World
Flash and Flex in an HTML5 / App Store World
 
Design Essentials for Developers 08.31.11
Design Essentials for Developers 08.31.11Design Essentials for Developers 08.31.11
Design Essentials for Developers 08.31.11
 
Flex4 Component Lifecycle
Flex4 Component LifecycleFlex4 Component Lifecycle
Flex4 Component Lifecycle
 
The Art of Interaction
The Art of InteractionThe Art of Interaction
The Art of Interaction
 
Design Essentials for Developers
Design Essentials for DevelopersDesign Essentials for Developers
Design Essentials for Developers
 
Rails on HBase
Rails on HBaseRails on HBase
Rails on HBase
 
Git for the Android Developer
Git for the Android DeveloperGit for the Android Developer
Git for the Android Developer
 
Microsoft Kinect and Molehill
Microsoft Kinect and MolehillMicrosoft Kinect and Molehill
Microsoft Kinect and Molehill
 
Reasons for Flash: Flash Development in an HTML5 and App Store World
Reasons for Flash: Flash Development in an HTML5 and App Store WorldReasons for Flash: Flash Development in an HTML5 and App Store World
Reasons for Flash: Flash Development in an HTML5 and App Store World
 
Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...
Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...
Discombobulation, Fire-Breathing Dragons and Wet Noodles: Creating Productive...
 
Design Essentials for Developers
Design Essentials for DevelopersDesign Essentials for Developers
Design Essentials for Developers
 
Your Mom Has an iPad
Your Mom Has an iPadYour Mom Has an iPad
Your Mom Has an iPad
 
Human-Centered Design and the Intersection of the Physical and Digital Worlds
Human-Centered Design and the Intersection of the Physical and Digital WorldsHuman-Centered Design and the Intersection of the Physical and Digital Worlds
Human-Centered Design and the Intersection of the Physical and Digital Worlds
 
From the Trenches: Building the Accessible Web
From the Trenches: Building the Accessible WebFrom the Trenches: Building the Accessible Web
From the Trenches: Building the Accessible Web
 
An Opinionated Introduction to Mate
An Opinionated Introduction to MateAn Opinionated Introduction to Mate
An Opinionated Introduction to Mate
 
Flex 360 Rules Engine
Flex 360 Rules EngineFlex 360 Rules Engine
Flex 360 Rules Engine
 
Flex 4 Deep Dive
Flex 4 Deep DiveFlex 4 Deep Dive
Flex 4 Deep Dive
 
The ROI of User Experience:
The ROI of User Experience: The ROI of User Experience:
The ROI of User Experience:
 

Kürzlich hochgeladen

Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 

Kürzlich hochgeladen (20)

Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 

Diving Deep with the Flex Component Life Cycle

  • 1. Diving Deep with the Flex Component Lifecycle Joshua Jamison EffectiveUI www.effectiveui.com January 30, 2009
  • 2. Who am I? ‣ Joshua Jamison • Software Architect @ EffectiveUI
  • 3. Who are you (hopefully)? ‣ Beginner to intermediate level developers ‣ Anyone who doesn’t currently understand the lifecycle ‣ Anyone who wants a good review of the basics
  • 4. What’s this about, anyway? ‣ Flex component lifecycle ‣ Flex frame cycle (“elastic racetrack”)
  • 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
  • 7. A frame in AS3 image courtesy of Sean Christmann
  • 8. Phases of the Lifecycle ‣ 3 Main Phases: ‣ BIRTH: • construction, con guration, attachment, initialization ‣ LIFE: • invalidation, validation, interaction ‣ DEATH: • detachment, garbage collection
  • 10. Construction Birth construction con guration attachment initialization Life Death
  • 11. What is a constructor? ‣ A function called to instantiate (create in memory) a new instance of a class Birth construction con guration attachment initialization Life Death
  • 12. How is a constructor invoked? Actionscript: var theLabel : Label = new Label(); MXML: <mx:Label id="theLabel"/> Birth construction con guration attachment initialization Life Death
  • 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
  • 18. Con guration 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
  • 20. Hooray: Sample code! <mx:Application ...> ... <local:SampleChild property1="value!"/> </mx:Application> Output: SampleChild constructor Birth SampleChild.property1 setter construction Adding child SampleChild4 con guration attachment initialization Life Death
  • 21. Con guration and Containers ‣ Containers must not expect their children have to be instantiated when properties are set. <mx:Application ...> <local:SampleContainer property1="value!"> <local:SampleChild property1="value!"/> </local:SampleContainer> </mx:Application> SampleContainer constructor Birth construction SampleContainer.property1 setter con guration SampleChild constructor attachment SampleChild.property1 setter initialization Life Death
  • 22. Con guration Optimization ‣ To avoid performance bottlenecks, make your setters fast and defer any real work until validation ‣ We’ll talk more about deferment in the validation / invalidation section Birth construction con guration attachment initialization Life Death
  • 23. Attachment Birth construction con guration attachment initialization Life Death
  • 24. What is attachment? ‣ Adding a component to the display list (addChild, addChildAt, MXML declaration) ‣ The component lifecycle is stalled after con guration until attachment occurs. Birth construction con guration attachment initialization Life Death
  • 25. Consider this component: public class A extends UIComponent { public function A() { (It traces all of its methods.) trace( "CONSTRUCTOR" ); super(); } override protected function createChildren() : void { trace( "CREATECHILDREN" ); super.createChildren(); } override protected function measure() : void { trace( "MEASURE" ); super.measure(); } override protected function updateDisplayList(width:Number, height:Number) : void { trace( "UPDATEDISPLAYLIST" ); super.updateDisplayList(width,height); } override protected function commitProperties():void { trace( "COMMITPROPERTIES" ); super.commitProperties(); }
  • 26. And this application: <mx:Application ...> <mx:Script> <![CDATA[ override protected function createChildren() : void { super.createChildren(); var a : A = new A(); } ]]> </mx:Script> </mx:Application> Output: CONSTRUCTOR ‣ Without attachment, the rest of the lifecycle doesn’t happen.
  • 27. But what about this application? <mx:Application ...> <mx:Script> <![CDATA[ override protected function createChildren() : void { super.createChildren(); var a : A = new A(); this.addChild( a ); } ]]> </mx:Script> </mx:Application> Output: CONSTRUCTOR CREATECHILDREN COMMITPROPERTIES MEASURE UPDATEDISPLAYLIST ‣ Moral of the story: don’t add components to the stage until you need them.
  • 28. Initialization Birth construction con guration attachment initialization Life Death
  • 29. Initialization ‣ 2 phases, 3 events: 1. ‘preInitialize’ dispatched Create 2. createChildren(); called 3. ‘initialize’ dispatched Validate 4. rst validation pass occurs 5. ‘creationComplete’ dispatched Birth construction con guration attachment initialization Life Death
  • 30. createChildren() ‣ MXML uses the createChildren() method to add children to containers ‣ Override this method to add children using AS • Follow MXML’s creation strategy: create, con gure, attach override protected function createChildren():void { ... create textField = new UITextField(); textField.enabled = enabled; con gure textField.ignorePadding = true; textField.addEventListener("textFieldStyleChange", textField_textFieldStyleChangeHandler); ... ... attach } addChild(DisplayObject(textField));
  • 31. rst validation pass ‣ Invalidation is not part of initialization - only Validation ‣ Validation consists of 3 methods: • commitProperties() • measure() • updateDisplayList() ‣ more on these later Birth construction con guration attachment initialization Life Death
  • 32. Life They grow up so fast.
  • 33. Invalidation Birth Life invalidation validation interaction Death
  • 34. Invalidation / Validation cycle ‣ Flex imposes deferred validation on the Flash API • goal: defer screen updates until all properties have been set ‣ 3 main method pairs to be aware of: • invalidateProperties() -> commitProperties() • invalidateSize() -> measure() • invalidateDisplayList() -> updateDisplayList()
  • 35. Invalidation / Validation theory ‣ First, a little theory.
  • 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
  • 37. Text-book example Bad: public function set text(value:String):void { myLabel.text = value; // Possible Error! during first config phase, // myLabel might not exist! } Good: private var _text:String = ""; public function set text(value:String):void override protected function { commitProperties():void{ textSet = true; { _text = value; if(textChanged){ textChanged = true; myLabel.text = _text; textChanged = false; invalidateProperties(); } invalidateSize(); super.commitProperties(); invalidateDisplayList(); } }
  • 38. The Elastic Racetrack revisited image courtesy of Sean Christmann Invalidation occurs here
  • 39. Invalidation methods ‣ invalidateProperties() • Any property changes ‣ invalidateSize() • Changes to width or height ‣ invalidateDisplayList() • Changes to child component size or position Birth Life invalidation validation interaction Death
  • 40. Invalidation example 1 <mx:Application> <mx:Script> <![CDATA[ import mx.collections.ArrayCollection; [Bindable] public var arr : ArrayCollection = new ArrayCollection(); public function onClick() : void { var c : int = 0; while( c++ < 20 ) { arr.addItem( c ); } } ]]> </mx:Script> <mx:VBox> <mx:Button label="Click me!" click="onClick()"/> <test:BadList id="theList" dataProvider="{arr}"/> </mx:VBox> </mx:Application>
  • 41. Invalidation example 2 public class BadList extends VBox { private var _dataProvider : ArrayCollection; public function set dataProvider( arr : ArrayCollection ) : void { this._dataProvider = arr; arr.addEventListener( CollectionEvent.COLLECTION_CHANGE, dataProviderChangeHandler ); } private function dataProviderChangeHandler( e : Event ) : void { this.removeAllChildren(); for each( var n : Number in this._dataProvider ) { var l : Label = new Label(); l.text = n.toString(); this.addChild( l ); } } public function BadList() {} } Result: dataProviderChangeHandler called 20 times
  • 42. Invalidation example 3 public class GoodList extends VBox { private var _dataProvider : ArrayCollection; private var _dataProviderChanged : Boolean = false; public function set dataProvider( arr : ArrayCollection ) : void { this._dataProvider = arr; arr.addEventListener( CollectionEvent.COLLECTION_CHANGE, dataProviderChangeHandler ); this._dataProviderChanged = true; this.invalidateProperties(); } override protected function commitProperties():void { super.commitProperties(); if( this._dataProviderChanged ) { this.removeAllChildren(); for each( var n : Number in this._dataProvider ) { var l : Label = new Label(); l.text = n.toString(); Result: commitProperties this.addChild( l ); called only twice (once } this._dataProviderChanged = false; during initialization) } } private function dataProviderChangeHandler( e : Event ) : void { this._dataProviderChanged = true; this.invalidateProperties(); } public function GoodList() {} }
  • 43. Validation Birth Life invalidation validation interaction Death
  • 44. The Elastic Racetrack revisited Validation occurs here
  • 45. Validation ‣ Apply the changes deferred during invalidation ‣ Update all visual aspects of the application in preparation for the render phase ‣ 3 methods: • commitProperties() • measure() Birth Life • updateDisplayList() invalidation validation interaction Death
  • 46. commitProperties() ‣ Ely says: “Calculate and commit the effects of changes to properties and underlying data.” ‣ Invoked rst - immediately before measurement and layout Birth Life invalidation validation interaction Death
  • 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
  • 50. measure() cont. ‣ Not reliable - Framework optimizes away any calls to measure it deems “unecessary” Birth Life invalidation 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
  • 53. Elastic Racetrack cont. ‣ User Actions • Dispatch invalidation events • Interact with any non-validation events from this frame (mouse movements, timers, etc.)
  • 54. Elastic Racetrack Cont. ‣ Invalidate Action • Process all validation calls ‣ Render Action • Do the heavy lifting - actually draw on the screen
  • 55. The Elastic Racetrack revisited Queued Invalidation Deferred Validation Render!
  • 56. Interaction 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
  • 59. Who can dispatch events? ‣ Subclasses of EventDispatcher • EventDispatcher inherits directly from Object ‣ Simply call dispatchEvent(event) to re off an event when something happens Birth Life invalidation validation interaction Death
  • 60. How to tell events apart? ‣ Event class • Different classes allow for customized payloads ‣ “type” eld: a constant Birth Life invalidation validation interaction Death
  • 61. Common Events ‣ Event.CHANGE ‣ MouseEvent.CLICK ‣ FlexEvent.CREATION_COMPLETE ‣ Event.RESIZE ‣ MouseEvent.ROLL_OUT Birth Life invalidation validation interaction Death
  • 62. Handling Events ‣ <mx:Button id=”theButton” click=”callThisFunction(event)”/> ‣ theButton.addEventListener( MouseEvent .CLICK, callThisFunction ) Birth Life invalidation validation interaction Death
  • 63. Event Propagation ‣ Three phases: Capturing, Targeting, Bubbling Application Application Capturing Bubbling Phase Phase Target Targeting Birth Phase Life invalidation validation interaction Death
  • 64. Event Propagation ‣ Three phases: Capturing, Targeting, Bubbling <mx:Application initialize="onInitialize()"> <mx:Script> <![CDATA[ public function onInitialize() : void { this.addEventListener( MouseEvent.CLICK, clickHandler, true ); this.addEventListener( MouseEvent.CLICK, clickHandler, false ); outer.addEventListener( MouseEvent.CLICK, clickHandler, true ); outer.addEventListener( MouseEvent.CLICK, clickHandler, false ); inner.addEventListener( MouseEvent.CLICK, clickHandler, true ); inner.addEventListener( MouseEvent.CLICK, clickHandler, false ); button.addEventListener( MouseEvent.CLICK, clickHandler, true ); button.addEventListener( MouseEvent.CLICK, clickHandler, false ); } public function clickHandler( e : Event ) : void { trace("----------------------------------------------------------"); trace("TARGET: " + e.target.id ); trace("CURRENT TARGET: " + e.currentTarget.id ); trace("PHASE: " + ( e.eventPhase == 1 ? "CAPTURE" : ( e.eventPhase == 2 ? "TARGET" : "BUBBLE" ) ) ); } ]]> </mx:Script> <mx:VBox> <mx:Panel id="outer"> <mx:TitleWindow id="inner"> <mx:Button id="button"/> </mx:TitleWindow> Birth </mx:Panel> </mx:VBox> Life </mx:Application> invalidation ‣ validation interaction Death
  • 65. Event Propagation ---------------------------------------------------------- TARGET: button CURRENT TARGET: eventTest PHASE: CAPTURE ---------------------------------------------------------- TARGET: button CURRENT TARGET: outer PHASE: CAPTURE ---------------------------------------------------------- TARGET: button CURRENT TARGET: inner PHASE: CAPTURE ---------------------------------------------------------- TARGET: button CURRENT TARGET: button PHASE: TARGET ---------------------------------------------------------- TARGET: button CURRENT TARGET: inner PHASE: BUBBLE ---------------------------------------------------------- TARGET: button CURRENT TARGET: outer PHASE: BUBBLE ---------------------------------------------------------- Birth TARGET: button CURRENT TARGET: eventTest Life PHASE: BUBBLE 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
  • 68. Dispatching events from custom components ‣ MXML: <mx:Metadata> [Event(name="atePizza", type="flash.events.JoshEvent")] </mx:Metadata> ‣ Actionscript: [Event(name="atePizza", type="flash.events.JoshEvent")] public class MyComponent extends UIComponent { ... } Birth Life invalidation validation interaction Death
  • 69. Death All good things come to an end.
  • 70. Detachment Birth Life Death detachment garbage collection
  • 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
  • 73. Garbage Collection 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
  • 75. Conclusion ‣ Defer, Defer, DEFER! ‣ Use validation methods correctly ‣ Remember the elastic racetrack
  • 76. References ‣ Ely Green eld: “Building a Flex Component” • http://www.on ex.org/ACDS/ BuildingAFlexComponent.pdf ‣ Cha c Kazoun, Joey Lott: “Programming Flex 2” by O’Reilly • http://oreilly.com/catalog/9780596526894/ ‣ Colin Moock: “Essential Actionscript 3.0” by O’Reilly • http://oreilly.com/catalog/9780596526948/ index.html