Ok…so to say that there’s a memory leak in Lists and Grids is a bit redundant as they all inherit from one class, ListBase, which is where the problem is, but a bit of redundancy can be eye-catching.

Anyway…recently I was tracking down an issue filed by one of our testers, and stumbled across a nasty little memory leak in the 3.2 SDK.  Adobe’s already corrected the problem in the 3.3 nightlies, but I thought I’d post my findings here on the chance that anyone else needs the fix in their 3.2 SDK.

The problem is a small class called StageEventProxy.  SystemManager creates an instance of StageEventProxy passing to it your listener whenever one of the following types of events is listened for from SystemManager:

• MouseEvent.MOUSE_MOVE
• MouseEvent.MOUSE_UP
• MouseEvent.MOUSE_DOWN
• Event.ACTIVATE
• Event.DEACTIVATE

The problem is that StageEventProxy keeps a hard reference to your listener function.  This means that when garbage collection runs, that listener and the object its attached to will never get marked for garbage collection.

Now, you’re probably thinking, “I’ve never added any of those listeners to SystemManager so I’m free and clear.  Woot!”  Unfortunately you’re not off the hook just yet.  Adobe adds a MOUSE_UP listener to SystemManager in ListBase’s mouseDownHandler():

systemManager.getSandboxRoot().addEventListener(MouseEvent.MOUSE_UP, mouseUpHandler, true, 0, true);

The consequence of this line is that any object that’s an instance of a sub-class of this class (a quick search through the source code revealed List, DataGrid, AdvancedDataGrid, and TileList) will never be garbage collected once the user has clicked on any of the rows in the list. Additionally, because all UIComponents keep a hard reference to their parent component, the garbage collector will also neglect to clean up any of your list’s ancestors in the document hierarchy.

The implications of that for most people are that lists in pop-ups will cause the entirety of your pop-up to never get garbage collected. Here at Workday its a much larger issue, however. Our pages are dynamically created based on XML page definitions we get from the server. These pages are also dynamically unloaded when a new page is received. As a result of the patch for this fix, we’ve seen dramatically reduced memory usage over time in our Flex applications.

Here’s the culprit so you can see what was going on:

////////////////////////////////////////////////////////////////////////////////
//
//  ADOBE SYSTEMS INCORPORATED
//  Copyright 2003-2006 Adobe Systems Incorporated
//  All Rights Reserved.
//
//  NOTICE: Adobe permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
////////////////////////////////////////////////////////////////////////////////

package mx.managers.systemClasses
{

[ExcludeClass]

import flash.display.Stage;
import flash.events.Event;

/**
 * An object that filters stage
 */
public class StageEventProxy
{
	private var listener:Function;

	public function StageEventProxy(listener:Function)
	{
		this.listener = listener;
	}

	public function stageListener(event:Event):void
	{
		if (event.target is Stage)
			listener(event);
	}

}

}

Here’s the updated version Adobe’s including in the 3.3 SDK:

////////////////////////////////////////////////////////////////////////////////
//
//  ADOBE SYSTEMS INCORPORATED
//  Copyright 2003-2006 Adobe Systems Incorporated
//  All Rights Reserved.
//
//  NOTICE: Adobe permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
////////////////////////////////////////////////////////////////////////////////

package mx.managers.systemClasses
{

[ExcludeClass]

import flash.display.Stage;
import flash.events.Event;
import flash.utils.Dictionary;

/**
 * An object that filters stage
 */
public class StageEventProxy
{
	private var weakRef: Dictionary = new Dictionary(true);

	public function StageEventProxy(listener:Function)
	{
		this.weakRef[listener] = 1;
	}

	public function stageListener(event:Event):void
	{
		if (event.target is Stage)
		{
			for (var p:* in weakRef)
			{
				var f:Function = p as Function;
				f(event);
			}
		}
	}

}

}

And finally…Here’s a patch file you can drop in your Lib folder that will solve the problem: PATCH FILE

In case you somehow missed it, I wanted to point out an interview with our humble leader, Dave Duffield.  He recently participated in the Bill Kutik Radio Show podcast.  One of the highlights in this great podcast is Dave’s rundown of his companies and the technology changes that occurred during each.

