From the code depot you can download a compiled SWC or a ZIP file that contains all the source and ASDoc generated files. We have posted the ADoc files on-line so that you can easily access them if you do not download them. Currently, we have 219 unit tests running and passing for the library, which are all available from the source tree if you wish to access them.

The current release of Core contains the following functionality. We have marked new and updated features that have been changed from the Vivisecting Media Library to the new Core Library:

• Task Management System new! – The Task system is a priority queuing system that enables an application to execute specific bundles of business and/or server logic in a specific order leveraging priority and the ability to override previously queued bundles. These bundles are encapsulated inside of Task objects, which can be then bundled Task Group objects. Tasks and task groups have the ability to take priority over other Tasks or Task Groups inside of the queue, as well as replace existing tasks in the queue based on a set of overrides an individual task can define.
• Command Action Delegation System (CAD) new! – Provides a pre-built solution for implementing the Command Pattern within ActionScript/Flex/AIR applications. The command / action system allows for commands to be dispatched to the ActionDelegate which then executes any assigned functionality via an Action.
• Selection Management System updated! – The Selection Management system enables any kind of object to become selectable and treated as part of a Selection group. In most cases this would be a UI Component that should behave similarly to a radio button group, where only one item can be selected at one time. This system also allows for multi-select and deselection of items that are members of a selection group.
• Local Connection Management updated! – The Local Connection manager is a helper class to quickly establish and manage local connection instances within an application. The Local Connection manager also supports the ability to maintain strong class types when the data object is passed over the local connection instance.
• Event Broker Utility – The Event Broker is a utility class that acts as a router for specified events. The Event Broker is a single point of contact that any object can broadcast to or subscribe to. This functionality is intended to be the focal point for implementing the mediator pattern within the application.
• Instance Factory Utility new! – The Instance Factory allows for the ability to make sure there is only one instance of a specified class within the instance of the factory. This is useful for using in Locators that handle generating a new instance on the first request but then making sure the original instance of the requested item is returned on subsequent requests.
• Singleton Factory Utility new! – Similar to the Instance Factory, the Singleton Factory verifies that there is only one instance of a requested item, but instead of being limited to the instance of the factory, the Singleton Factory verifies there is only one instance of the requested item in the entire application.
• Adjustable Date Utility new! – The adjustable date wraps a Flash Date object and provides a series of helper methods to adjust time and dates quickly and easily. Example uses included the ability to adjust a date by a specific number of days forward or backwards, making sure that the number of days in the month and Leap Years are respected during the adjustment.
• Queue Data Structures updated! – The Queue system allows for items to be stored in either a LIFO or FIFO based queue order or in a priority queue order and then retrieved from the data structure depending on how the items are ordered.
• Hash Table Data Structure – The Hash Table is key/value that allows any value or object to be used as a reference key to another value or object item. The Hash Table is similar to Flex’s ArrayCollection in how items can be referenced but unlike the collection, this is ActionScript independent, is not intended for data pagination and is focused on performance for larger data sets.
• Browser Location Utility new! – Utility class used to query the current url in the application. The class provides static properties for each piece of the application url.

Adobe MAX 2008: The Future of Flex Builder (Part One)

In this post I will be delving deeper into the new/updated feature set that focuses on the aspect of the “Test & Tune” workflow. Test & tune is the day-to-day development workflow that we are all used to: Navigating our projects, creating new code, documenting, re-factoring, debugging and testing. A lot of these features may seem small but they provide a lot of power and can drastically improve development time and ease frustration that we experience during the development cycle.

Package Explorer

The first test & tune feature I want to examine is the new Package Explorer. Some of you may be thinking to yourself that Flex Builder already has a Package Explorer and wondering why this is a new feature. Well, to be exact, Flex Builder 3 does not have a true Package Explorer, what it has is the “Flex Navigator” which is really just a folder browser. When we use the Flex Navigator we often treat it like a package explorer since ActionScript packages are just folder hierarchies and this is what is represented within the Flex Navigator. The new Package Explorer merges the functionality of the Flex Code Outline panel and the Flex Navigator into one view.

Take a look at the screen cap, first you will notice that the MXML root file is now in a (default package) node within the explorer. From there you can then expand the MXML file data to look at the Classes contained and the properties of the class. Next, you can see that the default view makes the hierarchy a flat layout. For example, the package “com.developmentarc.test” is listed all in one line which means you don’t have to expand to view the structure to access a deep package like you would in the Flex Navigator. If you don’t like the flat layout you can change the settings of the Package Explorer to create the more traditional parent/child structure.

Finally, look at the Flex 4 SWC package in the screen cap. The Flex SDK version for the project is now shown in the Package Explorer. Not only is it shown but you can expand the SWCs to see the content structure, classes and properties contained within. In the screen cap I am exploring the Array in the playerglobal.swc file. This SWC exploration also works with 3rd party SWCs, not just the Flex 4 SDK. These all may seem like small changes, but it makes exploration, creation and modification of existing projects much easier. This also allows for Java Eclipse users to experience a much more familiar view when developing Flex Applications. Good stuff.

Event Auto-generation

During development, creating event bindings and method handlers such as the Mouse click event, is a common task. The event auto-generation is a short cut feature in Design View that allows a developer to quickly generate an event handler for a component. The example they used in the session was adding an event handler for a Button’s click event. From design view the developer would click on the generate handler button next to the on click event field:

