Jonathan Campos' Blog » Best Practices

Customizable Busy Indicator

jonbcampos — Fri, 05 Aug 2011 14:44:05 +0000

A good friend of mine, Antonio Holguin, inspired me to write this blog post when he wanted a good, customized busy indicator for a new application that he is creating – and he wanted to know what the heck I did with Queue Manager. If you’ve seen my Queue Manager application you’ve probably noticed that I have a custom busy indicator that looks like an “N” as it’s loading (Designed by Dimi Arhontidis).

In this post I’m going to show you a class that I made after studying the Flex “BusyIndicator” class. Adobe has spent a great amount of time creating a great Busy Indicator, however I didn’t feel that the BusyIndicator was easily customizable, so I changed that.

Below is my code and some implementations.

First, my custom class. The class is fairly straight forward and a slight modification of the Adobe provided BusyIndicator, however the thing that I did was add an easy way to override the shape creation function and give you two options to know where the loader is in progress, either through the selected index or the current rotation value. If you are using a circular loader then the “currentRotation” value may be better for you. For anything else the selectedIndex value may be better for you.

Use these values when you draw your symbols.

CustomizableBusyIndicator

package com.unitedmindset.components
{
import flash.display.Graphics;
import flash.events.Event;
import flash.events.TimerEvent;
import flash.utils.Timer;

import mx.core.DPIClassification;
import mx.core.DesignLayer;
import mx.core.FlexGlobals;
import mx.core.IUIComponent;
import mx.core.IVisualElement;
import mx.core.UIComponent;
import mx.events.FlexEvent;
import mx.events.PropertyChangeEvent;

/**
* The interval to delay, in milliseconds, between rotations of this
* component. Controls the speed at which this component spins.
*
* @default 50
*
* @langversion 3.0
* @playerversion AIR 2.5
* @productversion Flex 4.5
*
*/
[Style(name="rotationInterval", type="Number", format="Time", inherit="no")]

/**
* Color of the symbols of the spinner.
*
* @default 0x000000
*
* @langversion 3.0
* @playerversion AIR 2.5
* @productversion Flex 4.5
*/
[Style(name="symbolColor", type="uint", format="Color", inherit="yes", theme="spark,mobile")]

/**
* Busy Indicator with easy to customize symbols.
*
* Just override the drawSymbol() method to customize your symbols.
* Override the measure method to adjust the sizes of the
* busyindicator for different dpis. This is slightly modified code
* from the Flex framework to make the busy indicator easier to customize
* in my opinion while still being as lightweight as possible.
*
* @author jonbcampos
*
*/
public class CustomizableBusyIndicator extends UIComponent
{
//--------------------------------------------------------------------------
//
// Constructor
//
//--------------------------------------------------------------------------
public function CustomizableBusyIndicator()
{
super();

// Listen to added to stage and removed from stage.
// Start rotating when we are on the stage and stop
// when we are removed from the stage.
addEventListener(Event.ADDED_TO_STAGE, addedToStageHandler);
addEventListener(Event.REMOVED_FROM_STAGE, removedFromStageHandler);
}

//--------------------------------------------------------------------------
//
// Class constants
//
//--------------------------------------------------------------------------

/**
* @private
*/
static private const DEFAULT_ROTATION_INTERVAL:Number = 50;

/**
* @private
*/
static private const DEFAULT_MINIMUM_WIDTH_SIZE:Number = 28;
static private const DEFAULT_MINIMUM_HEIGHT_SIZE:Number = 38;

//--------------------------------------------------------------------------
//
// Variables
//
//--------------------------------------------------------------------------

/**
* @private
*/
private var effectiveVisibility:Boolean = false;

/**
* @private
*/
private var effectiveVisibilityChanged:Boolean = true;

/**
* @private
*/
private var oldUnscaledHeight:Number;

/**
* @private
*/
private var oldUnscaledWidth:Number;

/**
* @private
*/
private var rotationTimer:Timer;

/**
* Current rotation of this component in degrees.
*
* Mimicked by the selectedIndex, though in index form.
*/
protected var currentRotation:Number = 0;
/**
* Current selected index of the symbols.
*
* Mimicked by the currentRotation, though in degrees.
*/
protected var selectedIndex:int = 0;

private var _symbolQuantity:int = 1;
private var _symbolQuantityChanged:Boolean;
/**
* The fewer the symbols the less the drawing
* the faster the component.
*
* @return
*
*/
public function get symbolQuantity():int { return _symbolQuantity; }

public function set symbolQuantity(value:int):void
{
if (_symbolQuantity == value)
return;
if(value<1)
value = 1;
_symbolQuantity = value;
_symbolQuantityChanged = true;
invalidateProperties();
}

//--------------------------------------------------------------------------
//
// Private Properties
//
//--------------------------------------------------------------------------

/**
* @private
* Cache the last value of applicationDPI.
*/
private var _applicationDPI:Number;

/**
* @private
*
* Get the applicationDPI in use.
*/
private function get applicationDPI():Number
{
if (_applicationDPI)
return _applicationDPI;

var application:Object = FlexGlobals.topLevelApplication;

if ("applicationDPI" in application)
_applicationDPI = application["applicationDPI"];

return _applicationDPI;
}

//--------------------------------------------------------------------------
//
// Overridden properties: UIComponent
//
//--------------------------------------------------------------------------

/**
* @private
*/
override public function set designLayer(value:DesignLayer):void
{
super.designLayer = value;

effectiveVisibilityChanged = true;
invalidateProperties();
}

//--------------------------------------------------------------------------
//
// Overridden methods: UIComponent
//
//--------------------------------------------------------------------------

/**
* @private
*/
override protected function commitProperties():void
{
super.commitProperties();

if (effectiveVisibilityChanged)
{
// if visibility changed, re-compute them here
computeEffectiveVisibility();

if (canRotate())
startRotation();
else
stopRotation();

effectiveVisibilityChanged = false;
}

if(_symbolQuantityChanged)
{
_symbolQuantityChanged = false;
updateSymbols();
}
}

/**
* @private
*/
override protected function measure():void
{
super.measure();

// Set the default measured size depending on the
// applicationDPI
if (applicationDPI == DPIClassification.DPI_320)
{
//12x12
measuredWidth = 42;
measuredHeight = 42;
}
else if (applicationDPI == DPIClassification.DPI_240)
{
//10x10
measuredWidth = 34;
measuredHeight = 34;
}
else if (applicationDPI == DPIClassification.DPI_160)
{
//8x8
measuredWidth = 28;
measuredHeight = 28;
}
else
{
measuredWidth = DEFAULT_MINIMUM_WIDTH_SIZE;
measuredHeight = DEFAULT_MINIMUM_HEIGHT_SIZE;
}

measuredMinWidth = DEFAULT_MINIMUM_WIDTH_SIZE;
measuredMinHeight = DEFAULT_MINIMUM_HEIGHT_SIZE;
}

/**
* @private
* Override so we know when visibility is set. The initialized
* property calls setVisible() with noEvent == true
* so we wouldn't get a visibility event if we just listened
* for events.
*/
override public function setVisible(value:Boolean, noEvent:Boolean = false):void
{
super.setVisible(value, noEvent);

effectiveVisibilityChanged = true;
invalidateProperties();
}

/**
* @private
*/
override public function styleChanged(styleProp:String):void
{
super.styleChanged(styleProp);

var allStyles:Boolean = !styleName || styleName == "styleName";

// Check for skin/icon changes here.
// We could only throw out any skins that change,
// but since dynamic re-skinning is uncommon, we'll take
// the simpler approach of throwing out all skins.
if (allStyles || styleName == "rotationInterval")
{
// Update the timer if the rotation interval has changed.
if (isRotating())
{
stopRotation();
startRotation();
}
}

if (allStyles || styleName == "symbolColor")
{
updateSymbols();
}
}

/**
* @private
*/
override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
super.updateDisplayList(unscaledWidth, unscaledHeight);

// If the size changed, then create a new spinner.
if (oldUnscaledWidth != unscaledWidth || oldUnscaledHeight != unscaledHeight)
{
var newDiameter:Number;

updateSymbols();

oldUnscaledWidth = unscaledWidth;
oldUnscaledHeight = unscaledHeight;

}
}

//--------------------------------------------------------------------------
//
// Methods
//
//--------------------------------------------------------------------------

/**
* @private
*
* Update the spinner properties and redraw.
*/
private function updateSymbols():void
{
var isRotating:Boolean = isRotating();

if (isRotating)
stopRotation();

drawSymbols();

if (isRotating)
startRotation();
}

/**
* Draw the spinner using the graphics property of this component.
*/
protected function drawSymbols():void
{
var g:Graphics = graphics;
g.clear();

var index:int = -1;
while(++index<symbolQuantity)
drawSymbol(index);
}

/**
* Draws the symbol, use the index to determine the position, color, etc.
*
* @param index
*
*/
protected function drawSymbol(index:int):void
{

}

/**
* @private
*/
private function startRotation():void
{
if (!rotationTimer)
{
var rotationInterval:Number = getStyle("rotationInterval");
if (isNaN(rotationInterval))
rotationInterval = DEFAULT_ROTATION_INTERVAL;

if (rotationInterval < 16.6)
rotationInterval = 16.6;

rotationTimer = new Timer(rotationInterval);
}

if (!rotationTimer.hasEventListener(TimerEvent.TIMER))
{
rotationTimer.addEventListener(TimerEvent.TIMER, timerHandler);
rotationTimer.start();
}

}

/**
* @private
*/
private function stopRotation():void
{
if (rotationTimer)
{
rotationTimer.removeEventListener(TimerEvent.TIMER, timerHandler);
rotationTimer.stop();
rotationTimer = null;
}
}

/**
* @private
*/
private function isRotating():Boolean
{
return rotationTimer != null;
}

/**
* The BusyIndicator can be rotated if it is both on the display list and
* visible.
*
* @returns true if the BusyIndicator can be rotated, false otherwise.
*/
private function canRotate():Boolean
{
if (effectiveVisibility && stage != null)
return true;

return false;
}

/**
* @private
*/
private function computeEffectiveVisibility():void
{

// Check our design layer first.
if (designLayer && !designLayer.effectiveVisibility)
{
effectiveVisibility = false;
return;
}

// Start out with true visibility and enablement
// then loop up parent-chain to see if any of them are false.
effectiveVisibility = true;
var current:IVisualElement = this;

while (current)
{
if (!current.visible)
{
if (!(current is IUIComponent) || !IUIComponent(current).isPopUp)
{
// Treat all pop ups as if they were visible. This is to
// fix a bug where the BusyIndicator does not spin when it
// is inside modal popup. The problem is in we do not get
// an event when the modal window is made visible in
// PopUpManagerImpl.fadeInEffectEndHandler(). When the modal
// window is made visible, setVisible() is passed "true" so
// as to not send an event. When do get events when the
// non-modal windows are popped up. Only modal windows are
// a problem.
// The downside of this fix is BusyIndicator components that are
// inside of hidden, non-modal, popup windows will paint themselves
// on a timer.
effectiveVisibility = false;
break;
}
}

current = current.parent as IVisualElement;
}
}

/**
* @private
* Add event listeners for SHOW and HIDE on all the ancestors up the parent chain.
* Adding weak event listeners just to be safe.
*/
private function addVisibilityListeners():void
{
var current:IVisualElement = this.parent as IVisualElement;
while (current)
{
// add visibility listeners to the parent
current.addEventListener(FlexEvent.HIDE, visibilityChangedHandler, false, 0, true);
current.addEventListener(FlexEvent.SHOW, visibilityChangedHandler, false, 0, true);

current = current.parent as IVisualElement;
}
}

/**
* @private
* Remove event listeners for SHOW and HIDE on all the ancestors up the parent chain.
*/
private function removeVisibilityListeners():void
{
var current:IVisualElement = this;
while (current)
{
current.removeEventListener(FlexEvent.HIDE, visibilityChangedHandler, false);
current.removeEventListener(FlexEvent.SHOW, visibilityChangedHandler, false);

current = current.parent as IVisualElement;
}
}

//--------------------------------------------------------------------------
//
// Overridden event handlers: UIComponent
//
//--------------------------------------------------------------------------

/**
* @private
*/
override protected function layer_PropertyChange(event:PropertyChangeEvent):void
{
super.layer_PropertyChange(event);

if (event.property == "effectiveVisibility")
{
effectiveVisibilityChanged = true;
invalidateProperties();
}
}

//--------------------------------------------------------------------------
//
// Event Handlers
//
//--------------------------------------------------------------------------

/**
* @private
*/
private function addedToStageHandler(event:Event):void
{
// Check our visibility here since we haven't added
// visibility listeners yet.
computeEffectiveVisibility();

if (canRotate())
startRotation();

addVisibilityListeners();
}

/**
* @private
*/
private function removedFromStageHandler(event:Event):void
{
stopRotation();

removeVisibilityListeners();
}

/**
* @private
* Event call back whenever the visibility of us or one of our ancestors
* changes
*/
private function visibilityChangedHandler(event:FlexEvent):void
{
effectiveVisibilityChanged = true;
invalidateProperties();
}

/**
* @private
*
* Rotate the spinner once for each timer event.
*/
private function timerHandler(event:TimerEvent):void
{
currentRotation += 360/symbolQuantity;
selectedIndex++;
if (currentRotation >= 360)
{
currentRotation = 0;
selectedIndex = 0;
}

drawSymbols();
event.updateAfterEvent();
}
}
}

