Apocalypse Soon

Apocalypse Soon? The remaking of 'Flex Components' Michael Labriola Digital Primates

Who are you?
Michael Labriola
Senior Consultant at Digital Primates
Flex Geek
Component Developer
Flex Team Mentor
Flex Unit 4 Lead Developer

What is this session about?
This session is part of my continuing quest to teach Flex from the inside out.
Learn what the Flash Player and the Flex framework are really doing and you are more likely to use them successfully, respect their boundaries and extend them in useful ways

Where are we going to do?
We are going to derive the Flex Framework.. Well at least the component model
We are not going to write or implement our own custom components
We are going to talk about how Flex components work and why

Standard Disclaimer
I am going to lie to you a lot… a whole lot
Even at this ridiculous level of detail, there is much more
All of this is conditional. So, we are just going to take one route and go with it

Flex Components
Flex 3 and Flex 4 components share a common ancestry which allows for interoperability
They both descend from UIComponent, the base class for most interactive visual items in Flex

Flex Components
These components are expected to interact with the user and run inside of the Flash Player, which means they are also subject to the resources available
One of the most relevant aspects of the Flash Player which drives component development is

The Beginning
If you are going to write components that behave well in the Flash Player, then you better know something about the Flash Player
You can’t write good components divorced from the environment where they run

The Flash Player
For our purposes, the Flash Player is nothing more than a single threaded runtime allowing us to execute byte code
The word single threaded is thrown around a lot, but what does it really mean

Single Threaded
The colloquial meaning is that a single threaded machine can only do one thing at a time.
That’s sort of right, but with the exception of mutlicore chips and multiple processors almost every computer can only do one thing at a time

Single Threaded
In general that means that a single processor is only doing one thing at a time in either single or multithreaded environments
So, what does single threaded really mean?

Single Threaded
It means that the processor can’t interrupt running code to do something else
In a single threaded environment a running method must be allowed to complete, and the method that called it, etc. before something else can happen

Multi Threaded
In a multi-threaded environment, the system can pause executing code go and work on something else and come back
Multi-threading is exceptionally useful, but imagine the great possibilities of how you can screw up.

Back to Single
So Flash Player is single threaded. It is never, ever going to interrupt ActionScript code execution
What the player is really doing is creating a multitasking environment, which is the appearance of doing multiple things at once. This is accomplished via scheduling

Multitasking
The player schedules when code is going to run. It executes your code on a schedule and eventually takes the results and renders them to the screen.

Framerate
It needs to ensure that it both executes your code and renders the screen at a rate fast enough to be a good experience for the user
This is where the concept of a framerate comes in. For our purposes, this is the rate at which Flash Player renders to the screen

Interruption
However, there is an issue. Remember Flash Player cannot ever interrupt your code.

Solving It
To attempt to solve the issues we have the idea of invalidation.
Invalidation allows us to indicate that some piece of code needs to be run. However, instead of running it now, we ask that it is run at the appropriate point in the schedule

Invalidation
This invalidation scheme is core to what it means to be a Flex component.
All Flex components for version 3 and 4 embrace the same invalidation scheme allowing code to execute later..
Speaking of 3 versus 4

Flex 3 v 4
Flex 4 is based on (more or less) the same UIComponent class used in Flex 3. That means all of the basic methods of Flex 3 also apply to Flex 4.
However, there is one minor difference in approach

A Simple Component
Let’s imagine at a series of components in the Flex 3 world. They are simply responsible for positioning 3 pictures in a variety of ways and adding a variety of borders.

Flex 3
In the Flex 3 world, we would likely have one of two scenarios
A base class and then a descendent class for each layout (think List, HorizontalList) plus potentially more descendents for different frame types: (Button, LinkButton )

Flex 3
Or we would have one giant uber base class that has all of this functionality inside of it and can then be configure.
Option 1 is rough for maintenance. Option 2 is very heavy

Flex 4 Frame Horizontal Vertical Diagonal Frame 1 Frame 2

Making it Work
To make a philosophy like Flex 4 work though, all of the visual components need to exist outside of the base component
What does that mean a list really is?

Important things to understand
In Flex 4 components are composed of two pieces
The form
The function

The Function
What the component does
How it does it
When it does it
Defines what the component is
Buttons are about being clicked
List is about selection and virtualization

The Form
A list doesn’t have to be horizontal or vertical to be a list
Buttons don’t need to be rectangles

Separation
Separating these pieces favors composition over inheritance
By separating form and function we gain and we lose.

We Gain
The capability of having one set of functionality look many different ways
Back to the list example, a list can be horizontal, vertical, circular, etc. but we only have to maintain the code in one list class

We Lose
We lose a lot of dead weight
We lose a lot of extra classes

There are two types of UI Components in Flex
Controls
Interact with a user
Present data
Accept gestures
Containers
Hold other containers and controls
Control positioning of children

On the topic of losing weight
There are two types of things in the Flex 4 world, those that can be skinned and those that cannot
Roughly corresponding to those that have their own visual appearance and those that simply influence the visualization of others
Why? Because we don’t want to burden everything in the world with functionality it doesn’t need