When the user clicks this button, the handler function is generated in an <Script> block within the MXML file and the method is then assigned to the Button’s click property. My personal feelings about this feature is that it is helpful for initial development and/or learning of the Flex event handling model, but for complex development I am hesitant to see this as a go to feature. For one, the feature automatically adds the script to the current MXML file. On larger projects I typically avoid having scripts in MXML, this is especially true when following the code-behind pattern. I also feel this is going against the proposed workflow model that Adobe is pushing for Flash Catalyst and Flex Builder integration since your MXML is becoming more layout-centric with Classes for logic.

Overall, its a helpful feature and it makes prototyping, initial development and demoing a lot easier. We will see how this feature matures and how it is adopted by developers in the future.

ASDoc

ASDoc-ing is the process of adding specially formatted comments to your code that enables the ASDoc tool to generate documentation from the code and formatted comments. ASDoc is just like JavaDoc and has been evolving and maturing the the first release of Flex. One feature that has been part of Eclipse’s Java development suite is the ability to see inline contextual JavaDoc notes for specific Classes, properties and/or methods. The next version of Flex Builder supports the same kind of in-context doc hinting for code that has been properly ASDoc-ed.

When a user hovers over a method, property or class in either ActionScript or MXML the ASDoc tooltip will display showing the contextual docs for the specified attribute. In the screenshot above, I am hovering over the “left” attribute of an <FxButton> tag. Notice that the displayed doc notes are only for the “left” property. If I rolled over <FxButton portion of the tag you would see the ASDoc content for just FxButton. Not only can you view content inline, there is now a ASDoc panel that can be added to you workspace layout. This panel automatically updates when you click on a property, method, class, tag or attribute. This way you can have the view up and accessing ASDoc content without having to wait for the rollover event.

The ASDoc feature also works within your own code. For example, if you are developing a custom Class and provide properly formatted ASDocs in the Class, the ASDoc window/tooltip will show your ASDoc notes whenever you reference your Class in the application. The Flex team is also working on a new SWC format nicknamed “Fat SWC”. This Fat SWC will now include all ASDoc notes that are provided in the source code for the SWC compilation. This means that when you use a “Fat SWC” in your project, you will get ASDoc hints for any of the Classes, properties, methods, tags or tag attributes that are contained within the SWC.

New Re-factoring Features

There are two new re-factoring features that were demonstrated during the session, both of which help automate tasks that developers do on a weekly, if not daily basis. The first feature is the ability to auto-generate a getter/setter pair from an existing property.

To use this feature you first select, or apply cursor focus, the property that you want to convert to a getter/setter pair. You can then either right click > source > Generate Getter Setter… or you can choose the Source > Generate Getter Setter… menu option. This brings up the above options dialog where you can decide if the existing property should become private, what the new name of the property should become (it defaults to a single underscore prefix), the name of the exposed get / set method, should it create both the get and set method, or just one or the other and finally where the new methods should be added.

This is one of those at first glance small yet super powerful features. During development there are many times where you need to convert a basic public property to a get/set pair and this helps write the code quickly and elegantly. One other cool thing to note about this feature is its ability to remember your preferred prefix. As I mentioned earlier, the default is a single underscore prefix for the private method. I personally prefer a double underscore prefix for my get/set value properties and when I added that additional underscore Flex Builder remembered this and kept the double underscore when I used the re-factor function again. Very, very cool.

The second re-factoring feature, isn’t really new, its just a lot more complete. When re-factoring the code-base, one of the biggest challenges is the process of moving Classes around to new packages. This may occur for all kinds of different reasons: better project organization, company name changes, project changes, etc. etc. Eclipse (which Flex Builder is built upon) supports the move option, yet in the current release this would just move the resource to the new folder and not update the Class’ package structure and linkage throughout the workspace. If you used the rename function, Flex Builder would handle all the updating for you, so it always felt as if the functionality was half-complete.

Well, now move is finally fully supported. This is great news for those of us that have had to spend five minutes moving resources and then the next hour fixing the compiler errors. Typically the process was move the resource, build the project, look for errors, updating bad references, re-build the project, looking for bad references, rinse and repeat. This can get really ugly when you have 800+ classes (which I have had in the past) and you are doing a massive project re-structure. Not fun, let me tell ya. When you choose to move an asset you get to choose what package to move it to and Flex Builder handles updating all the linkage references and package declarations.

One thing to note, in the current preview build of Flex Builder the package has to exist before you move the resource to it. If I recall, David Zuckerman mentioned that this will change in the future. Even if it doesn’t this is a great feature, one that I want NOW. It would have been soooo nice yesterday when I had to move a ton of MXML classes around and re-link them throughout the project, oh well.

Code Templates

Code templates are more or less self exactly what they sound like. A code template is similar to an email signature in that it provides the ability to auto-fill predefined content when a new MXML, ActionScript or CSS file is created. In a way, we have already been using Code Templates when we generate a new ActionScript class. The provided package structure, class declaration and constructor are all generated by the Code Template engine. The difference is that in the next version of Flex Builder this will all be exposed to you and fully modifiable.