Next we need to customize and subclass the CustomizableBusyIndicator by overriding the drawSymbol method. Below are two examples of the customized busy indicator. The first I modeled after the Nintendo DS Loader – I was just playing Zelda, it’s all I could come up with.

The second is modeled after another loader I’ve seen, can’t remember where.

Customizing is easy and best of all the loader has been performance optimized. So you can create something custom is with the mental security you’re not screwing anything up.

Busy Indicators

DS Loader

package com.unitedmindset.components
{
import flash.display.Graphics;

/**
* Busy Indicator modeled after the Nintendo DS Busy Indicator.
*
* @author jonbcampos
*
*/
public class DSBusyIndicator extends CustomizableBusyIndicator
{
public function DSBusyIndicator()
{
super();
//the quantity of symbols for this indicator.
//8 squares
symbolQuantity = 8;
}

private var _symbolPadding:Number = 2;
private var _symbolWidth:Number = 0;
private var _symbolHeight:Number = 0;

/**
* Measures and sets size based on DPI.
*/
override protected function measure():void
{
//use the default sizes.
//I could also make different
//sizes for my component by overriding.
super.measure();

//I only want to make this
//calculation when the measurement
//changes, but it isn't super
//necessary here. I would put it in the
//drawSymbols method.
_symbolHeight = (measuredHeight - (_symbolPadding*2)) / 3;
_symbolWidth = (measuredWidth - (_symbolPadding*2)) / 3;
}

/**
* Kick starts drawing all the individual symbols.
*/
override protected function drawSymbols():void
{
super.drawSymbols();

var symbolColor:uint = getStyle("symbolColor") as uint;

//make center square
var g:Graphics = graphics;
g.beginFill(symbolColor, 1);
var centerX:Number = (measuredWidth - _symbolWidth)/2;
var centerY:Number = (measuredHeight - _symbolHeight)/2;
g.drawRect(centerX, centerY, _symbolWidth, _symbolHeight);
g.endFill();
}

/**
* Draws one symbol.
*
* @param index The index shows which symbol in the matrix you are making.
* This value is arbitrary and you can layout your symbols however you want
* in whatever index order you want.
*
*/
override protected function drawSymbol(index:int):void
{
var _alpha:Number = 1;
var _posX:Number = 0;
var _posY:Number = 0;

var _alpha1:Number = 0.4;
var _alpha2:Number = 0.6;

switch(index)
{
case 0: //top left
//set alpha if it is the selected symbol
if(selectedIndex==0)
_alpha = _alpha1;
else if(selectedIndex==7)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
//default pos
break;
case 1: //top center
//set alpha if it is the selected symbol
if(selectedIndex==1)
_alpha = _alpha1;
else if(selectedIndex==0)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
_posX = _symbolWidth + _symbolPadding;
break;
case 2: //top right
//set alpha if it is the selected symbol
if(selectedIndex==2)
_alpha = _alpha1;
else if(selectedIndex==1)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
_posX = _symbolWidth*2 + _symbolPadding*2;
break;
case 3: //mid right
//set alpha if it is the selected symbol
if(selectedIndex==3)
_alpha = _alpha1;
else if(selectedIndex==2)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
_posX = _symbolWidth*2 + _symbolPadding*2;
_posY = _symbolHeight + _symbolPadding;
break;
case 4: //bottom right
//set alpha if it is the selected symbol
if(selectedIndex==4)
_alpha = _alpha1;
else if(selectedIndex==3)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
_posX = _symbolWidth*2 + _symbolPadding*2;
_posY = _symbolHeight*2 + _symbolPadding*2;
break;
case 5: //bottom center
//set alpha if it is the selected symbol
if(selectedIndex==5)
_alpha = _alpha1;
else if(selectedIndex==4)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
_posX = _symbolWidth + _symbolPadding;
_posY = _symbolHeight*2 + _symbolPadding*2;
break;
case 6: //bottom left
//set alpha if it is the selected symbol
if(selectedIndex==6)
_alpha = _alpha1;
else if(selectedIndex==5)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
_posY = _symbolHeight*2 + _symbolPadding*2;
break;
case 7: //mid left
//set alpha if it is the selected symbol
if(selectedIndex==7)
_alpha = _alpha1;
else if(selectedIndex==6)
_alpha = _alpha2;
else
_alpha = 1;
//position symbol
_posY = _symbolHeight + _symbolPadding;
break;
}
//get the symbol style color
var symbolColor:uint = getStyle("symbolColor") as uint;
//with all my positions determined,
//now actual draw the graphic
var g:Graphics = graphics;
g.beginFill(symbolColor, _alpha);
g.drawRect(_posX, _posY, _symbolWidth, _symbolHeight);
g.endFill();
}
}
}

Other Loader

package com.unitedmindset.components
{
import flash.display.Graphics;

/**
* Busy Indicator modeled after ?.
* @author jonbcampos
*
*/
public class CirclesBusyIndicator extends CustomizableBusyIndicator
{
public function CirclesBusyIndicator()
{
super();
//the quantity of symbols for this indicator.
//6 circles
symbolQuantity = 6;
//make it just a bit slower
//you could also adjust the
//speed by setting the style on
//the component instance.
setStyle("rotationInterval", 100);
}

private var _symbolWidth:Number = 0;
private var _symbolHeight:Number = 0;
private var _radius:Number = 0;

/**
* Measures and sets size based on DPI.
*/
override protected function measure():void
{
//use the default sizes.
//I could also make different
//sizes for my component by overriding.
super.measure();

//I only want to make this
//calculation when the measurement
//changes, but it isn't super
//necessary here. I would put it in the
//drawSymbols method.
_symbolHeight = measuredHeight/3;
_symbolWidth = measuredWidth/3;
_radius = measuredWidth / 7;
}

/**
* Draws one symbol.
*
* @param index The index shows which symbol in the matrix you are making.
* This value is arbitrary and you can layout your symbols however you want
* in whatever index order you want.
*
*/
override protected function drawSymbol(index:int):void
{
var _alpha:Number = 1;
var _posX:Number = 0;
var _posY:Number = 0;

//if the selected index
//is the index we are drawing
//set it's alpha lower
if(index==selectedIndex)
_alpha = 0.5;

switch(index)
{
case 0: //top left
_posX = measuredWidth / 3;
_posY = measuredHeight / 6;
break;
case 1: //top right
_posX = measuredWidth - _symbolWidth;
_posY = measuredHeight / 6;
break;
case 2: //mid right
_posX = (measuredWidth + measuredWidth/6) - _symbolWidth;
_posY = measuredHeight / 2;
break;
case 3: //bottom right
_posX = measuredWidth - _symbolWidth;
_posY = (measuredHeight + measuredHeight/6) - _symbolHeight;
break;
case 4: //bottom left
_posX = measuredWidth / 3;
_posY = (measuredHeight + measuredHeight/6) - _symbolHeight;
break;
case 5: //mid left
_posX = measuredWidth / 6;
_posY = measuredHeight / 2;
break;
}
//get the symbol style color
var symbolColor:uint = getStyle("symbolColor") as uint;
//with all my positions determined,
//now actual draw the graphic
var g:Graphics = graphics;
g.beginFill(symbolColor, _alpha);
g.drawCircle(_posX, _posY, _radius);
g.endFill();
}
}
}