Podcasts are a really great technology.  The quality of the recordings can be just as good as what you find on the radio, but with the flexibility of the content to be what you care most about.  I’ll have to admit that I don’t listen to as many podcasts as I should, but that’s just because I get too engrossed in them.  Therefore, that means they’re not an option when coding.  I’d listen to them on my “commute” but since that’s only 10 minutes long, I don’t think I’d get much in that way either.

If you do like podcasts and want to learn a little more about Flex (the technology that powers Workday’s UI), there’s a really great podcast put on by two friends of mine: Jeff Houser and John Wilker.  It’s called The Flex Show and it covers the Adobe Flex technology world.  I’ll have to get Khurram and Frank from the Workday UI team to do an interview with them soon, so you can find out some juicy details about our amazing UI.  In the meantime, you can listen to a brief interview with Charlie Boyle (the UI team’s manager).  You can zoom to minute 14 to get to Charlie in that episode.

Here at Workday the Flex application we’re building is extremely complex (like a fine wine) because our components are built dynamically.  As such, debugging visual and styling issues can often be onerous.  One of my favorite tools for aiding in that task is FlexSpy.  It’s a great tool that lets you view your application’s object hierarchy and inspect the properties on each object in that hierarchy.  Its the closest thing I’ve found in Flex to what Firebug is for Ajax apps.  It even has a “finder” similar to Firebug’s “Inspect” functionality.

There are a couple of problems with FlexSpy, however:

1. FlexSpy does not have the ability to use SystemManager as its root.  By default it chooses the current Application as its root, thereby rendering you unable to inspect anything else attached to system manager (like pop-ups).
2. The “finder” mostly works, but doesn’t always let you drill into the child-most component.  For example, if you’re trying to get to a component that’s in a DataGrid cell, the finder will only take you as deep as the grid itself.  From there, you then have to use the tree view to get to the component you’re looking for.

I’ve added a couple enhancements to FlexSpy to try and tackle these problems and posted them in an issue filed on their Google Code page.  The 2 attachments change FlexSpy so it uses SystemManager as its root, and make the finder much more accurate.

I hope that folks will find these changes useful.  If you find any problems with the changes, please feel free to comment here, and I”ll see if I can figure out what’s going on.

I’ve recently been trying to add better keyboard control to some of our components.  One such component is basically a container with a set of radio buttons.  The radio buttons not only have labels, but also associated fields (TextInputs, ComboBoxes, etc.) that are only applicable when the radio button next to it is selected.  Thus, the radio button and its associated field both get wrapped in a container for alignment.

This particular component also supports the inclusion of a “None of the above” radio button.  For that particular item in the radio button list we were using a standard Flex RadioButton as there needs to be no associated field next to it.  The result of one of these instances might have a structure similar to this:

<mx:HBox>
 <mx:RadioButton/>
 <mx:ComboBox/>
</mx:HBox>
<mx:HBox>
 <mx:RadioButton/>
 <mx:TextInput/>
</mx:HBox>
<mx:HBox>
 <mx:RadioButton/>
 <mx:CheckBox/>
</mx:HBox>
<mx:RadioButton label="None of the above"/>

The problem I ran into was this: My focus being set on any of the radio buttons in the list, I would start hitting the up arrow.  Once the arrow took me to the radio button physically at the top of the list, it would allow me to move one further, and take me back to the “None of the above” radio button.  For some reason it thought that “None of the above” was first in the list.

I started digging around and here’s what I found:  When RadioButtons are assigned a RadioButtonGroup (via their group property), they register themselves with that RadioButtonGroup via  call to the addInstance() method.  The problem is that the registration does not happen as soon as the group is added.  There are actually several possible places where it can happen, including commitProperties() and updateDisplayList().

This means that the order in which RadioButtons are added to their groups’ array of radio buttons is dependent on the flow of the component lifecycle.  The reason “None of the above” was at the top of the groups movement list was because it was the only one in the list of radio buttons that wasn’t also wrapped in another container.  The extra level of nesting for all the other radio buttons meant that they would get their updateDisplayList and commitProperties methods called after the “None of the above” button’s.

I wound up resolving the problem by wrapping the last radio button in the same type of container as all the rest.  Hopefully this helps someone else avoid having to spend a bunch of time on the same problem.