Are you working on a MIT or other licensed project? You can now add the license block to the template code and any new file will have the proper structure. You can predefine code blocks, ASDoc blocks, code layout and preferred structures all within the code templates. You can also use variables that set time, file path, names, etc. into the template. On top of that you can export your created templates, pass them around and have others import the template into their Flex Builder. This is great if you work with multiple developers and want to create better coding standards or if you want to create company or open source project specific structures. Again, a simple yet very powerful feature that is being exposed to us.

Code Navigation

The last Test & Tune feature I am going to talk about in this post is code navigation. Code navigation shows a developer in code view what methods are overrides and implementations of interfaces. It also allows for quick navigation up to the parent reference when the triangle icon is clicked.

This is a nice feature because in the past you had to look at the Interface itself to determine what methods are implemented in the current class related. Overriding was generally easy to see at a glance because of the override keyword but getting to the parent method instance was not so easy. This feature enables both code readability and better navigation within the application.

Well, that is all for now. I have three more topics to write about, two more test & tune and then a look at the new Data service support. I will save those for the final post.

• Design Fidelity / UI Creation
• Data / Service Management

Design Fidelity / UI creation is focused around a Flex developer that is responsible for bringing in the initial design for that application and making it a reality. This process includes layout, skinning, styling, animation and effects creation with the core goal of meeting the required design fidelity for the final product. The second entry point is for the developer that is responsible for the Data / Services management aspect of the application. This process includes creating data services, data model creation and loading management. To be clear, these two separate approaches do not mean they are handled by different developers, this is just a way at looking at how developers approach their Flex development duties.

Because there are the two main entry points for most developers, the Flex Builder team is first working on new and improved features that focus on these two areas. There is also a general initiative to work on improving general day-to-day use in Flex Builder, re-factoring management and debugging of Flex applications (they called this process “Test & Tune”). This general initiative covers both the design and the data aspect of application development.

I am going to be breaking this article into three separate posts. This first post will cover the workflow and new features added to Flex Builder for the Design Fidelity aspect of development. Post two will cover the overall day-to-day use features that are being updated/added and how the Flex Builder team is improving the “Test & Tune” workflow. The third post will look at the data services features that are being added to the Flex Builder 4 (Gumbo). One thing to note is that this session was a mini sneak-peek of Flex Builder, and there is a chance (albeit very small) that some of the features discussed in the post may not see the light of day (or change drastically). Also, all the screen caps in the posts are from the MAX Preview release, so there is always a chance that the UI and functionality shown will change. Okay, let’s get to it!

Design Fidelity Features

Theme Management The first new feature they examined is Flex Theme management and installation. Themes are not a new concept, they have been around since at least Flex 2 (I can’t recall if Flex 1/1.5 supported them, I think they did). A Theme contains style and skins assets for every Flex SDK component and is applied to your application during the compile process. The idea behind a theme is that you can apply a unified style across your application without having to go in and skin each component yourself. If you are familiar with WordPress, its the same concept as their themes; all the functionality stays the same but the look and feel can be drastically different.

The Theme market for Flex appears to be growing, but adding a theme to an app requires making compiler argument changes to make sure the theme’s assets are loaded and compiled into the generated SWF or AIR application. This means that the Flex Builder developer has to configure the project properties in the tool to make sure the Theme is applied. I have personally not used Themes in my applications due to the fact that all of the projects I have worked on have design teams and/or unique design requirements, but I have played around with themes in the past.

The Flex Builder team has seen the growing popularity of Themes and they want to make Theme installation a much easier process. Themes are packaged as SWC files that contain all the CSS and style assets. When a user downloads the SWC file to their machine they can then choose to install the theme into Flex Builder. To install a Theme, the user chooses the Import Theme… option which allows the user to point to the Theme file. The theme is then imported into Flex Builder and it can be selected from the new Theme management dialog.

You can access the theme management dialog by clicking on the “Manage Themes” link above the UI component panel in Design View. This dialog shows all the currently installed themes and a thumbnail of what the theme looks like. You then select what theme you want to apply and this updates the complier options for you and rebuilds Design view using the new theme. It also sounds like they are working on streamlining theme creation and how they are distributed to make theme use easier and more popular.

Catalyst and FXP Support

The next Design Fidelity workflow feature is the ability to handle importing and exporting of Flash Catalyst project files. Flash Catalyst is a new design/development tool by Adobe that is centered around creating and styling Flex applications. One of the most challenging processes of Flex development is applying complex custom UIs into your final application. The goal of Catalyst is to allow a designer or developer to import assorted creative asset formats, such as Photoshop files, Illustrator files and Fireworks files and then quickly build Flex UIs using the creative assets’ contents (layers, symbols, etc.). Once the layout / styling is done the Catalyst user can save their Catalyst built application as an FXP file and pass this on to a Flex developer to wire it up to data services and functionality. The FXP file created by Catalyst is a zipped version of a Flex Builder project which means that a Catalyst user can share their work with a Flex Builder developer or visa versa. This gets us into the new FXP feature and workflow being added to Flex Builder 4.

Flex Builder 4 has the ability to import an FXP file and then create a project within Flex Builder from the FXP file. This imported project has all the structure and content that was created inside Catalyst. From there the Flex Builder user can begin adding functionality to the Catalyst generated project, such as data binding and data service management. As the project moves along there will come a time where the UI will need to be modified. At this point the Flex Builder user can export the Flex Project back into the FXP file format and pass this to the Catalyst user. The Catalyst user can then open the FXP file, make the UI additions and then hand the FXP back to the Flex Builder user.