Learn from my mobile mistakes

jonbcampos — Tue, 28 Dec 2010 15:02:59 +0000

This blog post could also be “how to lower your stars in the marketplace”. I say this because now looking back at having an application in the marketplace for a few months I see many places that I have screwed up and things that I could do much better next time.

At the point of writing this I’m actually really happy with where Queue Manager has gone.
- Queue Manager has almost 50k users
- Queue Manager is listed highly in the Android Market
- Queue Manager is listed as the top Air for Android app on AppBrain
- Queue Manager is listed highly in AppAware
- Queue Manager is awaiting acceptance into the BlackBerry App World
- Android Central listed Queue Manager as a top pick in October and it was stated “it [Queue Manager] has proven to me the viability of Adobe Air as a development platform for Android”

All this success has not been due to my efforts though, I feel that my efforts have only hindered the application’s success rather than bolster it. I’m going to go through the things that I’ve done – or have been done to me – that have hurt Queue Manager and what I have done to fix my mistakes.

Some of these mistakes are embarrassing to admit, especially from a developer that has made multiple applications / products before, yet the old issues still creep up if you let them.

Releasing Too Early
This issue was due to my ego more than anything else. I wanted to have the first Air for Android application on the market and guess what? I did it. The second that Air was pushed to the market I followed right up with Queue Manager. What issues did this cause? You can assume and assume correctly that the initial release was buggy, feature depleted, and could have used some good ole’ optimization. In subsequent releases I fixed up these bugs but due to my buggy release I ended up on triage duty for the first week.

To Do Item(s):

- Release when the app is ready, not based on some other date

Frequent Releases
Part of this issue was due to how far I needed to go to compete with other Netflix applications on the Android market, part of this issue was that I was trying to have a specific feature set out by Adobe Max, part of this issue was that I wasn’t testing thoroughly enough and had to constantly release bug fixes, and part of this issue was that every time I finished a feature I wanted it out to the market as fast as possible. All of these “parts” lead to one thing: upset users. While some users appreciated the frequent releases most told me that they would have preferred if they weren’t quite as frequent as I was making them. As time has gone on my releases have been less frequent as the amount of changes needed to the application have decreased. Along with that I have been testing more on my application prior to release – not just testing the feature that I worked on. Finally my app has grown to a very stable state so the bugs have been worked out over time.

I currently sit on releases a day or two just to feel good about them.

To Do Item(s):

- Plan releases
- Test throughly so that you’re not having to follow up a feature release with an immediate bug fix
- Even if you have good code to release, spread it out and possibly merge feature releases

Work closely with your API provider
This has actually been one of my biggest problems and a problem I am completely helpless to – hopefully the app that you make isn’t dependent on a public API.

The issue is that Netflix provides me X amount of calls against their servers in one day. If Queue Manger gets featured somewhere or a bunch of people decide to use Queue Manager for an extended period of time and Queue Manager hits it’s Netflix limit then the application starts giving back an error from Netflix. Each time this has happened I have contacted Netflix and they have given me a bump in my limit, yet another few weeks pass by and I start hitting my limit again. I feel for my users, they just want an application that works, yet this is an area that I am completely hopeless.

When this happens I usually end up with a string of 1 star comments in my market reviews.

This is particularly bad when I put out a new release because everyone goes and plays with the app to see what has changed. A quarter of my user base could easily put me over my API limit.

To Do Item(s):

- Give good feedback to the user
- Limit calls to the server

Condense your trips
Mobile is great because it is on the go however you can quickly come across places that on the go doesn’t equal on the web. With this spotty service possibility even the smallest service call may take quite a long time to fully get back. I learned this the hard way with my initial release.

On my testing computer I received each service call I made almost instantly and the computer was quickly able to parse and visualize the data. When my users started working with my application the initial comments I got back were that they didn’t know if anything was going on. Even after adding visual loading indicators I had users complaining that the application was “sluggish” and the data was taking too long to get back.

This lead to another place for optimization and I spent some long nights working on reorganizing the service calls that I made to the Netflix service. This reduced the data that I was receiving from Netflix, sped up the application and especially the loading time. I still have users that say it takes to long, but eventually there is only so much that I can do about the network, their location, and their device.

To Do Item(s):

- Give good feedback to the user
- Reduce the amount of data you rely on

Double check your app id prior to release!
I thought that I would be the only person to hit this but alas my good friend FlashCanon also fell prey to this. Prior to releasing your app to the Android Market double check your app id in the application descriptor file and make sure you are perfectly happy with it BECAUSE YOU CAN’T CHANGE IT LATER! The name of the app, the programming, the colors, and basically everything else about your app can change between releases but your app id will stay the same and can’t be changed.

I know there are rumors that you can contact Google and ask them to help change your app id but I would recommend just getting this right from the beginning.

If you need to change the app id you will just have to put up a new application with the right id and get your users to reinstall the new app. Obviously you will lose the stats and whatever else from your initial release but you will get the id that you were wanting.

To Do Item(s):

- Double check your application id!

Double check your application descriptor prior to every release
With every release you can remove your application from the Android Market based on the options that are in your application descriptor. There was about a two week period that I removed Queue Manager from the Marketplace because I updated my Flash Builder version and the application descriptor changed just slightly. This slight change altered the filtering options on my application and even my users couldn’t find the application in a search.

Always check your application descriptor and the application manifest. These details lead to filtering in the Android Market.

Now prior to every release I read through my application manifest, double check that the install location is set to auto, and that my user permissions are set properly.

To Do Item(s):

- Double check your permissions
- Make sure that the install location is set to auto for app2sd functionality
- Ensure that your icons stay consistent between releases (and exist)

Have error tracking code
As I hinted at earlier there are many things that may go wrong with an application. The device may malfunction, the internet signal may fade, or – the most obvious – your code may break. Your users will probably be quick to tell you that your application sucks or has failed but be unclear as to what happened. As I am limited and don’t know what has happened on the server side (delivered by Netflix) I have an entire section of my application that I am unaware of any issues.

That being said I’ve had to construct an error tracking system within my application to give the users details as to what happened and ultimately deliver to me the error. All this extra work is very helpful to narrowing down the problem. As an added bonus, if you make error reporting very easy on your users they are more apt to sending you the generated error report.

To Do Item(s):

- Give good feedback to the user
- Make it easy for the user to submit bugs/issues

Have statistics gathering code
I love statistics gathering code because once I know what my users are doing on a statistical level I know where to focus my efforts for development. I’ve recently learned that my users do two things: search for titles and browse through new instant titles. That’s it. Knowing this I can focus my development practices around making sure that my application can do what my users want.

Where did I fail on this? Well I didn’t put in my tracking information till recently. If you are working on an application I recommend GA for Flash.

To Do Item(s):

- Add in code to gather use statistics
- Don’t gather more information than is necessary, this just will cause extra unneeded application chatter

Optimize Visuals
My good friend Dimi would be proud of me and all the work I did on the icons. Just for the record he designed most of the app and how it looked, I just pieced it all together. The issue was that some of the icons came out as “crunchy” (thanks Antonio).

I knew to not scale the images yet the icons still came out as “crunchy”.

One night I decided to sit down and figure out the problem, it didn’t take long. The icons that I was using was built at an odd size. Due to the odd size the device has having issues displaying the icon as the device also does some scaling of the icon. However when I rebuilt the icons with their size based on a power of 2 (specifically 36×36) the icon’s “crunchy” look went away and was smooth again.

To Do Item(s):

- Look over all images, make sure they are a multiple of 2 (16×16, 36×36, etc)

Test on multiple screens
Testing on multiple devices is the bane of my existence. No matter how many devices I get my hands on there is always one more device that makes my app look just a little bit different and horrible at the same time. At a certain point you are going to need to decide for yourself how many devices is “good enough” and move forward.

I’d recommend testing on at least 3 different phones and 1 tablet. These different sizes and resolutions should help get most of the kinks out. When you see your app on these different resolutions and sizes you’ll probably realize the same two things that I did. Things that were “a bit” on the small size are unusable on some devices and things that “a bit” on the large size actually look okay.

For the most part I’ve been really happy with the look of my app across many devices. The Flex Team is doing a good job of keeping design stable across multiple screens.

To Do Item(s):

- Get devices
- Test on devices

Never accept “okay”
There are a few times that I’ve had to make the hard decision “I will cut a corner here so I can get this important bug fixed there”. I thought that my users wouldn’t notice and that they would be happy to get one bug fixed even if it meant that the update wasn’t very significant.

I was wrong.

My users did notice and they punished me for it. Users aren’t happy for incremental changes and they will comment and rate your application on two levels. The first is an overall score while the second is how much has the app improved from the last update. If the user doesn’t deem the update important enough you’ll get a nice 1-star rating for wasting their time with the update. Not nice but it is reality.

After seeing this phenomenon I’ve been very happy to rate applications that I enjoy with 5 stars, even if the updates seem trivial.

To Do Item(s):

- Plan your updates
- Realize that everything is significant and you can’t skip out anywhere

Accept that your users are going to destroy your app
This point was very interesting and something I didn’t expect. I had a user contact me that the app didn’t work for them. After a few more emails back and forth I couldn’t understand what the problem was and was left to just apologizing to the user. Then the user gave me a break through. He had a custom build of the Android OS that gave him a few extra abilities – including the ability to turn on and off permissions to applications.

Apparently he decided that my application didn’t need the ability to access the internet but was upset with me when the application couldn’t access the Netflix API.

The lesson? Sometimes there is nothing you can do.

To Do Item(s):

- Accept defeat

Unit Test (where possible)
Don’t have to go far into this subject. Unit tests work, use them. Even if you think you’re a “good developer” they will help.

To Do Item(s):

- Write your tests

Have a release checklist
This may not seem like very important but I’ve always found release checklists to be helpful. There were a few times in early releases that I didn’t follow any checklist and I accidentally left in debug information or my testing api key or a few other issues. All of these caused for some bad releases followed by an immediate secondary release followed by upset users.

I recommend writing a script for you to follow when you are making a release. Make sure all of your testing bits are in the script, any settings you have to change, and double check your application descriptor. Once your checklist is completed then make your release.

I originally didn’t do all this with my app as I considered it a “small” app and suspected I could remember all these steps off the cuff. I quickly learned that there is no such thing as a small app and every detail matters.

To Do Item(s):

- Make a script
- Follow your script each time