When variableRowHeight is set to true on AdvancedDataGrid,
(a) mx.controls.AdvancedDataGrid ignores attributes such as rowCount.
(b) there is no way to figure out the height of the AdvancedDataGrid instance because we don’t know how much height we will need to show the rows of data in our dataProvider. We can set the height to maxHeight but what of the sum of heights of all rows in our grid is less than the maxHeight, we need our grid to adjust itself to the shorter height but the AdvancedDataGrid does not.

(c) When opening/closing trees in hierarchical data inside the grid, we need the grid to automatically adjust its height. AdvancedDataGrid does not do that when variableRowHeight == true

The AutoSizingAdvancedDataGrid fixes this issues. It does this by dynamically increasing the height of the array until (a) all the rows in the dataProvider have been displayed or (b) maxHeight has been reached.

Click the image or here to see the example app.  You can right-click and view source as well.

We’re working with the AdvancedDataGrid pretty heavily here at Workday. Therefore, we find ourselves using HierarchicalCollectionView by default since ADG wraps HierarchicalData in one.

The problems that we’re encountering is with filtering. I opened up my first Flex Bugbase Jira (woohoo!), so please go vote for it. https://bugs.adobe.com/jira/browse/FLEXDMV-1700

If you set the filterFunction property to null in any other collection, that means you’re done filtering. Since there’s no filterFunction, every item should be shown in the collection and any past filter results should be removed. HierarchicalCollectionView just says, “Well, if there isn’t a filterFunction, then we don’t need to update the data at all.” Bummer.

To see what I mean, check out my test app I submitted with the Jira. It’s located here and has view source enabled so you can make sure I’m not crazy!

Be sure to vote for sameer’s Sort bug as well: https://bugs.adobe.com/jira/browse/FLEXDMV-1594 It’s pretty much the same thing only for Sorting instead of filtering.

Workday’s web application is currently built on top of Adobe’s Flex Framework. Flex let’s us build really cool widgets, which the application developers then turn into useful applications. Flex is great for developing. The current way to access the application is via a web browser, which is great for some reasons (zero-deployment, lightweight client, etc.) and not so great for other reasons (back/forward buttons, tabs in the browser, bookmarking, etc.)

Just because an application is deployed via a web browser doesn’t make it a “website”. Workday is a tool that our customers will use everyday of their work life. They should be able to access it like an other application they use at work by double clicking an icon on the desktop, single clicking an icon in the Quick Launch bar, or choosing an item from the Start menu (Yes, this is a Window’s users view).

Prism offers that functionality. It does it easily without much complication. The nice thing about Prism is that it’s an end-user technology. You don’t have to be a developer to convert your favorite web app into a desktop application. You just need to know a url and you’re done. Yes, it’s currently for Windows only and still pretty slim on features. However, for Workday, we build plenty of features ourselves into the application and it’s nice to see it shine on it’s own. If you’re interested in a bit of the Prism story, read Alex’s entry (he’s working on User Experience at Mozilla).

Below is a screenshot of my desktop. You can see the Workday app running in a tab inside Firefox. This is how I normally access the application. Moving forward though, I’ll be using the “Workday Dev” application instead. It’s the window with the red box outline around it (the red box is my doing to call out the window, Prism doen’t do that). You can also see 2 red circles highlighting the Desktop icon and Quick Launch icon.

If you use Workday and want it to access it like a desktop application, then go to the Mozilla Labs site and give Prism a twirl. Remember, it’s currently Windows only, but Mac and Linux support should be out soon.

Some of the Flex compiler warnings are more informational in nature i.e. they are not really warnings just information pointers, sort of like “are you sure this is what you want, if yes then ignore”.  I discuss two of them that directly affect many apps below –

 1.  One such so-called warning comes up when you do not specify an explicit scope for your variable or method.  For example –  

 Declaring a function as follows will give a compiler warning in flex –

public class Foo {

function bar():void {

            //whatever

}

}

The warning would read like this: “1084: function bar will be scoped to the default namespace: Foo.internal and will not be visible outside this package”.  Now this is useful information only if the developer wanted this function to be visible outside its package.  On the other hand, if the intended design was to not have this function visible outside the package, then the signature of the function is correct and specifying any of the scope keywords (public, private or protected) on this function just to get rid of the warning would be incorrect as that’s changing the design.  Package scope is common in modern object oriented languages such as Java and ActionScript 3.  Java compiler does not complain about it, AS compiler shouldn’t too.