At this point, when the Flex Builder user imports the updated FXP it recognizes that the project already exists and provides the option to allow the user to merge the Catalyst changes into the existing project. When the user selects merge, the project conflicts are then highlighted in red within the project view and the user can then right click on the conflicted files to show a merge tool view that enables the user to determine what changes to bring into the project. This current workflow is in its very early stages and I assume that it will be both improved and changed as development/testing/feedback is provided.

The focus of the FXP support within Flex Builder is to help create a better streamlined workflow between the design and development aspect of Flex. My example above assumes that your Catalyst and Flex Builder user are different people, but this workflow can be used by a single person going between Flex Builder and Flash Catalyst. As both of these products move forward in development I expect to see a lot of discussions around integration, workflow and best practices for planning and structuring your Flex projects.

That’s all for now… The next post for this article will cover the new Test and Tune features that are being added to Flex Builder.

Aaron and I have a TON of notes and thoughts that are being worked on, all thanks to MAX North America. I am sure we will have even more coming from MAX EU. We will both be working on a ton of new posts over the coming few weeks and at the same time we are in the process of getting our DevelopmentArc site proper (don’t forget client work and other assorted projects we are working on too!). More to come on that later. So, for those of you in/from the States that celebrate T-day, enjoy! For those of you that don’t, no worries, you can laugh at us as we Americans stumble around in a triptiphane induced food coma.

Oh, and for those of you that read this blog for Flex/Flash/Technology info, read up on my newest obsession while I am away: Degrafa. Degrafa is short for “Declarative Graphics Framework” and it is a set of Classes that enable you to create simple to complex graphical content using MXML instead of having to write a bunch of ActionScript graphics calls. But that is just the tip of the iceberg, you can actually make component skins (states and all!) using their framework. Its rare for me to get this excited about a new framework, I am usually super hesitant about jumping in, but after a demo at the MAX Birds of a Feather, and now getting my hands dirty in it, I am super impressed. Good work guys!

My goal was to take these two posts, summarize them and show how to get the current source and check it in. Just as I sat down to write this all up, Mike Chambers comes in and scoops me. Figures. Anyway, I yelled at Mike via IM for stealing my thoughts and then mentioned that I figured out how to bind the Flex 4 source to the SWC in Flex Builder so that you can F3 / CTRL+Click you way to the code. So, I am going to post that aspect of the process and refer back to Mike’s straightforward post on how to get the SDK compiling and running.

Check Out The Source
The first step of linking the Flex 4 source to Flex Builder, is to download the code from Adobe’s Open Source website. Adobe and the Flex team are using Subversion to manage the code base so you will need to use SVN to checkout the source. I already had Subversion installed so I was able to jump right in and checkout the code. If you don’t have Subversion, or want to learn more about how Adobe has the SVN configured, then make sure to read how to check out from Adobe’s code base. If you have Subversion installed, then here is the short and sweet version.

First, I didn’t want to download the entire SDK SVN trunk, so I found the direct path the Flex 4 Framework code using their web browser interface:

http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/flex4/src/

Next, I picked a location to keep the source. I personally chose to put it inside the flex 4 SDK folder under a new subfolder called src. You can put this folder anywhere you want, I just chose this location on a whim. To get the source, I opened up my terminal, cd‘d to the new src folder and then ran the following command to download the source:

svn checkout http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/flex4/src/ ./

You don’t technically have to cd to the new folder but I hate having to fit it all in one command line. Whatever, I can do what I want! Once you run this command, Subversion will download all the ActionScript source for the framework into your new directory. The last step is to inform Flex Builder that you have source for it.

Get Flex Builder Into The Know
To do this, right click (CMD+Click) on your project in Flex Builder and choose Properties > Flex Build Path > Library Path. Expand the Flex 4 SDK tree and then expand Flex4.SWC so that you see the Source Attachment: option. Double click Source Attachment: and then browse to the folder that holds the source you just downloaded. Choose Okay, and there you have it, source is now bound to your SDK and you can F3 to your hearts content.

One thing to note, if you only use the default namespace, then hinting will not follow through in FB3. I recommend binding the gumbo library for this to work:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application 
	xmlns="http://ns.adobe.com/mxml/2009"
	xmlns:mx="library:adobe/flex/halo" 
	xmlns:gumbo="library:adobe/flex/gumbo"
	layout="vertical">
 
	<gumbo:Button label="hello world" />
	<gumbo:Group>
		<gumbo:content>
			<gumbo:Ellipse width="30" height="30">
				<gumbo:fill>
					<mx:SolidColor color="#FF0000" />
				</gumbo:fill>
			</gumbo:Ellipse>
		</gumbo:content>
	</gumbo:Group>
</mx:Application>

This tells FB where to start looking for the source and enables it to open properly. If you know of a way to bind the namespace to the source, please let me know!