Include your contact information
Finally, give your users a way to contact you. I’ve found over the entire process that I have some very kind users and also some users that have great ideas and points for improvements. They appreciate that the ability to give feedback and contribute often. I receive roughly 10 emails a day from my users with ideas and requests.

To Do Item(s):

- Include your contact information somewhere

Flex 4.5 PersistenceManager

jonbcampos — Mon, 01 Nov 2010 15:26:48 +0000

The PersistenceManager is the data center backbone to your mobile Flex application. The reason you need to think about the persistance layer of your mobile app more than you needed to before in web and desktop development is because of the high probability of interruption and application closure.

In web and desktop development if something else happened on the user’s computer the user could simply switch windows to handle the interruption and continue their task. This happens so frequently that developers actually never think of this as a issue. However with mobile development there is always the chance of a phone call coming in, or email, or any other application that may take focus away from your application. While you application is not in immediate use you now fall prey to the operating system’s whim. If the OS decides that your application needs to close for memory or power reasons then the state of your application and any data it was holding may now be lost unless you have created an aggressive data persistance layer.

On top of that, the views within your application are created and destroyed quite frequently. That means if you were a developer that was used to grabbing data from offscreen or invisible views then your data will no longer be available when these other views are destroyed. Another reason why you need to be very aggressive about moving data into a proper data model and away from the view.

Getting into it let’s look at the PersistenceManager, what it is, and how we can alter it to do our bidding.

PersistenceManager
First off the PersistenceManager is a simple way to interact with an LSO (Local Shared Object). This is the default way to persist data across views and sessions. There are only a handful of functions to worry about to get use this class.

//--------------------------------------------------------------------------
//
// Methods
//
//--------------------------------------------------------------------------

/**
* Clears all the data that is being stored by the persistence
* manager.
*
* @langversion 3.0
* @playerversion Flash 10.1
* @playerversion AIR 2.5
* @productversion Flex 4.5
*/
function clear():void;

/**
* Flushes the data being managed by the persistence manager to
* disk or another external storage file.
*
* @langversion 3.0
* @playerversion Flash 10.1
* @playerversion AIR 2.5
* @productversion Flex 4.5
*/
function flush():void;

/**
* Initializes the persistence manager.
*
* @langversion 3.0
* @playerversion Flash 10.1
* @playerversion AIR 2.5
* @productversion Flex 4.5
*/
function initialize():void;

/**
* Returns the value of a property stored in the persistence manager.
*
* @param key The property key
*
* @langversion 3.0
* @playerversion Flash 10.1
* @playerversion AIR 2.5
* @productversion Flex 4.5
*/
function getProperty(key:String):Object;

/**
* Stores a value in the persistence manager.
*
* @param key The key to use to store the value
* @param value The value object to store
*
* @langversion 3.0
* @playerversion Flash 10.1
* @playerversion AIR 2.5
* @productversion Flex 4.5
*/
function setProperty(key:String, value:Object):void;

This makes it very easy to set and get data from the persistence layer.

var p:PersistanceManager = new PersistenceManager(); /* this is a singleton */
p.setProperty("key", 1232131.123);

...
...

var p:PersistanceManager = new PersistenceManager(); /* this is a singleton */
var key:Number = p.getProperty("key") as Number;

Roll Your Own
Don’t like using LSOs? Prefer SQLite Databases or some other storage plan? No problem. You don’t have to roll your own completely if you don’t want to – though you could. You can still use the PersistenceManager, just make sure to use the interface: IPersistenceManager. The functions are all the same but now you can make your own and do whatever you want. This is a wonderful example of programming to an interface rather than an implementation.

While the simple functions provided by the IPersistenceManager may not be robust enough for your application then you can just completely write your own class. I prefer to stick to the provided interfaces because then other developers that help out don’t have to learn an entire new set of methods.

Looking at getting started with Flash Builder Burrito and the new Flex SDK? Check out this post on Flex Hero development.

Looking at getting going with non-Hero development or don’t have the new Flash Builder Burrito? Check out this post on getting started with Air for Android.

Optimization Techniques for Air for Android apps

jonbcampos — Wed, 08 Sep 2010 14:53:57 +0000

Day one everything I heard about mobile development was performance, memory optimization, and battery consumption. Spread all over the internet are a variety of articles and presentations with a variety of [great] optimization techniques.

As with my previous posts on performance optimization I like to focus on the big gains and these techniques that are practical. I say practical because you can’t always spend a year working on each component and optimizing every interaction, but what you can do is focus on the big gains and when time permits – the details. I don’t mean to play down the importance of code optimization; especially for mobile applications optimization is of the highest importance.

In no particular order of importance let’s look at some excellent places for performance and memory allocation gains.

Keep framerate as low as possible
For anyone that hasn’t looked into it, the default framerate for the Flash Player is 24 frames per second. That means that 24 times every second new code is being executed, regions are being redrawn, and user interactions are being calculated. So it stands to reason that the quickest way to reduce memory consumption, code execution, and redrawing algorithms is to reduce the framerate and therefore the amount of times per second that all these calculations are being run.

What few developers know is that you can change your framerate dynamically dependent on what is happening within your application. The first recommendation is to set your framerate to something low but tolerable – like 4 frames per second. Then when a transition or other animation is going to play increase your framerate to keep your animation smooth.

stage.frameRate = 4;

Monitoring your framerate is very important as many flash designers want to ramp up the framerate to 60 frames per second because it will make the animations “pretty”.

Avoid timers
Each timer that you add and use in your application connects into the Flash Player environment and calculates time on each frame, thus adding additional computations on each frame for each timer you create. Real fast you can multiply these calculations if you aren’t careful.

To improve performance avoid high rate timers, this will reduce the amount of events being fired and the quantity of code being executed.

The second performance increase is to have one timer for the entire application. Think of it as a heartbeat for your application keeping the internal timing for all your functions. This will reduce the amount of timers you have and the amount of time calculations taken from the Flash Player environment.

Blends and Filters
It has long been known that as filters and blends cause for an extra amount of lifting from the Flash Player, lifting that can truly slow down performance. So where possible avoid blends and filters. “But I want to have a 2px drop shadow around this box.” Does it really need to be a filter? Can you not use a dark line that is 2 pixels thick? I know this sounds elementary but many people seem to forget that there are other more creative solutions that might get you to the same goal.

Cache As Bitmap
If you’ve been in the Flash Player world for a while you will remember the day you saw Adobe’s cacheAsBitmap presentation and how quickly everything rendered. My mind was blown and I had found my magic bullet to all my slow rendering woes.

Well not exactly. cacheAsBitmap is amazing and in many situations can be very helpful. How does it achieve it’s amazing win? By caching a bitmap off screen that can be used as opposed to needing to recreate the bitmap over and over again. The issue comes if you change the alpha/rotation/colors on your bitmap. Now the renderer needs to make a new bitmap to cache and you are doing extra lifting to cache and draw rather than just draw. What this means for you is if you are going to be making lots of alpha/rotation/colors changes then you might not want to set cacheAsBitmap to true.

myBall.cacheAsBitmap = true;

One other little used cache method is cacheAsBitmapMatrix. Similar to the cacheAsBitmap this will also cache the x, y, rotation, scale, skew properties. Keeping the Flash Player from having to redraw the object. Again, if you make any changes to alpha/color or the children sprites matrix the object will be redrawn and you will be spending more time and memory to cache an object that is constantly redrawn.

myBall.cacheAsBitmap = true;
myBall.cacheAsBitmapMatrix = new Matrix();

Asset Management
Asset management is extremely important with mobile because all those images can eat up memory quick.

First: Make sure your images are the right size. I’ve seen many developers take icons that are 40×40 and just resize them to 20×20 at runtime. I know this seems picky and obvious but this is a quick way to double your memory and hurt rendering performance with unnecessary calculations. Just make sure that images are set to their proper size.

Second: Don’t embed fonts/images/media you aren’t using. It’s easy to forget about all the items you are embedding. Be an asset nazi.

Third: Compress Compress Compress. Do you really need that high quality sound file? Or that PNG with the transparency layer when there is no transparency? Compress those media files. Use JPGs rather than PNG when possible. And if you are just trying to see the background through an icon, think or building the icon with the correct background already in the file. Transparency is another calculation that isn’t necessary if you can be sure of the end goal.

Don’t forget that images split by the power of 2 are going to be more efficient on memory than odd sized images. This can’t always be avoided by it’s good to remember. This is definitely a nit-picky thing.

“Make bitmaps in sizes that are close to, but less than, 2n by 2m bits. The dimensions do not have to be power of 2, but they should be close to a power of 2, without being larger. For example, a 31-by-15–pixel image renders faster than a 33-by-17–pixel image. (31 and 15 are just less than powers of 2: 32 and 16.)”
-From the Developing Air Apps for Android Guide.

Events and Bubbling
I’m really interested to see how Mate responds to this one. We’ve known for a long time that events are costly and that lots of events and event bubbling through deeply nested component trees can lead to bottle necks and performance issues.

A quick way to deal with these issues is to not bubble your events when possible and when you do need to bubble, stop propagation when the events have reached a point that they don’t need to bubble anymore.

event.stopPropagation();

Simplifying your display tree whenever possible is a great way to improve performance. Don’t do this for just the events but for your entire application.

One other thing you can do is prevent mouse events (that are set to bubble by default) from effecting children you weren’t intending. Try setting mouseChildren and mouseEnabled to false.

Drawing API
For you masochists that love to write out Actionscript drawings I’d take particular notice of this part. Watch out how much you draw dynamically because each drawing is drawn to the stage and then rendered in the rasterizer. When you build assets at authoring time your assets are rendered and stored in memory rather than created on the fly.

Color Selection
This gain is specifically to do with battery life. The color white takes more power to show than the color black. Am I saying to have all your applications look like tributes to The Dark Knight? Nope. Just giving your designers a warning that their decisions directly effect performance and battery consumption.

Embedded Fonts and Device Fonts
Android devices have fonts that are embedded within the system, these fonts will require the smallest amount of memory because it won’t require embedding any additional fonts and they render remarkably fast. Use these fonts when possible.

But what if you have a picky designer that has to have the fonts his way? Embed your fonts for the fastest rendering and follow best practices to limit the glyphs that you include with your embed.

You can find out what fonts your Android system has in the /system/fonts folder.

