Memory Leak Opening Multiple AIR Windows?

I’ve noticed that when I create multiple Window top-level containers in an AIR application, the memory they consume never appears to be garbage-collected, even after the windows are closed and their references destroyed.

This may be an unusual problem, since most AIR applications simply make use of the WindowedApplication container for their initial (and only) window.

For now, the only workaround available is to simply reuse AIR windows instead of closing them - which means the memory leak is only as bad as the maximum number of windows I need to have visible at once.

Where’s free() when you really need it?

Selectable Text and Hyperlinks

The Text control in Flex allows you to display non-editable, multi-line text with basic HTML markup.

But there’s a problem when it comes to anchor tags.

If you set the selectable property in the Text control to false, as I often do, the links in your HTML text will no longer work.

Believe it or not, this is by design!

From the Adobe® Flex® 3 Language Reference (emphasis added):

selectable property
selectable:Boolean [read-write]

Specifies whether the text can be selected. Making the text selectable lets you copy text from the control.

When a link event is specified in the Label control, the selectable property must be set to true to execute the link event.

The default value is false;.

So it seems that if you want the links in your Text control to remain clickable, the HTML text must be selectable.

(Not the biggest deal of course, but it would have been nice to know before I spent an hour pouring over my code at 1am trying to figure out why my links weren’t working)

Image Skinning a Button in Flex 3

Flex 3 makes it easy as pie to transform a series of images into a custom Button control.

First, create a CSS style declaration for your button, and define a different skin for each image you want to use. Even if you only have a single image, you’ll still want to implement the basic upSkin, downSkin, overSkin and disabledSkin style properties.

To embed an image asset in CSS, use the following syntax:

up-skin: Embed("pathTo/myImages/Up.png");

Once you’ve created your CSS style declaration, you’ll need to reference it in the styleName property of your Button control.

Finally, since we’ve replaced the default chrome with a custom set of images, the mouse cursors won’t behave like they would for a normal button. To fix this, we need to enable the buttonMode property and disable the mouseChildren property in the button.

That’s all there is to it!

Sample code for the CSS:
http://userflex.wordpress.privatepaste.com/d1JLaHSoi8

Sample code for the MXML:
http://userflex.wordpress.privatepaste.com/aaZFSzU9E0

Working with CSS Styles Programmatically in Flex

The StyleManager class in Flex allows you to easily read and write individual style properties from the comfort of your AS3 code.

But it’s not as easy as it could be.

You still have to retrieve each style declaration, make sure they exist, and then either return or set the desired style property. It’s not a lot of work, but it’s repetitive, and we can do better.

Enter the StyleUtil class.

StyleUtil is an all-static class I created with methods to access and modify individual style properties.

There are two basic methods, setCSSStyle() and getCSSStyle(), as well as hex() and hexToString() methods for converting hexadecimal values.

Now, changing the background color of a Canvas container is as simple as calling:

StyleUtil.setCSSStyle ("Canvas", "backgroundColor", StyleUtil.hex (value));

Not too shabby, eh?

Full source code is available here:
http://userflex.wordpress.privatepaste.com/241rTkjoRl

As well as a few sample getters and setters:
http://userflex.wordpress.privatepaste.com/ceKcBegdpA

Update: Code snippets I’ve posted using Private Paste are randomly disappearing, so if the above link no longer exists, here’s a backup.

Pitfalls to Avoid with Custom Item Renderers and List Controls

When you create a custom item renderer for a List control you need to be very careful how many layout constraints you introduce in each component. What might seem harmless in a single item can quickly become a performance bottleneck when that item is recreated several hundred times in a list.

A few general rules of thumb:

Use exact measurements
This one is obvious. By specifying an exact location (x, y) and size (width, height) you reduce the number of constraints your application has to keep track of. While the effect may be minimal, it can really make a difference when manipulating large data sets.

Don’t abuse the maxWidth property
I learned this the hard way. Setting the maxWidth property on as few as two components in an item renderer can ground your application to a halt, even with as few as a dozen items in your List control.

Don’t resize components using percentage widths
This applies to complex item renderers that have one or more components that set the maxWidth property, but in general its a good idea to resize your components absolutely. Even if you can only shave a few milliseconds off the rendering time it can make your application feel that much more responsive.

Avoid nesting containers
In general you should use as few containers as possible in your application, and item renderers are no exception. Nested containers create layer upon layer of constraints and can unnecessarily slow down your application. If you can, use a single layout container, and if at all possible, use a Canvas container with absolute positioning. Even HBox and VBox containers are heavier than Canvas.

Use Resize and Move effects instead of changing (x, y, w, h) directly
Although it may seem counter-intuitive, using effects can actually improve the performance of your application. Processing large amounts of information when you move or resize components can result in your application being unresponsive. But if you use effects, you can take advantage of the suspendBackgroundProcessing property to block all background processing while your components are being moved or resized. Even if you set the effect duration to 0ms you will still see an improvement in performance!

To summarize, when creating custom item renderers and List controls, be aware of the effect your design decisions will have, especially on larger data sets. What may seem to be insignificant data-bindings can quickly add up to huge performance problems!