I read a great analysis article by Grant Skinner, talking about the different Open Source licenses and how they can affect you and your client. I originally licensed the code library under the Mozilla Public License (MPL) due to its popularity, its freedom to allow developers to build on top of the code base for any purpose (free or for charge) and only requires code modification submission if the developer changed the original code in the library. My goal with VivMedia is to help developers build great applications, and the last thing I wanted to do is limit them, yet I do want to encourage people to submit changes and updates. That is why I went with MPL at first.

The issue with MPL (as Grant points out) is that when you use MPL code there are certain steps you need to take to release your project. In most cases this is not a big deal and it very rarely impacts the project but it may cause some developers or their clients a bit of grief. In all honesty, I just want to create a library that myself and others can use without having to jump through hoops with our clients. This lead me to change all the code license to MIT, which is very permissive of all forms of development. All you need to do is keep the MIT license headers in the source. You don’t have to submit changes (all thought I would be very happy if you did) and you don’t have to jump through any other legal hoops when deploying. So, if you are using the library already, update to the new version and know that the door is now wide open and you don’t have to fret about how you or your clients release the work.

The other addition to this version is the new Queue data structure. The Queue allows you to add and remove items is in a linear fashion. You can define the Queue as either Last in First Out (LIFO) or First in First Out (FIFO). What that means is when you add() item A and item B to the Queue and then call next(), the item returned is dependent if the queue is set to LIFO or FIFO. A LIFO Queue returns item B, since it was the last item added. A FIFO Queue returns item A since it was the first item added. As always, a full tutorial will be posted soon on how to use the Queue in your code.

The Queue is a building block for a lot of new functionality that I am starting to plan out. There will probably be variations of the Queue going forward too. For example a version that is designed to help solve Asynchronous issues in a Synchronous fashion, without you having to write a lot of logic around the actions. Right now, its all about what time permits… and as I said in the last post, vacation is nearly here! So, update/download the library, check out the ASDocs in the source (I always update them for each release) and let me know what you all think.

Overview
The SelectionController allows you to group items similarly to how a radio group works in both HTML and Flex. The general principle with a radio group is that when one radio button is selected, any of the other radio buttons in the group are then deselected. This kind of selection occurs in Lists, DataGrids, etc.

The challenge is that in a highly stylized Flash/Flex applications we often need to treat custom components as a group. One example is my Wordpress PhotoSlider. When a user selects a thumbnail, the selected thumbnail is highlighted and the previously highlighted thumbnail is deselected.

A typical solution is to make the parent container smart enough to understand when an item is selected and then let the parent change the highlight state. This approach can get tricky when you have items that are deeply nested and don’t share an easily accessible common parent or if you have complex selection/deselection requirements that may span across multiple containers or even have selected children that are currently off the display stack.

To solve the easiest issues to the most complex selection challenges I developed a SelectionController that is a Singleton instance that manages selection of content for you. Items first need to implement the ISelectable interface and then they can be added to a selection group. When you want to select or deselect a group you can either pass in the group ID or you can pass in one of the items in the group to handle selection.

Examples
First, lets look at our item that we want to be selectable and then we will look at how you can select/deselect the item.

package com.vivisectingmedia.tutorial
{
	import com.vivisectingmedia.framework.controllers.SelectionController;
	import com.vivisectingmedia.framework.controllers.interfaces.ISelectable;
 
	import flash.events.MouseEvent;
 
	import mx.controls.Button;
 
	public class MySelectionButton extends Button implements ISelectable
	{
		// constructor
		public function MySelectionButton()
		{
			super();
		}
 
		/**
		 * The default method for when a Button is clicked.
		 * We override this method so that when a user clicks
		 * on this Button we select this item and deselect
		 * all the other Buttons in the group.
		 * 
		 * @param event Click event.
		 * 
		 */
		override protected function clickHandler(event:MouseEvent):void
		{
			super.clickHandler(event);
 
			// this item is now selected
			SelectionController.selectItem(this);
		}
 
		/**
		 * This setter is called when the SeletionController
		 * changes the Button's selection state.  Technically,
		 * we do not have to override this method because the Button
		 * Class already supports the selected getter/setter signature
		 * required by the ISelectable interface.
		 *  
		 * @param value True is selected, false is deselected.
		 * 
		 */		
		override public function set selected(value:Boolean):void
		{
			// store the private reference
			super.selected = value;
		}
 
		override public function get selected():Boolean
		{
			return super.selected;
		}
 
	}
}

A couple of notes about the above code. As I mentioned in the comments, we don’t really need to override the get/set method for selected. The Button Class already meets the ISelectable interface requirement, but you will still need to extend the Button class to add the ISelectable interface so that it works with the SelectionController. I overrode the code just to show you how you would need to implement this in a component that does not already support selection states. What I really want you to focus on is implements ISelectable and the clickHandler() method.

In the clickHandler() call we pass up the super.clickHandler() and then we call the SelectionController.selectItem() passing the component instance reference in as the argument. What this is telling the SelectionController to do is first, see if the passed item is in a selection group, if so, select the item by setting selected to true, and then set selected value to false on any other item in the selection group. The SelectionController is friendly enough that if the item passed in is not in a selection group, then the item is still selected and nothing else happens.

So how do you leverage the selection object? Let’s look at some examples:

// create some selectable items
var buttonOne:MySelectionButton = new MySelectionButton();
var buttonTwo:MySelectionButton = new MySelectionButton();
var buttonThree:MySelectionButton = new MySelectionButton();
 