Garbage Collection
First off I think I need to say “stop running the garbage collection”. Yes developers, I know you want your application to clean itself up immediately. However, I’ve seen more than one app become sluggish because of an over worked garbage collector. So all those tricks that you’ve found to run the garbage collector, stop. The Flash Player runs the garbage collection when it needs to. If something isn’t going away the way you expect maybe you should check for other leaks caused by listener references or other common leaks.

Memory Allocation
Not enough programmers take advantage of Object Pooling. This is probably why I was impressed with PushButton Engine right from day one, everything is based off object pools. This is an easy and tested way to reuse objects and save your application from the costly ‘new’ function.

What do I mean by the costly new function? Whenever you use the “new” function and create a new object you are running a costly operation. Multiple things happen deep within the Flash Player including heap/memory allocation, garbage collection, and component creation. If you know you are going to be creating and destroying something frequently make the change to Object Pools early and save yourself the memory and performance woes.

A few months back I wrote another article doing a series of performance tests. I devote an entire section of tests to the “new” operator in Practical Performance Tweaks.

Video
This is something that your designers are going to hate: stop messing with the video player! All those crazy graphics, overlays, and blends that you may put over your video to add the grunge border will need to go. If you are worried about performance these are a quick way to cause redraws and layering calculations on each video frame.

When encoding your video thing of the final endpoint. Most devices have a native codec (usually H.264) that will help improve decompression and playback on the hardware level rather than the software level. Make sure to target these native codecs and see the performance and battery life improvement.

Show Redraw Regions
This is pretty low on the priority list but very important if you get it wrong. Flex visual components build off of the Flash Sprite class. As such they are interactive objects without animation timelines. However, when working with Flash based components, Flex developers often forget the MovieClip Class – the lowest class to include a timeline. This class can be set to run causing all sorts of redraws on each frame of animation until it is eventually told to stop playing.

When working with visual components from Flash or especially components that are based off of Movieclip make sure to stop the timeline when the component is not visible. Even when invisible the timeline is running and redraws are occurring. Using the Show Redraw Regions will expose this.

movieClipComponent.stop();

It is also best practices to look over your application as a whole and make sure that components aren’t needlessly being redrawn. This may be caused by a bad property or a misbehaving function. Check that only regions that change are actually getting redrawn for some pretty nice performance increases.

Open To Comments
I’d be interested to see where else others have seen visible improvements when using specific performance improvement methods. Feel free to comment! All the methods displayed above I have personally tested and seen the difference between using them and not using them.

@includeExample

jonbcampos — Tue, 10 Aug 2010 14:00:02 +0000

In my continuing quest to do everything I can to make components I make easier to understand and quicker to use, my most recent addition to my docs was to use @includeExample.

Adding in @includeExample is super simple if you’ve been actively testing your component. There are a few things you may need to do to enable the examples inclusion but the process should only take a few moments to set up.

I have an open ASDoc Jira Bug around this topic. The issue is that I want to see the example working in the asdoc but the current asdoc tool doesn’t actually make the SWFs and the embed information. It is partially there and commented out. I would like to see this completed.
Link To Jira Bug – vote for it

To include your examples is simple.

First, your need to duplicate your src directory. On the base directory add in a folder called examples. This is where your examples will go – in the same structure as your library classes.

Second, you need to write your example. For my example I am building an example for my AutocompleteList.

The example:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:unitedmindset="library://ns.unitedmindset.com"
creationComplete="application1_creationCompleteHandler(event)">
<fx:Script>
[CDATA[
import mx.collections.ArrayCollection;
import mx.events.FlexEvent;

[Bindable]
public var dataProvider:ArrayCollection;

protected function application1_creationCompleteHandler(event:FlexEvent):void
{
var source:Array = [];
source.push({label:"Adult"});
source.push({label:"Aeroplane"});
source.push({label:"Air"});
source.push({label:"Aircraft Carrier"});
source.push({label:"Airforce"});
source.push({label:"Airport"});
source.push({label:"Album"});
source.push({label:"Alphabet"});
source.push({label:"Apple (is evil)"});
source.push({label:"Arm"});
source.push({label:"Army"});
source.push({label:"Baby"});
source.push({label:"Backpack"});
source.push({label:"Balloon"});
source.push({label:"Banana"});
source.push({label:"Bank"});
source.push({label:"Barbecue"});
source.push({label:"Bathroom"});
source.push({label:"Bathtub"});
source.push({label:"Bed"});
source.push({label:"Bee"});
source.push({label:"Bible"});
source.push({label:"Bird"});
source.push({label:"Bomb"});
source.push({label:"Book"});
source.push({label:"Boss"});
source.push({label:"Bottle"});
source.push({label:"Bowl"});
source.push({label:"Box"});
source.push({label:"Boy"});
source.push({label:"Brain"});
source.push({label:"Bridge"});
source.push({label:"Butterfly"});
source.push({label:"Button"});
source.push({label:"Cappuccino"});
source.push({label:"Car"});
source.push({label:"Car-race"});
source.push({label:"Carpet"});
source.push({label:"Carrot"});
source.push({label:"Cave"});
source.push({label:"Chair"});
source.push({label:"Chess Board"});
source.push({label:"Chief"});
source.push({label:"Child"});
source.push({label:"Chisel"});
source.push({label:"Chocolates"});
source.push({label:"Church"});
source.push({label:"Circle"});
source.push({label:"Circus"});
source.push({label:"Clock"});
source.push({label:"Clowns are scary"});
source.push({label:"Coffee"});
source.push({label:"Coffee-shop"});
source.push({label:"Comet"});
source.push({label:"Compact Disc"});
source.push({label:"Compass"});
source.push({label:"Computer"});
source.push({label:"Crystal"});
source.push({label:"Cup"});
source.push({label:"Cycle"});
source.push({label:"Data Base"});
source.push({label:"Desk"});
source.push({label:"Diamond"});
source.push({label:"Dress"});
source.push({label:"Drill"});
source.push({label:"Drink"});
source.push({label:"Drum"});
source.push({label:"Dung"});
source.push({label:"Ears"});
source.push({label:"Earth"});
source.push({label:"Egg"});
source.push({label:"Electricity"});
source.push({label:"Elephant"});
source.push({label:"Eraser"});
source.push({label:"Explosive"});
source.push({label:"Eyes"});
source.push({label:"Family"});
source.push({label:"Fan"});
source.push({label:"Feather"});
source.push({label:"Festival"});
source.push({label:"Film"});
source.push({label:"Finger"});
source.push({label:"Fire"});
source.push({label:"Floodlight"});
source.push({label:"Flower"});
source.push({label:"Foot"});
source.push({label:"Fork"});
source.push({label:"Freeway"});
source.push({label:"Fruit"});
source.push({label:"Fungus"});
source.push({label:"Game"});
source.push({label:"Garden"});
source.push({label:"Gas"});
source.push({label:"Gate"});
source.push({label:"Gemstone"});
source.push({label:"Girl"});
source.push({label:"Gloves"});
source.push({label:"God"});
source.push({label:"Grapes"});
source.push({label:"Guitar"});
source.push({label:"Hammer"});
source.push({label:"Hat"});
source.push({label:"Hieroglyph"});
source.push({label:"Highway"});
source.push({label:"Horoscope"});
source.push({label:"Horse"});
source.push({label:"Hose"});
source.push({label:"Ice"});
source.push({label:"Ice-cream"});
source.push({label:"Insect"});
source.push({label:"Jet fighter"});
source.push({label:"Junk"});
source.push({label:"Kaleidoscope"});
source.push({label:"Kitchen"});
source.push({label:"Knife"});
source.push({label:"Leather jacket"});
source.push({label:"Leg"});
source.push({label:"Library"});
source.push({label:"Liquid"});
source.push({label:"Magnet"});
source.push({label:"Man"});
source.push({label:"Map"});
source.push({label:"Maze"});
source.push({label:"Meat"});
source.push({label:"Meteor"});
source.push({label:"Microscope"});
source.push({label:"Milk"});
source.push({label:"Milkshake"});
source.push({label:"Mist"});
source.push({label:"Money $$$$"});
source.push({label:"Monster"});
source.push({label:"Mosquito"});
source.push({label:"Mouth"});
source.push({label:"Nail"});
source.push({label:"Navy"});
source.push({label:"Necklace"});
source.push({label:"Needle"});
source.push({label:"Onion"});
source.push({label:"PaintBrush"});
source.push({label:"Pants"});
source.push({label:"Parachute"});
source.push({label:"Passport"});
source.push({label:"Pebble"});
source.push({label:"Pendulum"});
source.push({label:"Pepper"});
source.push({label:"Perfume"});
source.push({label:"Pillow"});
source.push({label:"Plane"});
source.push({label:"Planet"});
source.push({label:"Pocket"});
source.push({label:"Post-office"});
source.push({label:"Potato"});
source.push({label:"Printer"});
source.push({label:"Prison"});
source.push({label:"Pyramid"});
source.push({label:"Radar"});
source.push({label:"Rainbow"});
source.push({label:"Record"});
source.push({label:"Restaurant"});
source.push({label:"Rifle"});
source.push({label:"Ring"});
source.push({label:"Robot"});
source.push({label:"Rock"});
source.push({label:"Rocket"});
source.push({label:"Roof"});
source.push({label:"Room"});
source.push({label:"Rope"});
source.push({label:"Saddle"});
source.push({label:"Salt"});
source.push({label:"Sandpaper"});
source.push({label:"Sandwich"});
source.push({label:"Satellite"});
source.push({label:"School"});
source.push({label:"Sex"});
source.push({label:"Ship"});
source.push({label:"Shoes"});
source.push({label:"Shop"});
source.push({label:"Shower"});
source.push({label:"Signature"});
source.push({label:"Skeleton"});
source.push({label:"Slave"});
source.push({label:"Snail"});
source.push({label:"Software"});
source.push({label:"Solid"});
source.push({label:"Space Shuttle"});
source.push({label:"Spectrum"});
source.push({label:"Sphere"});
source.push({label:"Spice"});
source.push({label:"Spiral"});
source.push({label:"Spoon"});
source.push({label:"Sports-car"});
source.push({label:"Spot Light"});
source.push({label:"Square"});
source.push({label:"Staircase"});
source.push({label:"Star"});
source.push({label:"Stomach"});
source.push({label:"Sun"});
source.push({label:"Sunglasses"});
source.push({label:"Surveyor"});
source.push({label:"Swimming Pool"});
source.push({label:"Sword"});
source.push({label:"Table"});
source.push({label:"Tapestry"});
source.push({label:"Teeth"});
source.push({label:"Telescope"});
source.push({label:"Television"});
source.push({label:"Tennis racquet"});
source.push({label:"Thermometer"});
source.push({label:"Tiger"});
source.push({label:"Toilet"});
source.push({label:"Tongue"});
source.push({label:"Torch"});
source.push({label:"Torpedo"});
source.push({label:"Train"});
source.push({label:"Treadmill"});
source.push({label:"Triangle"});
source.push({label:"Tunnel"});
source.push({label:"Typewriter"});
source.push({label:"Umbrella"});
source.push({label:"Unitedmindset"});
source.push({label:"Vacuum"});
source.push({label:"Vampire"});
source.push({label:"Videotape"});
source.push({label:"Vulture"});
source.push({label:"Water"});
source.push({label:"Weapon"});
source.push({label:"Web"});
source.push({label:"Wheelchair"});
source.push({label:"Window"});
source.push({label:"Woman"});
source.push({label:"Worm"});
source.push({label:"X-ray"});
dataProvider = new ArrayCollection(source);
}

]]>
fx:Script>
<fx:Declarations>
-- Place non-visual elements (e.g., services, value objects) here -->
fx:Declarations>
<s:layout>
<s:VerticalLayout paddingBottom="20" paddingLeft="20" paddingRight="20" paddingTop="20"/>
s:layout>
<unitedmindset:AutocompleteList dataProvider="{dataProvider}"/>
s:Application>