Groups are the Base Type of Container
Groups don’t have a visual identity of their own
Groups can accept a layout object to handle the layout of children

Layout Types
Layout types built into flex
BasicLayout
HorizontalLayout
VerticalLayout
The important part about this is creating your own layouts

Controls and Some Containers can be Skinned
Controls can also have their visual appearance modified and quite easily by skinning

Skins
Skins are classes defined in MXML
They are based on the Skin class
They are applied to components using
The skinClass
Or by CSS

Definitions
Think about the list class
No visual elements can exist inside the list or it reduces skin-ability
All visuals exist in the skin
That means the component provides the functionality and controls aspects of the skin
That could get ugly

Contracts
That means we must have some sort of contract between a skin and a component.
This contract defines the minimum things that must be present inside of the skin to be considered valid
This contract is fulfilled in two ways

Components
Declare skin parts (required or not)
Declare skin states

Skins
Specify a HostComponent
<fx:Metadata>
[HostComponent("spark.components.Button")]
</fx:Metadata>
Declare states
<s:states>
<s:State name="up" />
<s:State name="over" />
</s:states>
Establish visuals

Visuals
What type of visuals?

How it all works
Internally Flex components are driven by a couple of basic needs
They have the need to size themselves correctly.
They have the need to be created at runtime
They have the need to interact with parents and children

Instantiation
Just like any other ActionScript class, all Flex components start with a constructor
Constructors in Flex add event listeners and setup initial properties… that’s it

Display List
Eventually, the lucky components make it onto the display list, this is where the work starts
An item on the display list needs to interact with users.. And hence needs a visual appearance

Creating Children
In Flex, all visual children of a component are created in the createChildren method
In Flex 4, the visual children of a component exist in the skin and so the skin is first created at this time

Skin Methods
To that end, Flex 4 introduces a few new methods as well:
attachSkin
detachSkin
partAdded
partRemoved

Sizing
One of the most import differentiators of Flex components is their ability to self size
When I put a Container on the screen and put a Button inside of it, everything figures out how to size itself correctly, how?

Sizing
Sizing in Flex applications works because each parent is allowed to determine its appropriate size based on its children
So, first step in sizing would be needing to know the size of your children, which means, they need to exist

Sizing
Each and every component in the Flex framework implements a method called measure().
Measure is responsible for figuring out four things
measuredWidth/Height – how big the component would like to be
measuredMinWidth/measuredMinHeight – min sizes

Sizing
Measure can do this any way it wants.. Random, hardcoded, it doesn’t matter and we don’t know for sure, however, most components figure out how big they would like to be, based on how big their children are

Sizing
This means that one of two things needs to be true, either the children must know their size before their parent or the parent must be able to force the children to size themselves.
Either would work equally well in a simple example, but it is a recursive problem and remember Flash Player cannot interrupt code execution

Sizing
So, Flex works on the principle that children must be sized before their parent and it makes the sizing process potentially asynchronous
How? Well, ever waited in line to get on a plane?

Plane
Usually when boarding a plane it is not just a linear process. Some airlines allow premier members to board first. Some have the back of the plane or the window seats board first.
So, even though your position in line has something to do with your boarding time, there is the ability to modify that

Priority Queue
This is an example of a priority queue which is at the heart of the how Flex handles these issues. Every time a component needs to be sized (including the first time) it is added to a priority queue.
What establishes the priority?

Measure v. NestLevel
Well in the case of measure, children at a deeper nest level are handled before children at a shallower level.
In other words, it is still a queue, but if two components need to be measured at the same time, the one on the deeper nest level always gets measured first

Measure v. NestLevel
This makes a lot of sense.
If parents need to figure out their size based on their children, then even if things change size at runtime, we really need to make sure that we figure out the new size of children before their parents.

Flex 4
So, in Flex 4 children don’t live inside of a component, they live in the skin, so how do we measure?
This is all recursive, the skin is a component, so we ask it the size of its children

Measured Data
The whole of the work done in measure is only a suggestion.
When the measure method is done the component has four pieces of possibly irrelevant information.
The component does not have a size

Sizing
There are only a few absolutes in Flex, but one of them is that a component does not size itself.
Parents size children

Sizing
So, after all of the measuring is done, all you have a are a bunch of suggestions on how big you might like things to be
Now comes the critical time when children actually need to be sized

Sizing and Positioning
Sizing and positioning is done in a method called updateDisplayList()
This method, like measure() is called by the framework when it is time

UDL v NestLevel
The order in which it is called is also based on its nestLevel. However, since this method directly affects children, it is opposite of measure.
A parent must know its size before it can assign size to its children, so parents are always called before children

UDL
Each component on the screen is given an width and a height that it is allowed to work with.
This facilitates the biggest and best lie in Flex

UDL
Components are given a size.
Once the component is given its size, it is free to do what it wishes. For the most part, this information is simply passed down to the skin
Again recursion

Resources
Blog Aggregator (All of the Digital Primates)
http://blogs.digitalprimates.net/
My Blog Specifically
http://blogs.digitalprimates.net/codeSlinger/

Apocalypse Soon

by michael.labriola on Mar 12, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 3

Statistics

Apocalypse Soon — Presentation Transcript