Flex3 Deep Dive Final

A Deep Dive into the Flex 3 Framework

Brad Umbaugh

RJ Owen

EffectiveUI

November 18, 2008

Introductions

Who are we?

Brad

Senior Developer at EffectiveUI, builds lots of cool stuff, looks a little like John Stamos.

RJ

Senior Developer at EffectiveUI, Adobe Community Expert, falls asleep when he drinks wine

Who are you?

Assumptions:

You know some Flex

You want to know more Flex

You know how to get things done with Flex, but not how to make the most of the Flex Framework

What will we talk about today?

Several topics that help you maximize Flex’s power (grr!!)

Things many beginner - intermediate developers don’t know a lot about

Data Binding

Style manager

Collections

System Manager

For each of these, we’ll discuss:

What it is

How it affects you

Best ways to use it

Common mistakes to avoid

It’ll start simple, and get deeper as we go

Roll-my-own solution

I have a VO that contains some text I need to display on the screen

public class BoringVO1 {

public var _text : String;

}

®

How will I know when the text field on this object changes? I’ll have it dispatch events.

[Event(name=”textChanged”), type=”flash.events.Event”]

public class BoringVO1 extends EventDispatcher {

private var _text : String;

public function set text( value : String ) : void {

_text = value;

this.dispatchEvent( new Event(“textChanged”) );

}

}

®

In the view, I’ll listen for those events:

public function setMyText() {

theLabel.text = value;

}

<mx:Label id=”theLabel”/>

private var _vo : BoringVO1;

public function set vo( value : BoringVO1 ) : void {

_vo = value;

_vo.addEventListener( “textChanged”, this.setMyText )

}

®

Flex’s solution: data binding

Data binding is a contract between two objects: one promises to dispatch events when its data changes, and another promises to listen to those changes and update itself

Got this definition from Michael Labriola’s fantastic data binding talk at 360|Flex San Jose, “Diving in the Data Binding Waters”

Contrary to popular belief, it isn’t magic: it’s events!

Flex’s solution: data binding

Mark the object and its property as [Bindable], use curly braces, and away you go.

public class BoringVO1 {

[Bindable]

public var text : String;

}

The VO! The app! ®

The Basic Idea

A property of a component changes

The property’s component fires off an event indicating that the property changed

Other components listen for this event, recognize that a needed value has changed, and update themselves with the new value

Bindings also fire once on initialization, so that initial values are set correctly

MXML Example (with curly braces), binding to a property

To bind to a property, simply put a reference to the property in curly braces:

<mx:Label text=”{anObject.text}”/>

The referenced data must be marked as bindable: give it [Bindable] metadata

If it isn’t marked as [Bindable], you’ll get a warning from the compiler...

“Data binding will not be able to detect assignments...”

...and the binding won’t work.

Metadata

What is it?

Metadata is information that tells the compiler how components are used in a Flex application.

Various kinds: [ArrayElementType], [DefaultProperty], [Deprecated], [Effect], [Embed]...

[Bindable] metadata tells the compiler to generate code to dispatch events when the property or properties marked [Bindable] are changed, so that other objects binding to that data will update accordingly.

Why is it needed?

Remember all of the event dispatching and listening from the roll-my-own example?

The [Bindable] metadata tells the compiler to dispatch all of those events when objects or their properties change.

Metadata

Where should [Bindable] metadata be placed?

Before a public class definition

Makes all public properties, public getters/setters available as binding sources

Before a public, protected, or private property defined as a variable

Makes that property available as a data binding source

Before a public, protected, or private property defined as a getter/setter

Makes that property available as a data binding source

Components declared in MXML are automatically set as [Bindable] in the compiler-generated Actionscript, as long as they have an id set

Example: DataBinding4.mxml / DataBinding4-interface.as

What is the syntax?

[Bindable] or [Bindable(event=“eventTypeToWhichInterestedComponentsShouldRespond”)]

If no event type is given, by default an event named “propertyChange”, of type PropertyChangeEvent is dispatched

Metadata

Why use a custom event type?

It’s more efficient than using the default PropertyChangeEvent