Thirdly, you need to specify that there is an example in the class level asdoc. All you need to do is give the name of the example file. Since the examples files are mirrored against the original classes the asdoc tool knows the folder structure to find the example.

* pre>
*
* @see com.unitedmindset.skins.AutocompleteListSkin.mxml
*
* @includeExample AutocompleteList.mxml
*
* @author jonbcampos
*/
public class AutocompleteList extends List
{
private static const COMPARELABEL_CHANGE_EVENT:String = "compareLabelChange";
private static const COMPAREFUNCTION_CHANGE_EVENT:String = "compareFunctionChange";

public function AutocompleteList()
{
super();

- Optional – Adjust your compiler arguments. If for whatever reason your examples aren’t part of your project or live somewhere else you may need to add some arguments to your compiler. Specifically the -examples-path. By default the asdoc tool looks for the examples folder, but if you put the examples in a different folder just specify it as such:

Your folder is titled “myexamples” in the base directory, the compiler:

-examples-path myexamples

Or if your folder is at c:/myexamples, the compiler:

-examples-path c:/myexamples

The rest of the structure is matched for you.

And now your example is included with your asdocs page.

Related Posts:
Intellisense – Making your components work with the Flash Builder IDE
Building ASDocs with ANT

Practical Performance Tweaks

jonbcampos — Mon, 30 Nov 2009 16:02:39 +0000

I’ve had a little bit of time on my hands in my day job *cough choke laugh* and thought I would spend some time doing some low level improvements on the performance of my applications. Though there were some changes I made that might have improved the performance of a function by a few milliseconds on average there were a few things that I changed that made large improvements. These are the sorts of fixes that you commit to memory and just always keep them as time moves forward.

I’m not talking about making sure that you removeEventListeners and nullify unused objects for garbage collection, that is a given. These are common tweaks that people could use in every application but often we don’t because we suspect that the performance hit isn’t as big as it is. Here we will look at how big that hit actually is.

For all these tests I used Grant Skinner’s Performance Testing Harness. The numbers for the tests are provided along with the source code and the test available to run. I slightly modified the Testing Harness so that I could also get the times and numbers out of each test for graphing purposes.

Array vs ArrayCollection vs ICollectionView
These tests all started when I wondered how much slower iterating through an ArrayCollection was than iterating through an Array. The numbers were staggering. In some cases, iterating through the Array was 1/50th of the time or 5000% faster.

For my test I also was curious if using an interface instead of using the actual object made a difference. As you can see from the numbers that the difference wasn’t hugely significant, but actual.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.ArraysTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different array tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
findLastArray 81 16.20
findLastArrayCollection 4484 896.80
findLastICollectionView 4405 881.00
findLastVector 106 21.20
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

One rumor that I heard was that ArrayCollections are faster at finding a specific index value than Array’s due to some sort of magical optimization. So I tested that rumor also, below are the results. As you will see, this rumor is false. Arrays are faster at accessing a specific index value than ArrayCollections.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.ArraysTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different array tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
findObjectAtArray 64 12.80
findObjectAtArrayCollectionOperand 4200 840.00
findObjectAtArrayCollectionGetItemAt 1700 340.00
findObjectAtICollectionView 4151 830.20
findObjectAtVector 84 16.80
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Already there are additional tests I am thinking about running, but on the whole you can see that using the base Array over ArrayCollection will yield large performance improvements.

However, I again want to point out that whenever you set an Array as the dataProvider of a Flex component, Flex components convert Arrays to ArrayCollections. So don’t try to get a performance increase from a component specifically by setting the dataProvider as an Array, the Array will be transformed either way.

Loops
The next section that I was going to test was the age old debate about the perfect loop: For Loops vs While Loops, iterating before the loop vs after the loop, etc etc. Luckily for me, as soon as I started looking at Grant’s testing harness, he had already created most of the test cases for me (Thanks). So the only extension to the test that I had to make was to also test against iterating before or after the loop (++i vs i++). The results can be seen below.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.LoopsTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different loop structures.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
forIncrementAfter 439 87.80
forDecrementAfter 439 87.80
forIncrementBefore 445 89.00
forDecrementBefore 435 87.00
*
whileIncrementAfter 647 129.40
whileDecrementAfter 456 91.20
whileIncrementBefore 649 129.80
whileDecrementBefore 456 91.20
*
doWhileIncrementAfter 465 93.00
doWhileDecrementAfter 480 96.00
doWhileIncrementBefore 483 96.60
doWhileDecrementBefore 479 95.80
*
forIn 623 124.60
forEachIn 669 133.80
forEachInUntyped 647 129.40
forEachInPosttyped 1255 251.00
*
arrForEach 1722 344.40
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

What you will probably notice is that no specific loop includes massive performance improvements, though the simple for loop seemed to be the fastest on average. So take your pick and run with it.

Unrolled Loops
The next tests that I came up with was to see how efficient rolled vs unrolled loops were. The reason I felt this was important is there are times that we needlessly iterate through a loop when we know there will always be X number of elements. When this is a the case I’ve found (and the tests prove) that it is faster to just do what you need with the X elements rather than write a loop to iterate through the elements.

Remember to check the source to see the implementations of these different tests.

Length Reference Variable
This is definitely a nit picky test, but I had to know the truth! When iterating through a loop is it significantly better to get a reference to the length of the loop, or is it okay just to use array.length in each iteration. As proven, using a variable to store the length is significantly better.

Reference Variables
When iterating through a loop I often like to pull a reference to the current value that is being evaluated in a loop. I do this mainly to make reading the code easier, but I was curious if this creation of a new reference would be harmful to performance. On top of that I was curious if giving these temporary variables a type was helpful for performance or not. Below are the results.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.LoopsTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different loop structures.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
noTemporaryLoopVariableUntyped 1988 397.60
noTemporaryLoopVariableTyped 1937 387.40
temporaryLoopVariableUntyped 1849 369.80
temporaryLoopVariableTyped 1897 379.40
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

As you can see I’ve figured that there isn’t a significant performance increase or loss with using temporary variables. I think I’ll keep using my temporary variables to make reading easier.

Type, Cast and toX
The next series of tests are extremely geeky tests with some startling results. Is it faster to say (object as String) or String(object) or object.toString? This test case and many others are included below for each of the base types. May this help you decide how to type and cast your variables.

The big one to notice is the amount of time it takes to String(number) instead of saying (number as String).

Included with each test is the control case of casting and typing each type to the same base type.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.TypesTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different type, casting, and manipulation tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
stringToString 96 19.20
stringCastString 68 13.60
stringAsString 76 15.20
objectStringToString 153 30.60
objectStringCastString 70 14.00
objectStringAsString 78 15.60
numberCastString 888 177.60
numberAsString 104 20.80
intCastString 229 45.80
intAsString 86 17.20
uIntCastString 229 45.80
uIntAsString 86 17.20
*
numberCastNumber 46 9.20
numberAsNumber 103 20.60
objectNumberCastNumber 50 10.00
objectNumberAsNumber 81 16.20
intCastNumber 46 9.20
intAsNumber 84 16.80
uIntCastNumber 46 9.20
uIntAsNumber 86 17.20
stringCastNumber 76 15.20
stringAsNumber 84 16.80
*
uintCastUint 45 9.00
uintAsUint 86 17.20
objectUintCastUint 48 9.60
objectUintAsUint 82 16.40
numberCastUint 47 9.40
numberAsUint 113 22.60
intCastUint 45 9.00
intAsUint 84 16.80
stringCastUint 82 16.40
stringAsUint 90 18.00
*
intCastInt 46 9.20
intAsInt 82 16.40
objectIntCastInt 48 9.60
objectIntAsInt 80 16.00
numberCastInt 47 9.40
numberAsInt 106 21.20
uintCastInt 46 9.20
uintAsInt 86 17.20
stringCastInt 77 15.40
stringAsInt 88 17.60
*
arrayAsArray 77 15.40
objectArrayAsArray 81 16.20
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Remember when using “as”, if the conversion fails, you will receive a null rather than the value. Unless you explicitly know what the type will be, it is always good to make this check.

The “new” operator
I’ve always been told that when creating a new base type that you should use the value rather than new because it saves the need for the VM to allocate the memory in the heap. But what was the ACTUAL performance improvements. Again, the numbers are staggering. For the next tests I created each of the simple types 3 different ways.

The first way I used the new operator as such: var s:String = new String();
The second way I used the new value as such: var s:String = “”;
And the final test was to create the variable with the new operator without the final parenthesis, such as: var s:String = new String;

For every test setting the value rather than using the new operator was almost twice as fast. The biggest difference being with creating a new Array, using the [] operand instead of the new operator was almost 3 times as fast.

I should also point out that for almost each test, using the parenthesis was slower than leaving them off when creating a new variable, though this is considered bad practice. Though the difference was marginal.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.TypesTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different type, casting, and manipulation tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
newUintTest 75 15.00
newUintValueTest 44 8.80
newUintTestNoParams 76 15.20
*
newIntTest 75 15.00
newIntValueTest 45 9.00
newIntTestNoParams 74 14.80
*
newNumberTest 72 14.40
newNumberValueTest 45 9.00
newNumberTestNoParams 75 15.00
*
newStringTest 71 14.20
newStringValueTest 45 9.00
newStringTestNoParams 74 14.80
*
newArrayTest 711 142.20
newArrayValueTest 249 49.80
newArrayTestNoParams 709 141.80
*
newObjectTest 267 53.40
newObjectValueTest 230 46.00
newObjectTestNoParams 263 52.60
*
newXMLTest 1032 206.40
newXMLValueTest 1023 204.60
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Static Methods vs Class Methods
As a side curiosity I was wanted to know if there was any performance loss or gain based on the types of functions used within a class. I was able to see that there weren’t any significant performance improvements over one type of function or another. So stick with best practices within your classes and only make methods and properties public when they absolutely have to be.

This test does not include testing whether creating the class and then accessing the function is better than a static function which does not need to instantiate a class.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.ClassTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different class method tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
publicMethod 141 28.20
privateMethod 143 28.60
protectedMethod 144 28.80
publicStaticMethod 141 28.20
privateStaticMethod 142 28.40
protectedStaticMethod 141 28.20
publicInternalMethod 142 28.40
publicFinalMethod 144 28.80
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Using “this” and Other Class Curiosities
This next section includes many different tests to improve my class creation.

Setting the default values
In this test I was curious if it is better to initially set a variable in the constructor or at the variable, and also if setting the variable defaults inside the class vs outside the class was better. What I found is that it is faster to initially just set the variables to their default value rather than making this change in the constructor.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.VariablesTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different variables and vo based tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
defaultVarsSetVO 400 80.00
varsSetInConstructorVO 490 98.00
varsSetOutsideConstructorThisVO 499 99.80
varsSetOutsideConstructorNoThisVO 496 99.20
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Is using “this” wrong?
Checking whether it was faster to use the “this” identifier was harmful to performance I concluded that there was no significant performance loss or gain in using the “this” identifier.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.VariablesTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different variables and vo based tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
thisToString 2395 479.00
noThisToString 2441 488.20
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Getters and Setters vs Direct Accessors
Lots of good ole’ boy Java developers will tell you that every property has to have a getter and setter. Other programmers will say that this is only necessary if there is some logic that needs to run in the get/set process. Now you can see that by using a getter/setter when a direct accessor can be used is wasteful for performance and typing. Therefore, only create getters/setters when it is important to run some logic in the getting/setting process.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.VariablesTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different variables and vo based tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
noGetSetAccessors 2382 476.40
getSetAccessors 2786 557.20
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Size really doesn’t matter… in variables.
Finally, the stigma from writing Javascript applications always left me feeling guilty about using full words when a letter can do. In Javascript this was a performance issue and caused many programmers to use single incomprehensible letters instead of easy to read words. To elevate my guilt I decided to test if using long variable names made any difference at runtime. The answer is no. No savings, no loss. Now, guilt free, I will always use well written variable names instead of short single letter descriptors.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.VariablesTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different variables and vo based tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
shortVarNames 45 9.00
longVarNames 45 9.00
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

If..Then vs Switch..Case
Like loops, developers argue which logical test is better: if..then vs switch..case. Pitting the two against each other, apples vs apples, I’ve found that if..then statements are slightly faster than switch..case statements. I will still use each statement where appropriate though, but it is good to know in the situations that I have the choice that I should use if..then statements.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.LogicalTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different logical structure tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
switchCaseStatement 411 82.20
ifThenElseStatement 378 75.60
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Math.max() vs Math.max.apply()
One little known secret to AS3 is the apply method. Most classes have more than one way to skin a cat, and the apply method is that function. In the case of Math.max (or Math.min) I was curious how much faster the apply method was vs logically finding the largest (or smallest) value. The numbers were staggering. From now on I will be using the apply method whenever possible as it is a very low level and fast function.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––
com.unitedmindset.tests.ApplyTest (5 iterations)
Player version: MAC 10,0,32,18 (debug)
Test different apply method tests.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––
method..................................ttl ms...avg ms
findMaxLogically 2093 418.60
findMaxApply 131 26.20
–––––––––––––––––––––––––––––––––––––––––––––––––––––––

Final Thoughts
Obviously the things in this list I see as some of the greatest offenders and also the easiest to fix. It all comes down to you and which changes you feel comfortable making in your daily coding practices. Some of the more “nit picky” performance changes I feel can effect code readability and reusability, and which you implement into your code is up to you and your coding practices. Hopefully this ends the debate between some techniques as being the end all be all technique.

If there are other coding techniques that have left you wondering which is better, let me know and I’ll add it in. I’m sure over time I’ll revisit these test cases.

The Test, Run It For Yourself Or View Source

View Source (or right click swf)

Getting Through Black Magic: Font Embedding

jonbcampos — Tue, 24 Nov 2009 15:59:40 +0000

Be it in Fx2, Fx3 or Fx4, Font Embedding is an integral part of any application due to the annoying issues you will start running into by just using device fonts. And once you get your embedded font into the application you’ll never look back at the issue, but getting the embedded font into the application seems bring some developers to their knees.

There are two main ways that I see people embed fonts.

1) Straight @font-face embed via Flex CSS
2) Embedding the font into a Flash File, selecting the glyphs to embed, and then embedding the resulting SWF into Flex.