// generate an group id to assign them to
var groupOne:int = SelectionController.generateNewId();
 
// assign the items to the group
SelectionController.addItem(buttonOne, groupOne);
SelectionController.addItem(buttonTwo, groupOne);
SelectionController.addItem(buttonThree, groupOne);

This is the basic use case for grouping items. First, we use a helper method to generate a new group ID. The ID is an int and it must be unique for each group. The generateNewId() returns the next ID number not in use. Once you have an ID you can then add items to the SelectionController using the addItem() method. This stores the reference of the item and pairs it with the group.

Because the MySelectionButton is built with the SelectionController in mind we don’t have to do anything else if we want these three buttons to behave as a group. When a user clicks one of the buttons in the group, the clickHandler calls the SelectionController and the SelectionController will then select the clicked button and deselect the rest.

What happens when you want to programatically select one item, or all of the items in the group or deselect all the items in the group? The SelectionController provides methods to handle these tasks:

// select one item
SelectionController.selectItem(buttonTwo);
 
// select all the items, first get the group if
// you don't know it
var currentGroup:int = SelectionController.getItemGroup(buttonOne);
 
// now select the group
SelectionController.selectAll(currentGroup);
 
// or you can deselect them all
SelectionController.deselectAll(currentGroup);

Considerations and Gotchas
As with all my tutorials, lets talk about things you should consider/know about the SelectionController that may cause you some trouble if you attempt to do certain things.

One group to an item. Selectable items can not be members of multiple groups and when a new group is applied the item is removed from the original group. For example:

// create a new group
var groupTwo:int = SelectionController.generateNewId();
 
// apply the group to ButtonTwo
SelectionController.addItem(buttonTwo, groupTwo);

Doing the above would remove ButtonTwo from groupOne and when you call selectAll() on groupOne only buttonOne and buttonThree would be selected.

Items are Strong referenced. When an item is added to a group it is strong referenced in memory. This means that if you want to delete the item so that Garbage Collection can be applied you need to remove the item form the SelectionController by calling removeItem(). This removes the item from the SelectionController and Garbage Collection can be applied when the next pass occurs.

Multi-Select is supported by not built in by default. If you want to create a multi-selectable grouping you can use the SelectionController for this kind of functionality, but you will need to add more logic to you selectable items. For example, we want our MySelectionButton’s to be multi-selectable when a user has the Control/Command key down. To do this in our example you would modify the clickHandler() like so:

override protected function clickHandler(event:MouseEvent):void
{
	super.clickHandler(event);
 
	if(event.ctrlKey)
	{
		// do not select using the controller
		this.selected = true;
	} else {
		// do select using the controller
		SelectionController.selectItem(this);
	}
}

The above example determines if the user is multi-selecting by checking the ctrlKey value in the MouseEvent. The MouseEvent passes true if the key is down and false if the key is up. In the case when the key is down we want the object selected but we don’t want the Controller to deselect the rest of the items in the group. Otherwise, we do want the rest of the items to be deselected, so use then use the Controller.

That is the basics of the SelectionController, play around with it and let me know if you need more examples, find any issues or have any questions with the Controller.

One of the challenges of writing an article like this is first defining your audience and then determining how to cover the topic in the alloted text. The Edge sets a word count guideline and this limits how deep I could or in this case could not go. Personally, I fully support the word count guide because this both focuses the topic and generates more digestible articles. Yet, on a topic as broad and as deep as this one I had to focus more on an introductory guide to coding standards and adoption.

The second challenge is determining your audience. My goal was to create an article that worked for both readers who have never heard of coding standards, and readers that have been using them for years. I always try to create a broad stripe across my reader base because I want to inform as many people as possible. This thought process was kind of beaten into me during my years as a Technical Support rep and team-lead at Macromedia. There is nothing like having to write Tech-notes and email support to teach you how to write to a broad audience.

The main point I wanted to get across with this article is that coding standards are actually much more then just code formating. Code formatting, or code conventions, really focus on how you name variables, methods, classes, etc. Yet, this is just the tip of the coding standards iceberg. One of the least discussed aspects of coding standards is the adoption and implementation practice of code design patterns. As developers, we need to better understand how adoption of patterns, frameworks and micro-architectures help structure our code. Not only do they provided rapid development but they also help guide us into a more structured development process.

As RIA and web application development expands we are seeing a demand for much more complex and scalable applications. Scalability is not just about user load but includes further expansion of features and performance over time. More and more developers are being asked to create applications that have a lifespan longer then just a few months. Some people may gaffe at that comment, but if you look at a lot of “rich” applications up to this point, most have been for marketing campaigns and advertising. The nature of these kinds of projects do not focus on lifespan and version updates. Their focus is on making them work in a short time to meet the marketing deadline and then get them out the door.

With the trend of Web 2.0 (which I hate as a term), the web world is quickly being pushed into the long standing Desktop Software model. This is forcing a lot of us to re-evaluate how we design and develop our online enabled applications. This is a scary yet wonderful time in our industry as we are rapidly adopting and developing new ways of web application design and construction. Due to this push I feel its time to help expose more of us to coding standards. My article is more a call to arms then a definitive guide to coding standards implementation. If you are interested, take a read and add your thoughts to the comments…