More on this later

Who dispatches the custom event?

When no custom event type is specified:

Default PropertyChangeEvent is dispatched automatically

Example: DefaultEventFiring.mxml

When a custom event type is specified:

No PropertyChangeEvents are dispatched

Custom event types are not dispatched automatically

Must dispatch custom events explicitly

Example: CustomEventFiring2.mxml

MXML Example (with curly braces), binding to a function

Functions can be used as a source for data binding

Must be marked with appropriate metadata: [Bindable(event=”eventType”)]

When do bindings to functions execute?

Whenever the event type listed in the [Bindable(event=”eventType”)] metadata is dispatched

Example: DataBinding6.mxml

Whenever one of the bindable arguments passed in to the function changes

Code automatically generated to execute the binding whenever one of the function’s passed-in bindable arguments changes

Compiler will throw a warning when non-bindable arguments are passed in to the argument list of a bound function (and the binding won’t work, either)

On initialization

MXML Example (with curly braces), binding to XML data

Can bind directly to XML data

XML does not dispatch change events when nodes are edited, so views may not update correctly

XMLListCollection is the class of choice to use as an XML data provider

Provides sorting and filtering methods

Ensures views get updated when XML nodes are edited

MXML Example: using <Binding> tag

The MXML <Binding> tag accomplishes the same thing as curly braces

Allows you to bind multiple sources to a single destination

Can place a concatenated Actionscript expression in curly braces in the source property of a <Binding> tag

Example: BindingTag.mxml

What does the generated code buy you?

Brevity

Lots of error handling

Binding to expressions

Compiler generates code to evaluate the expression placed in curly braces when particular events are fired off; makes it very easy to bind to complex expressions

<mx:Label text=”{a.toString() + b.toString() + “: “ + (c/d).toString}/>

Chains

Binding to property chains happens easily, too:

<mx:Label text=”{this.childA.propertyB.childC.widgetD.text}”/>

When childA, propertyB, childC, or widgetD changes, the label’s text updates appropriately

All of the event listeners needed to make this happen are created for you in the generated code

All of the properties in the chain must be [Bindable] in order for this to work correctly

Binding in Actionscript: bindProperty() and bindSetter()

Bindings can be created in Actionscript code, too

Use mx.binding.utils.BindingUtils

Two important static methods on the BindingUtils class

bindProperty() sets a destination property when a source property or property chain changes

Takes a destination object, a destination property, a source object, and a source property chain (remember to make all elements in the source property chain [Bindable])

You can use bindProperty() to set a property that has a setter

bindSetter() calls a handler function() when a source property or property chain changes

Takes a handler function, a source object, and a source property chain

Since handler functions fire when bindSetter is first called; be sure to check for nulls

Handler function receives, as a parameter, the new value of the source’s property chain

Both of these functions return a ChangeWatcher object; use this to manipulate the binding after it has been created (change handler function, change objects, etc)

Common problem: performance in Cairngorm

Too many bindable fields on the model doesn’t perform well!

Why?

Every time one of the properties on the model changes, the model dispatches a PropertyChangeEvent

Any component binding to any property on the model listen for PropertyChangeEvents dispatched from the model

Examines the event to see which property the PropertyChangeEvent is for; disregards if not relevant

If the model has a lot of fields, this is a huge amount of unnecessary work

Solution? Custom event types

Listening components now only receive the particular event type dispatched for the property in question

Common problem: two-way binding

Problem: two fields should update each other

Simple solution: Create two bindings, one in each direction.

Flex makes sure that an infinite loop won’t occur

MXML solution: TwoWayMXML.mxml

Actionscript solution: TwoWayActionscript.mxml

There’s a shortcut for this coming in Gumbo (Flex 4)...

Curly braces

<mx:TextInput id=”firstInput”/>

<mx:TextInput id=”secondInput” text=”@{firstInput.text}”/>

Binding tags

<mx:Binding twoWay=”true” ...

Check out the Gumbo spec:

http://opensource.adobe.com/wiki/display/flexsdk/Two-way+Data+Binding

Common problem: making whole objects [Bindable] instead of individual properties