2.  The other such warning that comes up very frequently in Flex has to do with bindings.  For example –

 Let’s say that I have a mxml component as follows:

<mx:Text text=”{label}” xmlns….>

            <mx:Script>

                        <![CDATA[

                                    public var label:String;

                        ]]>

            </mx:Script>

</mx:Text>

 Flex will give you a warning that changes to label will not be detected by data binding.  This is an issue only if the developer wants the variable to be bindable.  In many cases in an application where [Bindable] has not been specified for a variable, the developer did not want it to be bindable mostly because the variable will never change its value once it has been initialized or if the intent is that the change in value should not update the bound variable.  One way to achieve this is to manuelly update the value in AS code instead of specifying it as a bound variable in MXML.  That is not the idea case for people like myself who like the elegance of MXML and want to resist the temptation to write AS code.

We ran into this issue while debugging memory issues in our flex application. This issue has been fixed in the latest beta version of the Flash Player 9.0.60.184. Here is the issue for your reference as it might help you debug memory issues in your application, also download and run the example source to replicate it.

As I was debugging some of the memory issues we are having, I noticed that the objects of types container do not get garbage collected if they have one or more children specified as MXML tags (or alternatively added through component descriptors). I looked at the mx.core.Container class and noticed that it keeps an array called _createdComponents of all the components that were created through their descriptors. It populates that array in the createComponentsFromDescriptors method. The problem is that it never gets rid of the components in the array when they are removed by calling any of the remove methods such as removeAllchildren, removeChildAt etc. That array thus keeps a strong reference to children that had already been deleted and should have been garbage collected. This also gives rise to a circular reference case where the parent and the child both don’t get GC’d.

I have created a small program that might be helpful in reproducing this bug.

1. After you load the files into a project, run the swf
2. Click on “Create AS based child”
3. Click on “Trace Reference”, it will show you the created children
4. Click on “Remove All” and then “Force GC”
5. Click on trace reference, you will see no references
6. Click on “Create Descriptor based child”
7. Click on “Trace Reference”, it will show you the created children
8. Click on “Remove All” and then “Force GC”
9. Click on “Trace Reference”, you will notice that the reference still hangs around even after it has been deleted and GC has run

There is another memory leak that occurs when you specify verticalGap or horizontalGap attributes on any container. This issue has also been resolved in the Flash Player version specified above.

Icons are one of the biggest challenges in designing good interactions.  Icons are a great way to represent an available action or show an affordance while using less space than descriptive text. They can also ease localization by lessening the number of labels that need to be translated.

The problem, simply put, is that there is a difference between icons and little pictures. Icons represent something in a way that is broadly recognized. Little pictures are simply little pictures, and subject to multiple, and widely varying, interpretations.

For example, Elvis is an icon. Flags of various countries are icons. Even a little picture of a printer is an icon.

Not every little picture is an icon. Little pictures of top hats, lightning bolts, or almost any animal are not icons.

There are a couple of mitigating factors. The first is that when certain small pictures are displayed in the appropriate context, they become icons. For example, an outline of a human head displayed within a group of camera settings will usually mean something about portrait photography. The other factor is that many little pictures can become icons through common usage. A small grid with a band across the top has become recognizable as a calendar, even though I saw many people not understand that when they first encountered it years ago.

So now for the fun part.

Next time you are bored, find an application on your computer or on the web. Choose something that most of your friends have not used, or use very infrequently. Take a screen shot of the application in a state showing as many icons as possible. Then use your favorite graphic editing tool to label each icon with a letter or number. (Don’t block any part of any icon.)

Now take your screen shot and send it off to an assortment of friends, asking each to reply to your message with their idea of the meaning of each icon.

The results are always interesting and often entertaining. (I got a lot of interesting guesses about the top hat.) Of course, to reward your friends for participating, your should summarize the responses and send the summary to them for their  amusement. It’s also good to include an “answer key” of the correct meanings.

If you would prefer that the guesses be more entertaining than informative, do the above with a screen shot of only the icons with no application to provide context. Then let the fun begin!