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

Apocalypse Soon

Embed Size (px)

DESCRIPTION

360|Flex San Jose 2010 presentation on Flex 4 component life cycle

Citation preview

Page 1: Apocalypse Soon

Apocalypse Soon? The remaking of

'Flex Components'Michael Labriola

Digital Primates

Page 2: Apocalypse Soon

Who are you?

Michael LabriolaSenior Consultant at Digital Primates

Flex GeekComponent DeveloperFlex Team MentorFlex Unit 4 Lead Developer

Page 3: Apocalypse Soon

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

Page 4: Apocalypse Soon

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

Page 5: Apocalypse Soon

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

Page 6: Apocalypse Soon

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

Page 7: Apocalypse Soon

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

Page 8: Apocalypse Soon

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

Page 9: Apocalypse Soon

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

Page 10: Apocalypse Soon

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

Page 11: Apocalypse Soon

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?

Page 12: Apocalypse Soon

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

Page 13: Apocalypse Soon

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.

Page 14: Apocalypse Soon

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

Page 15: Apocalypse Soon

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.

Page 16: Apocalypse Soon

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

Page 17: Apocalypse Soon

Interruption

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

Page 18: Apocalypse Soon

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

Page 19: Apocalypse Soon

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

Page 20: Apocalypse Soon

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

Page 21: Apocalypse Soon

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.

Page 22: Apocalypse Soon

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 )

Page 23: Apocalypse Soon

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

Page 24: Apocalypse Soon

Flex 4

Frame

Horizontal

Vertical

Diagonal

Frame 1

Frame 2

Page 25: Apocalypse Soon

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?

Page 26: Apocalypse Soon

Important things to understand

In Flex 4 components are composed of two pieces– The form– The function

Page 27: Apocalypse Soon

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

Page 28: Apocalypse Soon

The Form

A list doesn’t have to be horizontal or vertical to be a list

Buttons don’t need to be rectangles

Page 29: Apocalypse Soon

Separation

Separating these pieces favors composition over inheritance

By separating form and function we gain and we lose.

Page 30: Apocalypse Soon

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

Page 31: Apocalypse Soon

We Lose

We lose a lot of dead weight

We lose a lot of extra classes

Page 32: Apocalypse Soon

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

Page 33: Apocalypse Soon

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

Page 34: Apocalypse Soon

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

Page 35: Apocalypse Soon

Layout TypesLayout types built into flex

BasicLayoutHorizontalLayoutVerticalLayout

The important part about this is creating your own layouts

Page 36: Apocalypse Soon

Controls and Some Containers can be

SkinnedControls can also have their visual

appearance modified and quite easily by skinning

Page 37: Apocalypse Soon

SkinsSkins are classes defined in MXML

They are based on the Skin class

They are applied to components usingThe skinClassOr by CSS

Page 38: Apocalypse Soon

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

Page 39: Apocalypse Soon

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

Page 40: Apocalypse Soon

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

Page 41: Apocalypse Soon

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

Page 42: Apocalypse Soon

Visuals

• What type of visuals?

Page 43: Apocalypse Soon

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 runtimeThey have the need to interact with parents

and children

Page 44: Apocalypse Soon

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

Page 45: Apocalypse Soon

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

Page 46: Apocalypse Soon

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

Page 47: Apocalypse Soon

Skin Methods

To that end, Flex 4 introduces a few new methods as well:

attachSkindetachSkin

partAddedpartRemoved

Page 48: Apocalypse Soon

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?

Page 49: Apocalypse Soon

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

Page 50: Apocalypse Soon

Sizing

Each and every component in the Flex framework implements a method called measure().

Measure is responsible for figuring out four thingsmeasuredWidth/Height – how big the component would like to bemeasuredMinWidth/measuredMinHeight – min sizes

Page 51: Apocalypse Soon

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

Page 52: Apocalypse Soon

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

Page 53: Apocalypse Soon

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?

Page 54: Apocalypse Soon

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

Page 55: Apocalypse Soon

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?

Page 56: Apocalypse Soon

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

Page 57: Apocalypse Soon

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.

Page 58: Apocalypse Soon

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

Page 59: Apocalypse Soon

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

Page 60: Apocalypse Soon

Sizing

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

Parents size children

Page 61: Apocalypse Soon

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

Page 62: Apocalypse Soon

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

Page 63: Apocalypse Soon

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

Page 64: Apocalypse Soon

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

Page 65: Apocalypse Soon

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

Page 66: Apocalypse Soon

Resources

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

My Blog Specificallyhttp://blogs.digitalprimates.net/codeSlinger/