Imagine a complex graph, with thousands of data points

If each point on that graph is an object (VO), any time any point on the object changes it dispatches a property change event.

This can get incredibly expensive really fast when there are lots of objects sitting around in memory.

Whenever possible, make single properties [Bindable] instead of entire objects.

StyleManager: Styling 101

“Styles” differ from “Properties” in the way they are set, maintained, and accessed in your application

Ways to set styles:

In MXML, they look just like properties:

<mx:Label text=" woot! WTF FTW! " color=" 0x00ff00 " width=" 100 " />

In Actionscript, they must be set through the style manager:

var label : Label = new Label();

label.text = "woot! WTF FTW!" ;

label.setStyle( "color" , "0x00ff00" );

Why is it more complex in ActionScript?

Styles are inheritable

Styles must propagate to their children, and their children’s children, and sometimes their children’s children, forever and ever.

Styles are like genes!

This task requires some management

The flex team built a class to do just that, and creatively named it the Style Manager.

The StyleManager serves as the storehouse for all of this information and makes it available to other components.

Every time a style is set, the framework has to keep track of:

Any parent styles this over-rides

Any children who are affected

Flex adds/removes styles through proto chaining

Style properties are stored in the proto chains - not as properties on the objects themselves

proto chains are outside of the scope of our discussion, but it’s a really interesting topic to learn more about.

Style Precedence

Global, Type, Class, Attribute

*Image courtesy Juan Sanchez and Andy McIntosh

®

Adding styles to components in AS3

To add styles to individual components, use UIComponent.getStyle and setStyle

getStyle is cheap - it just reads the style information

setStyle is expensive - it has to traverse the entire style tree and re-calculate inheritance.

These methods inherently make use of the StyleManager

These should satisfy your styling needs on a component level

Using StyleManager to manage Assets

You can embed assets through the StyleManager

Advantages:

Avoid cluttering your component code with Embed statements

Keep all external resource paths in a single place

Manage resources that might be used in more than one part of your app

.icons {

wrenchIcon : Embed ( 'images/wrench.png' );

searchIcon : Embed ( 'images/search.png' );

loginIcon : Embed ( 'images/login.png' );

}

<mx:Button

icon=" { StyleManager.getStyleDeclaration( '.icons' ).getStyle( 'wrenchIcon' ) } "

label=" Customize "

/>

Using the StyleManager

Other things you can do with the StyleManager:

Make changes to existing styles

Useful for programmatically re-themeing at runtime for a configurator

StyleManager.getStyleDeclaration(selector);

StyleManager.setStyleDeclaration(selector, CSSSelector, update);

Clear existing styles

StyleManager.clearStyleDeclaration(selector, update)

Define whether your styles influence other components

StyleManager.registerParentSizeInvalidatingStyle(styleName:String)

StyleManager.registerParentDisplayListInvalidatingStyle(styleName)

Register aliases for color names

“ blue” instead of 0x0000ff

StyleManager.registerColorName(colorName, colorValue);

Load styles from a swf at runtime

StyleManager.loadStyleDeclarations(...);

Load style declarations at runtime

Uses different CSS files for the different themes

Load the style declarations from a pre-compiled swf

The core of the functionality:

private function changeCSS( panelTitle:String, name:String ): void {

StyleManager.loadStyleDeclarations( name, true );

}

Example: clearing and restoring styles

Same example as before, but a few new buttons / handlers:

Copyright 2008 Adobe Systems Incorporated. All rights reserved. public function unloadRed(): void { StyleManager.unloadStyleDeclarations( 'Red.swf' ); } // Code to restore the default 'Halo' button public function restoreDefaults(): void { StyleManager.setStyleDeclaration( 'Button' , defaultButtonStyle, true ); } private var defaultButtonStyle : CSSStyleDeclaration; public function onComplete(): void { defaultButtonStyle = StyleManager.getStyleDeclaration( 'Button' ); } ... <mx:Button label=" Go Red! " click="loadRed()" /> <mx:Button label=" Go Blue! " click="loadBlue()" /> <mx:Button label=" Clear " click="clearStyles()" /> <mx:Button label=" Restore " click="restoreDefaults()" /> <mx:Button label=" Unload Red " click="unloadRed()" /> ®