People use the first one for simplicity and the second (definitely more difficult route) for optimization. Yet people keep forgetting (or never knew) that there is a third route that provides simplicity and optimization.

First, the basics…
In your Flex CSS file (or in the style block) start up a new font face block.

@font-face {
}

Next provide a direct path from your application’s root folder to the font. For ease I usually make a copy of the font and stick it in my assets folder so that other people connected to my project can still build the app.

@font-face {
src: url("/assets/fonts/verdana.ttf");
}

Now name the new font-face so it can be referenced as a font family.

@font-face {
src: url("/assets/fonts/verdana.ttf");
fontFamily: verdanaEmbed;
}

Next you need to add some description to the font. Is it a normal font?

@font-face {
src: url("/assets/fonts/verdana.ttf");
fontFamily: verdanaEmbed;
fontStyle: normal;
fontWeight: normal;
}

Bold?

@font-face {
src: url("/assets/fonts/verdanab.ttf");
fontFamily: verdanaEmbed;
fontStyle: normal;
fontWeight: bold;
}

Italic?

@font-face {
src: url("/assets/fonts/verdanai.ttf");
fontFamily: verdanaEmbed;
fontStyle: italic;
fontWeight: normal;
}

Bold and Italic?

@font-face {
src: url("/assets/fonts/verdanaz.ttf");
fontFamily: verdanaEmbed;
fontStyle: italic;
fontWeight: bold;
}

To have all four of these options you would need to embed each of the different fonts that include all these options. They can all be under the same fontFamily name, but with different configurations. But if you are missing the bold font and trying to make your text bold you will not be getting the desired look.

If you are confused at all by the different @font-face blocks below make sure to look at the actually font file name. You will notice each is just slightly different with the different look.

@font-face {
src: url("/assets/fonts/verdana.ttf");
fontFamily: verdanaEmbed;
fontStyle: normal;
fontWeight: normal;
}

@font-face {
src: url("/assets/fonts/verdanab.ttf");
fontFamily: verdanaEmbed;
fontStyle: normal;
fontWeight: bold;
}

@font-face {
src: url("/assets/fonts/verdanai.ttf");
fontFamily: verdanaEmbed;
fontStyle: italic;
fontWeight: normal;
}

@font-face {
src: url("/assets/fonts/verdanaz.ttf");
fontFamily: verdanaEmbed;
fontStyle: italic;
fontWeight: bold;
}

Next you need to set whether your font is using advanced anti aliasing. This takes slightly more processing, but can make your fonts look nicer at larger sizes. This is dependent also on whether the font type supports it. Usually, I just set this to true.

@font-face {
src: url("/assets/fonts/verdana.ttf");
fontFamily: verdanaEmbed;
fontStyle: normal;
fontWeight: normal;
advancedAntiAliasing: true;
}

Now with Fx4 you have something new to worry about: CFF. If this is set to true, the font will be available to the new TLF engine and Fx4 (Spark) components. If CFF is set to false then it will be available to Fx3 (Halo) components. Yes, right now you need to embed two fonts to get this to work for both. In the future this may change.

@font-face {
src: url("/assets/fonts/verdana.ttf");
fontFamily: verdanaEmbed;
fontStyle: normal;
fontWeight: normal;
advancedAntiAliasing: true;
cff: true
}

And now, the optimization…
You may have hit some issues with all the previous steps, or not – but here is the optimizations. Within the @font-face tag you can set which unicode characters to embed – this is like selecting the glyphs in Flash. To find a helpful table of common unicode characters and ranges that people use refer back to your flex sdk, specifically: flex-sdk-folder/frameworks/flash-unicode-table.xml. After looking through the table you can select your desired ranges that you want included with the font embed. The more unicode characters the larger the final SWF file will be, the fewer, the smaller.
My final @font-face embed statement.

@font-face {
src: url("/assets/fonts/verdana.ttf");
fontFamily: verdanaEmbed;
fontStyle: normal;
fontWeight: normal;
advancedAntiAliasing: true;
cff: true
unicodeRange:
U+0041-U+005A, /* Upper-Case [A..Z] */
U+0061-U+007A, /* Lower-Case a-z */
U+0030-U+0039, /* Numbers [0..9] */
U+0020-U+002F,U+003A-U+0040,U+005B-U+0060,U+007B-U+007E; /* Puctuation */
}

Profit!
That’s it, embedded and optimized fonts. I’ve actually tested the size of the resulting Flex App SWF files after going the long route and the route shown here. Both resulting sizes are exactly the same, down to the last byte.

Lockable List and Tree

jonbcampos — Fri, 23 Oct 2009 15:05:04 +0000

Anyone that knows me knows that I like making little test cases and components. Before I start showing off some of my custom spark components I wanted to make sure and share this custom component that I call the Lockable List. But, as every developer knows, when you have a list it is almost assured that you will need a tree. So I followed up with the list and built the Lockable Tree.