The big change is this version is the addition of the new SelectionController and ISelectable interface. The SelectionController is a manager that allows you to group any number of items that implement the ISelectable interface and then treat them as a Radio Group or multi-selectable group. With the controller you assign items to groups and then you can use the controller to select and deselect the items.

A great example of this code is how I handle image highlighting in the Photoslider. Each of my image thumbnails implement ISelectable and then when a user clicks a thumb it calls the SelectionController.selectItem() and passes itself as an argument. The SelectionController then sets selected on all the thumbnails in the group, setting true for the passed in item and false for the rest. I plan on doing a full tutorial in the near future so keep an eye out for it. Enjoy!

What Is a Singleton?
If you have never heard of the Singleton Pattern you are not alone, I know many senior Java and ActionScript developers that looked at me blankly when I brought up the pattern in passing. The core idea of the pattern is to solve the issue of when you need only once instance of an object that can be accessed globally in you application.

For example, you have a User object that stores the user information once they are logged in. Throughout your code you want to use this information and you also want to make sure that there is only once instance of this user data. One solution is to pass around a value that represents the user, yet there are many issues with this kind of approach. First, the code needs to understand this data and expect it when called. Second, what happens if the user logs out or changes the data, such as their address? The code needs to know this the next time its called. Passing it around gets ugly very very fast.

Another solution is to save the values in a global variable. But where should this live and how should it be accessed? Does it live in _root (really, really bad idea) or the top Application? What happens when your code gets nested in another application or is modularized? How can you find the data? This is where the singleton comes in. The Singleton pattern leverages the power of static properties and methods which are bound to the Class type itself. What!?! Let me show you:

package com.vivisectingmedia.example
{
	public class User
	{
		public var name:String;
		public var address:String;
		public var birthDate:Date;
	}
}

So there is our basic user class. Its just a simple data object class that stores our information. In most cases we create a new instance of it and then start manipulating it, such as:

var loggedInUser:User = new User();
loggedInUser.name = "Bob";
loggedInUser.address = "123 Market St.";
loggedInUser.birthData = new Date(1976, 4, 6);

In the above example we are working with an instance of a class. We used the constructor to generate the instance and we are manipulating the properties of that instance. In ActionScript 3.0 we can leverage the static keyword to define properties on the class itself:

package com.vivisectingmedia.example
{
	public class User
	{
		static public var name:String;
		static public var address:String;
		static public var birthDate:Date;
	}
}
....
 
// we now access the name value through the Class, not an instance
User.name = "Bob";
User.address = "123 Fake St.";
User.birthData = new Date(1976, 4, 6);

Those values are being set on the Class not on an instance. This means that when you change values in one part of the code and then access the class in other parts of the code the stored values are the same. In a way we have just defined a global data object that stores our user data. The Singleton pattern takes the ability to store values on the Class and then steps it up a notch.

In theory we could go in and mark EVERYTHING static but this is not ideal and can lead to complications. The better way is to create a hybrid of the first User class example and the second. We do this by exposing a static method on User that checks if an instance of User is created and if not creates one and then returns it. This part of the Singleton is kind of a mind-bender so lets just jump into code.

Defining Singletons in ActionScript
The core idea of the Singleton is to have static helper methods that manages our object instance by allowing only one instance to exist and also provides access to this instance. Using the User example (above) here is a complete Singleton which also follows the extendable pattern. Don’t worry if you don’t get all of it on the first pass, I will break it down step by step later.

package com.vivisectingmedia.example
{
	public class User
	{
		// stores our instance
		static private var __inst:User;
 
		// standard public properties
		public var name:String;
		public var address:String;
		public var birthDate:Date;
 
		// accessor for the instance
		static public function get instance():User
		{
			if(!__inst) __inst = new User(generateLock());
			return __inst;
		}
 
		// accessor for our SingletonLock
		static protected function generateLock():SingletonLock
		{
			return SingletonLock;
		}
 
		// our constructor, must be public in AS3
		public function User(lock:Class)
		{
			if(!lock is SingletonLock)
			{
				throw new Error("Invalid use of singleton.");
			}
		}
 
		// add public methods and such here
		public function get age():int
		{
			// calculate age and return it
			...
		}
 
		...
	}
}
 
class SingletonLock
{
	public function SingletonLock()
	{
 
	}
}

Let’s break this down step by step. First of all lets look at the static property __inst and the static method instance(). These two parts are the most important aspect of the Singleton pattern. So what are we doing in instance()? The first thing to notice is that the instance() method is both static and a getter with no setter which makes it read-only. We would use it like this:

// set the user's info and call the age() method
User.instance.name = "Fred";
User.instance.address = "123 Mission St."
User.instance.birthData = new Date(1978, 5, 14);
var age:int = User.instance.age;

What happens is we call the instance() method through the class reference of User, the instance() method then looks and sees if the __inst property is currently storing an instance of User, if not then we create a new instance of User, save it in __inst and then return the reference. This means the the second time we call instance on the User class, we have already created the instance of User and we just hand back the reference. That’s the magic of the Singleton right there, we now only have one instance of the class that is created exactly once and is created at the time you need it. You don’t need to worry about creating it in onCreationComplete() or in the Document class. The first time you access it the item creates itself. Pretty nifty, eh?