More info?

Creating Visual Experiences with Flex 3.0 , by Juan Sanchez and Andy McIntosh

Still valid in Flex 4.0!

What is a collection?

Data comes in many formats

Objects

Arrays

XML

There are many different kinds of view components

Crossing all of the view components with all of the different types of data representations would yield an unmanageable number of classes

Need a common way to use any data as the source for any view component

This is where mx.collections.* shines

Why do we need collections?

Collections:

Abstract the format of the data from the display component

Ensure components are updated when data changes

Provide consistent operations to use on data

Provide sorted views of data

Provide filtered views

(Reasons taken from the online flex documentation at www.adobe.com )

So, what are collections really?

Classes that implement IList, ICollectionView

IList is an interface that contains that make it easy to work with linear data

ICollectionView is an interface that makes it easy to work with hierarchical data

ArrayCollection & XMLListCollection are the main ones you’ll use

These actually extend ListCollectionView, which implements IList and ICollectionView

IList

Interface for working with linear data

Interesting methods:

addItem

addItemAt

getItemAt

getItemIndex

removeAll

removeItemAt

setItemAt

ICollectionView

Interface for sorting, filtering, and interacting with linear and hierarchical data

Interesting properties

sort

filterFunction

Interesting methods

contains

createCursor

ListCollectionView

Implements IList

Implements ICollectionView

Consequently, components extending ListCollectionView can be used anywhere an IList or an ICollectionView is expected

Is the base class for ArrayCollecton, XMListCollection

ArrayCollection, XMLListCollection

The two classes in the Flex framework that inherit from ListCollectionView

ArrayCollection

Uses an array as its data source

Good for linear data

XMLListCollection

Uses an XMLList as its data source

XMLList is a list of one or more XML objects

Good for hierarchical data

Where are collections useful?

Various classes can all use collection objects as their data source; these are called “data provider components”:

ButtonBar

ColorPicker

ComboBox

DataGrid

DateField

HorizontalList

LinkBar

List

Menu

MenuBar

PopUpMenuButton

Tree

etc.

Review: why do we need collections?

Collections:

Abstract the format of the data from the display component

Ensure components are updated when data changes

Provide consistent operations to use on data

Provide sorted views of data

Provide filtered views

1. Abstract the data format

The <mx:TileList> can accept many different types of data sources, including an ArrayCollection and an XMLListCollection

The component can swap between different collections without a problem

Example: AbstractDataFormat.mxml

2. Update views when data changes

One of the main reasons to use collections is so that when the data contained by the collection changes, views update accordingly

Collections fire off CollectionChange events when their items change; views listen for these events and refresh themselves accordingly

When passing in non-collection objects as data providers, you may not see the view update immediately

Flex wraps the passed in “raw” objects (e.g., Array or XML) in collection objects; this lets you use your raw data directly.

However, changes made directly to those raw objects may not force the views to update

Example: UpdateTheViews.mxml

3. Consistent data manipulation operations

Both ArrayCollection and XMLListCollection inherit from ListCollectionView

This makes it easy to edit data in a consistent way, regardless of which type of data is being used for the data provider

Square brackets [] (Don’t use these - they’re involved in a Flash Player bug regarding loading sub-applications; use getItemAt() intead)

getItemAt()

removeItemAt()

addItem()

4. Sorted views

Collections provide a mechanism to sort the view of the data without changing the underlying data itself

ListCollectionView’s sort property:

type = Sort

sort.fields should be an array of SortField objects, which describe how to perform the sort

Call refresh() on the collection object after assigning it a sort object

Underlying data does not change

Example: SortingViews.mxml

5. Filtered views

Collections also offer an easy way to filter data

Simply set the filterFunction property on the collection to a function of the form:

function theFilterFunction( item : Object ) : Boolean {}

The function should return true on the object if it should be included in the filtered view of the data

Example: SortingViews.mxml

Hierarchical Data