I have left the source code and everything available for these components, but wanted to draw people’s attention to the itemrenderers here. This is where the real magic is. Yes there is some functionality to List and Tree components that I have added, but the item renderers are really what make things possible. The List and Tree mainly add a wrapper to the data that is set (so the itemrenderers can work off the data provided) and retreive the data back in it’s original manner. Pretty simple.

The itemrenderers are nice. Lightweight. Definitely check out the itemrenderer’s code. Very simple.

What these components do is “hold” or “lock” a selection. In these examples you may say “well that is similar to shift/ctrl select”. Yes and no. If you need to hold nodes that may become difficult in large lists and in my apps I do lots of list filtering and sorting, so now I can filter for a specific node AND keep locked nodes. Very helpful.

Special thank you to John Gorena who already pointed out that this is something helpful for mobile development. Enjoy!

MAX Presentation – Tackling Memory & Performance in Flash, Flex, and AIR

jonbcampos — Thu, 08 Oct 2009 22:44:21 +0000

Let’s start by saying thank you to everyone that attended my MAX presentation: Tackling Memory & Performance with Flash, Flex, and AIR. This presentation was made possible by a joint effort of Jun Heider and myself. Below is a link to the Adobe.Tv recording of this presentation.

This was a presentation that almost wasn’t though. For those who don’t know, this presentation was originally planned to be presented by Sean Chistmann of EffectiveUI, yet as he fell sick Adobe called Jun and myself to fill in the gap. Working closely with Jun and Sean (when available) we added our own personal touches to the presentation and presented on Tuesday and Wednesday of Max. Again, thank you to everyone that attended either of the sessions and all the great feedback we received.

Tackling Memory and Performance in Flash, Flex, and AIR
Presentation Source Files

Below is a list of helpful resources for continued education in this subject:

Livedocs

Flex Profiler and flash.sampler.* classes:

AVM2 and MMgc:

Performance and Memory Management:

Data Transfer and Performance:

http://www.jamesward.org/census

Elastic Racetrack:

AIR/Flash Player Mac Idle CPU:

Flexcoders:

Adobe Bugbase (Please vote for these bugs!):

Flex Best Practices – Models, Views, and Controllers

jonbcampos — Tue, 18 Aug 2009 13:34:00 +0000

If you read through this entire post and don’t see anything for you, congrats and ignore this next comment.

No one seems to know how to actually implement MVC and I can’t stand it!

Too many programs out there set up like a procedural php page (front top to bottom): imports, sql statements, data, methods, and a ton of html. This is not how to set up a page, and even more so this isn’t how you set up an entire application! But people do it, don’t ask me how or why, but it’s a mess.

I want to let everyone know that the following “worst practice” example is actual code shown to me very recently. I simplified it a bit but ultimately the Flex application was one large mxml file.

You may try to argue that MVC takes more time to setup, more coding, “harder to read”, or whatever other arguments I have heard, but in the end it is easier to program, loosely coupled, simplistic, dry, object oriented, and finally best practice.

If your code looks like this, you are doing it wrong! (Worst Practice)

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
creationComplete="application1_creationCompleteHandler(event)">
<fx:Script>
[CDATA[
import mx.controls.Alert;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import mx.collections.ArrayCollection;
import mx.events.FlexEvent;

[Bindable]
private var searchList:ArrayCollection = new ArrayCollection();

protected function application1_creationCompleteHandler(event:FlexEvent):void
{
runSearch();
}

private function runSearch(event:MouseEvent=null):void
{
httpService.send({searchTerm:searchInput.text});
}

protected function httpService_resultHandler(event:ResultEvent):void
{
searchList = new ArrayCollection( event.result as Array);
}

protected function httpService_faultHandler(event:FaultEvent):void
{
searchList = new ArrayCollection();
Alert.show("fault");
}

]]>
fx:Script>
<fx:Declarations>
<mx:HTTPService id="httpService"
result="httpService_resultHandler(event)"
fault="httpService_faultHandler(event)"
resultFormat="e4x"
url="http://www.someUrl.com/yourMethod"/>
fx:Declarations>
<s:layout>
<s:VerticalLayout gap="20" paddingBottom="20" paddingLeft="20" paddingRight="20" paddingTop="20"/>
s:layout>
<s:HGroup width="100%">
<mx:Label text="Search Term"/>
<s:TextInput width="100%" id="searchInput"/>
<s:Button label="Do It!" click="runSearch(event)"/>
s:HGroup>
<s:List width="100%" height="100%"/>
s:Application>

This is an extremely simple example and honestly if this is all that your application needed to do then you are done. If your application is more complicated – or will get more complicated than this example – then this will fall apart real fast. On top of that good luck being able to unit test this code, reuse any of this code, using object oriented designs such as factories or even just interfaces, or even using the outliner view to find specific methods. Our final MVC application will be able to do all these things.

Quick Look At MVC
MVC is a simple concept that is immensely helpful at simplifying application development. The concept is just to split up your application by it’s model (the data), the view (what is seen), and the controller (the methods and functions that move the data from the view to the model and back).
Wikipedia – MVC

Understanding The Model
The models are your data centers for the application and extremely simple. In actionscript when you create models, this is the exact time you will want to use getters and setters for your properties. Why? Because the model just holds data and when the model has changed, it releases events to alert anything listening that the model has changed.

Best Practices: All of the properties in your model should have setters and extend the EventDispatcher to be able to send out events when the model has changed. You can see what I mean in my model code below. You could always use custom events to send let your application know of property changes, but for my example I will just use the basic Event class. It is also Best Practice to check that the property has actually changed before sending out events and updating the value. Double check that the variable has actually changed first. Very easy with strings and numbers and such, a bit more effort for larger complex objects.

Refactoring Your Code To The Model
For our example the model is EXTREMELY simple due to only one property, but you can see how simple the model is and how well it separates and simplifies the application layout. Finally you can now reuse this model in multiple controllers.

package com.unitedmindset.models
{
import flash.events.Event;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;

[Event(name="searchListChanged",type="flash.events.Event")]

public class SampleModel extends EventDispatcher
{
public static const SEARCH_LIST_CHANGED:String = "searchListChanged";

public function SampleModel(target:IEventDispatcher=null)
{
super(target);
}

private var _searchList:Array;

public function get searchList():Array
{
return _searchList;
}

public function set searchList(v:Array):void
{
_searchList = v;
dispatchEvent(new Event(SEARCH_LIST_CHANGED));
}

}
}

Understanding The Controller
Controllers are nothing more than a class that contains methods to move data back and forth from the data, update and handle responses from the view. I touched on this earlier but by separating this code into it’s own class you can have interfaces, subclasses, use unit testing on individual methods, and finally use the outline to jump to specific methods. Basically, everything that will help you grow as a developer as you make bullet proof applications.

Best Practices: The controller includes whatever methods are necessary and a reference to the view. The methods/handlers that are required by the view will always be public, everything else is private or protected. All events handlers should be in the controller and then the controller modifies the model and/or changes the view. However the view NEVER directly accesses the model. Again, my events from the model are just straight Event classes, though you could always make custom events from your model, though it is probably a bit overkill. Notice especially that the model is set to private to protect it from the view and other components. If you wanted to allow accessors to specific data within the model you may want to add getters in the controller, though again this is highly discouraged.

Refactoring Your Code To The Controller
Setting up your controller is simple, let’s start with a blank class.

package com.unitedmindset.controllers
{
public class SampleController
{
public function SampleController()
{
}
}
}

Now we just have to move the methods and change the functions that need to be available to the view to be public. Notice that the controller includes a model reference and listens for changes to the model and then updates the view as necessary.

package com.unitedmindset.controllers
{
import com.unitedmindset.models.SampleModel;

import flash.events.Event;
import flash.events.MouseEvent;

import mx.collections.ArrayCollection;
import mx.controls.Alert;
import mx.events.FlexEvent;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import mx.rpc.http.HTTPService;

public class SampleController
{
[Bindable]
public var view:UMBlogMVC;

private var _model:SampleModel;

public function SampleController()
{
_model = new SampleModel();
_model.addEventListener(SampleModel.SEARCH_LIST_CHANGED,_onSearchListChanged);
}

public function application1_creationCompleteHandler(event:FlexEvent):void
{
runSearch();
}

private function _onSearchListChanged(event:Event):void
{
view.searchList.dataProvider = new ArrayCollection( _model.searchList );
}

public function runSearch(event:MouseEvent=null):void
{
var service:HTTPService = new HTTPService();
service.addEventListener(ResultEvent.RESULT,_httpService_resultHandler);
service.addEventListener(FaultEvent.FAULT,_httpService_faultHandler);
service.resultFormat = "e4x";
service.url = "http://www.someUrl.com/yourMethod";
service.send({searchTerm:view.searchInput.text});
}

private function _httpService_resultHandler(event:ResultEvent):void
{
var service:HTTPService = event.target as HTTPService;
service.removeEventListener(ResultEvent.RESULT,_httpService_resultHandler);
service.removeEventListener(FaultEvent.FAULT,_httpService_faultHandler);
_model.searchList = event.result as Array;
}

private function _httpService_faultHandler(event:FaultEvent):void
{
var service:HTTPService = event.target as HTTPService;
service.removeEventListener(ResultEvent.RESULT,_httpService_resultHandler);
service.removeEventListener(FaultEvent.FAULT,_httpService_faultHandler);
_model.searchList = new Array();
Alert.show("fault");
}
}
}

Some people will argue that the httpservice should be in the model rather than in the controller. This is a point of contention among some developers. I believe it should be in the controller (or in a simple command) because it is a piece of logic that requests the data from the server, not the data itself.

Your Simplified View
Finally we will refactor our view to just the view elements and making a reference to the controller instance in your declarations section (for Fx4).

Looking over this code you will notice that there is absolutely no logic in your view, keeping you view to only doing one thing, looking good. It is the controller instance that receives events from the view and the controller that houses all of your application’s logic.

Wrapping It All Up
Hopefully this is illuminating and pushes you to do some code refactoring. What is also great about this style of programming is that it works right in with any of your favorite frameworks. If you are making an application and are wondering “Where does this code go?”, you just have to ask yourself “is this part of what is seen, the data, or logic within the application?”. This separation will also make it easier for when you are working with junior developers and they don’t know where to put code. I am sure you can already see the benefits to not having services in your view and being able to reuse controllers over multiple views, and the ability to continue abstracting your code to new levels.

Good luck, and happy coding!