So what is all the other crap that is in this class? The rest of the code is both designed to help enforce Singleton usage in ActionScript and allow extending of the Singleton Class.

Protecting Singletons in ActionScript
One of the current limitations of AS3 is that constructors have to be public. In languages like Java they can be marked protected but not in AS3. This is being resolved in the ECMA 4 standard so when the new version of AS comes out we will not longer have to put all this enforcement code in.

Because constructors are always public there is nothing stopping a developer from ignoring the static instance getter and just creating an instance of the User class locally. This is a bad thing because we now have multiple instances of the object and this defeats the Singleton pattern. To help enforce this we use the SingletonLock as a special key that prevents the constructor from being used EXCEPT in instance() call and/or the extension process (more on extending later). Let’s look at the constructor again:

// our constructor, must be public in AS3
public function User(lock:Class)
{
	if(!lock is SingletonLock)
	{
		throw new Error("invalid use of singleton.");
	}
}

You will notice that the constructor expects one argument of type Class and then checks to make sure the passed in Class is of type SingletonLock, if not we throw an Error. SingletonLock is an internal class that is ONLY available to the User Class. We expose this class through a method called generateLock() which hands back the Class reference to the internal Class. The instance() method uses generateLock() to create the lock and pass it on to the constructor. By setting this structure up we have created an enforcement policy that only allows Classes with access to generateLock() to create an instance of the class. Take a moment to go back and walk through the entire User Class to make sure you understand this creation flow.

Its seems like overkill, but this kind of code is very important when working with open source projects or large teams. It forces developers to follow the pattern and prevents improper use of a Singleton based class. As I mentioned earlier this is only because AS3 does not allow protected or private constructors. In the future we can throw all this enforcement code away, but for now we should use it.

Extending A Singleton
Now that we have the Singleton how can we extended it and why would we ever want to? Very rarely would you want to extend a Singleton but it does come up. For me, the number one reason I want to extend Singletons is for automated unit testing.

Here is the situation: I have a series of unit tests that I want to run and each of the tests need to assume a clean instance of the Singleton exists. The challenge is that the tests all run in the same instance of the application (FlexUnit) and therefor the Singleton is created on the first test and the second test is now manipulating the previously created Singleton. Very bad for a testing environment.

One solution is that we expose a reset() method on the Singleton that enables the unit test to reset the Singleton instance. This is a bad approach because we really don’t want to expose this public method in the live version because we want to prevent users for resetting the Singleton, this reset() method is only for testing purposes.

The ideal solution is to extend the Singleton in the Test Suite and add the reset() method which is called on tearDown(). The test would use the extended instance so we are now able to verify the core Singleton functionality and still get reset() without exposing it for the deployed version. Here is how we would create a TestUser that extends our User example:

package com.vivisectingmedia.example
{
	public class TestUser extends User
	{
		// stores our instance
		static private var __inst:TestUser;
 
		// accessor for the instance
		static public function get instance():TestUser
		{
			if(!__inst) __inst = new TestUser(generateLock());
			return __inst;
		}
 
		static public function reset():void
		{
			__inst = new TestUser(generateLock());
		}
 
		// our constructor, must be public in AS3
		public function TestUser(lock:Class)
		{
			super(lock);
		}
	}
}

What changed? First we still define the static private instance but we type it as TestUser. The value has to be private because the __inst has to be specific to the Class its defined in. Remember that static properties and methods are bound to the Class itself. Things get a little tricky here so let me see if I can explain it.

We could try and set __inst as protected property on the User class. When the user calls instance() on TestUser we could create the TestUser instance, store it in the the protected __inst version on User since TestUser is a User. We could then cast __inst as a TestUser for the return call.

// accessor for the instance
static public function get instance():TestUser
{
	if(!__inst) __inst = new TestUser(generateLock());
	return TestUser(__inst);
}

The problem with this approach is that if you called User.instance first then tried TestUser.instance you will get an error because __inst is holding the User instance and User can not be upcasted to TestUser. The solution is to keep the __inst separate in each Class to prevent this possible issue. The added benefit is that you can have a User instance and TestUser instance living side by side which is awesome if you are extending the Singleton for other purposes.

The next thing we did is redefined instance(). Notice how I did not have to use override? Static methods are bound only to the Class and not any children that extend the Class. We have to redefine it to expose it on TestUser. Also, notice that the code is creating a TestUser and passing in the parents protected generateLock() call. Make sure to look at how we changed the constructor. We still expect the lock and we pass the generated lock on the to the super call.

This is exactly why we use a generateLock() method and pass a Class reference around. Up to this point a lot of developers (myself included) used the following style for defining the constructor:

// accessor for the instance
static public function get instance():User
{
	if(!__inst) __inst = new User(new SingletonLock());
	return __inst;
}
 
// our constructor, must be public in AS3
public function User(lock:SingletonLock)
{
	...
}

The issue with this structure is that you can not extend User because the constructor signature requires knowledge of the SingletonLock class which is an internal class of User and therefore only User can access it. By replacing the lock as a Class we can still secure the Singleton by validating the passed lock but we can easily extend it since we are expecting type Class in place of type SingletonLock.

Now that we have fully extended out Class we can add our reset() method which then overwrites the __inst. That’s how you can build and extend singletons in ActionScript. As always please let me know if you see any errors or have any questions about how this all works.