Representing hierarchical data in XML is trivial, since XML itself is natively hierarchical:

<Foods>

<Nuts>

<Nut>Peanut</Nut>

</Nuts>

</Foods>

Object graphs can be used, too

Example: ObjectHierarchy.mxml

Put the child objects in the “children” field of the object

Cursors

Classes used to navigate through collection objects

Provide convenient, consistent ways to access data in collections

Initialize to the first element in the collection

Cursors allow:

Movement through data (forward, back)

Searching (only if the collection is sorted)

Bookmarks

Data manipulation (addition, removal)

Great for navigating and searching through data

They respect sorts (even though the underlying data isn’t actually sorted, cursor will behave like it is)

They have an optimized find method

Handy for paging through long results sets

Common Problem: Manipulating a view component immediately after changing the data provider

Setting the dataProvider property on a component such as a Tree requires that it validate its properties and layout; it may need to add or remove children based on the changes

Attempting to manipulate the view component immediately after setting the dataProvider (i.e., on the next line of code) can cause runtime errors because the component has not yet validated its properties and layout

To get around this problem, call validateNow() on the view component immediately after setting the dataProvider

This forces the component to validate its properties and layout and redraw itself if necessary

Only do this when necessary; there’s a performance hit

Common Problem: Not seeing expected changes in the view

If the objects stored in a collection are not [Bindable], the view will not be able to detect when they have changed

In these instances, after updating an item in the collection, call the itemUpdated method on the collection, letting it know that its data has changed

SystemManager: overview

“Root” of the Flex swf

First class that is instantiated

Controls and coordinates the initialization of the application

Instantiates and displays the pre-loader

Instantiates Application and adds it to the display list

Manages layers of children for popups (sorta), cursors, and tooltips

Switches focus between top-level items like the above list

SystemManager: 2 frame swf

Flex apps currently publish to a 2 frame SWF

1st frame (small): SystemManager , Preloader, DownloadProgressBar, helper classes.

2nd frame (probably big): The rest of the framework, your application, embedded assets

SystemManager: 2 frame walkthrough

Frame 1 streams in, plays

SystemManager is created

SystemManager takes over - creates Preloader

Preloader tracks the rest of the bytes streaming in, provides updates to SystemManager

Once all bytes for frame 2 are streamed in, frame 2 plays

SystemManager: 2 frame walkthrough

Frame 2 plays

SystemManager instantiates Application, sets Application.systemManager to itself

Application initializes itself, emits CreationComplete

SystemManager adds Application to the DisplayList, hands control over to Application / LayoutManager

applicationComplete event is dispatched, and your app is ready to go

SystemManager: what is it good for?

Dispatches browser-resize events

Detecting if assets have been embedded

Fonts, for example. If the font isn’t embedded, use a different font.

SystemManager.embeddedFontList;

Displaying your own preloader

and...

SystemManager: what else is it good for?

Getting a reference to the root object

SystemManager.stage

Flash converts have probably spent some time looking for this

Monitoring keyboard and mouse activity

Manipulate multiple pop-ups, cursors, or tool-tips from their parent

SystemManager Pitfalls: Multiple Child Lists

PopUp windows added through PopUpManager.addPopUp or createPopUp do not go on the SystemManager.popupChildren list by default - they go on the normal Application child list.

This list is displayed above the Alert child list and toolTipChildList

To add them there, pass the constant PopUpManagerChildList.POPUP as the fourth parameter to the add or create methods on PopUpManager

PopUpManager.createPopUp( this , TestPopUp, false , PopUpManagerChildList.POPUP);

cursorChildren are on top of everything, then popupChildren, then toolTipChildren, then the regular old application children.

SystemManager Pitfalls: The Root

The system manager tries to own “_root”

May manipulate the root object in ways you’re not expecting in Flash

This makes flash / flex integration frustrating at times

I’m not going to go into this more, but be aware of it

Resources

Michael Labriola’s 2008 360|Flex San Jose talk about Data Binding: “Diving in the Data Binding Waters” (http://www.onflex.org/ted/2008/08/diving-in-data-binding-waters-with.php)