You are currently browsing archived articles from

Enforcing an all static API in ActionScript 3

Friday, September 28th, 2007

It is quite common when designing an API or system in Adobe Flex that you will identify certain areas which call for specific classes to contain an all static API.

Typically, all-static classes are utilized as helper, utility and factory classes which provide static methods for performing common utility methods.

A commonly overlooked aspect of such designs is the assumption that an all-static class will not be misused by clients, specifically via instance instantiation, as it is assumed by the designer that an all static class would never be instantiated as there are no instance members available, only static class members. This is a fair assumption. However it is not possible to guarantee this will never occur as ActionScript 3 does not support private constructors (yes, I am back on this subject yet again). Although this is an unfortunate limitation of the language it should not deter you from enforcing such restrictions.

To help facilitate these restrictions in my own designs I have created a very simple, yet effective Abstract class called AbstractStaticBase, which helper and utility classes can extend in order to ensure they are never instantiated.

Classes which contain an all static API can extend AbstractStaticBase in order to ensure they can never be instantiated. This is the only requirement.

AbstractStaticBase is lightweight as it only contains a constructor. The constructor does nothing more than create an Error object and parse the call stack to determine the fully qualified name of the concrete class which has been instantiated, the message property is then set on the Error object and thrown.

Implementation on the clients part is very straightforward as all that is required is to extend AbstractStaticBase.

Consider the following example. CalcUtil is an all static class, to ensure an instance of CalcUtil is never instantiated simply extend AbstractStaticBase as follows:

So if you want to enforce that static classes are never instantiated, simply extend AbstractStaticBase.

Multiton Pattern in ActionScript 3

Wednesday, September 26th, 2007

If you are familiar with the standard GoF Patterns than you more than likely are aware of the Singleton Pattern and the solutions which it provides.

For those of you who are not familiar with the Singleton Pattern it is a Creational Pattern which, when implemented as prescribed ensures only one instance of a class is ever instantiated. This is facilitated via a single global access point from which a singleton instance is to be created and or retrieved.

You may be wondering just what the Singleton Pattern has to do with the Multiton Pattern? And how does the Singleton pattern relate to the Multiton pattern? What are the differences and what are the similarities?

To answer your question the Multiton pattern is a Creational pattern which builds on the concept of the Singleton pattern by adding a mapping of key / value [object] pairs.

Unlike the Singleton Pattern, whereas there is only ever a single instance of an object created, the Multiton pattern ensures that only a single instance of an object is created per key. Therefore there are multiple instances which are managed via the Multiton object. The Multiton pattern provides centralized access of Multiton objects and advocates keyed storage of objects within a system.

Below is a simple example which demonstrates an implementation of the Multiton Pattern in ActionScript 3.0:

Here is a breakdown of the above example.

First a new class is created as well as an additional inner class outside of the package which is used to ensure the constructor can only be called from within the class body, in this case the Multiton class.

Next a private or protected static var of type HashMap (optionally, a generic Object or Dictionary can be substituted) is defined. The static HashMap instance contains the mappings of keys to objects in the Multiton class. Each key only ever contains a single Multiton object instance, and each Multiton instance can only be accessed by it’s associated key.

Lastly, Multiton implementations require a public static method; getInstance(); which is very similar to the static getInstance() as it applies to the Singleton pattern, but with a slightly different signature. The getInstance(); method in a Multiton requires a single parameter which specifies the key from which a new instance is to be assigned and / or retrieved.

Certain Multiton implementations use an object as the key, however it is arguably more intuitive to use a primitive type such as a String to define keys. Regardless, I prefer not to enforce type restraints as the implementation will typically depend on the context in which it is being applied.

To implement a Multiton instance all that is needed is to invoke the static getInstance(); on the Multiton class object just as one would invoke getInstance() on a singleton class object. However in the Multiton it is assumed that there will be many instances, albeit controlled instances, therefore a key must be specified.

Below is a simple example which demonstrates how to retrieve a specific instance of a Multiton object:

There is not to much documentation on the Multiton Pattern outside of the Ruby community and a Java implementation available on wikipedia, however the Multiton Pattern proves very useful when multiple, controlled object instances are needed.

AS3 QueryString API Update

Friday, September 21st, 2007

I have upgraded the QueryString API from an all static utility class to a much more robust API which now supports parsing, inspecting and modifying query strings.

The new QueryString API retrieves a query string for a Flex application via ExternalInterface. Therefore a query string which has been supplied to an application can be retrieved from an html wrapper (e.g. .html, .jsp, .aspx, etc) as well as a .swf file.

Developers can also utilize the new API to perform CRUD operations on an arbitrary query string supplied to the QueryString constructor. I have also added complete support for encoding and decoding a query string as well as appending a query string to separate URLs.

Modifications of a QueryString are now fully supported and allow parameters in a QueryString object to be created, read, updated and deleted.

The QueryString constructor takes a url as an argument. This argument is optional, and, if specified instructs the QueryString object to use the specified url for all subsequent operations. If the url is not specified the QueryString object will assume the aplication query string is to be used for all operations.

Unfortunately, ActionScript 3 does not support constructor / method overloading so the url parameter is used to achieve the correct functionality based on context.

Below is a typical use-case which demonstrates how to instantiate a new QueryString object which defaults to the application’s querystring:

Optionally, you can choose to use a specific QueryString by passing it to the constructor:

Additional usage examples for all method can be found in the accompanying ASDoc.

You can view the source for the IQueryString interface and concrete QueryString implementation as well as the asdocs.

QueryString API is protected under the MIT license.

Adobe Thermo?

Tuesday, September 18th, 2007

So what exactly is Adobe Thermo? Or at least what is this new product from Adobe which has been codenamed “Thermo”? I don’t think anyone outside of Adobe really knows for sure just yet…

Based on what I have read so far “Thermo” appears to be a cool new tool which will allow creative professionals to leverage their existing skills to build RIAs utilizing tools they are comfortable with such as the Adobe Creative Suite product line.

Regardless of the specifics, one thing is for certain – any new tool which builds on the Adobe Flash Platform can only be a good thing for RIA developers specializing in Adobe technologies.

So I guess we will just have to wait for MAX 2007 / Chicago in 2 weeks to find out more.

For more information check out Mark Anders post on Thermo.

Static constant definition utility

Sunday, September 16th, 2007

I recently was working on an application where I needed to verify that certain static constants were defined by a specific class. I have run into similar situations like this before so I decided to write a simple utility which I could reuse.

ConstantDefinitionUtil is an all static class which provides an API for determining if specific constants have been defined by a class.

Additionally, ConstantDefinitionUtil provides a method for retrieving all static constants which have been defined by a class.

The following example demonstrates how ConstantDefinitionUtil can be utilized to determine if the static constant “X” has been defined by ClassA:

ConstantDefinitionUtil.as

ComboBox.prompt

Tuesday, September 11th, 2007

This is one of those little things that you come across from time to time and think to yourself, “man, how did I not come across this before?”.

There has been so many times where I have added an item to a collection in order to display a message to the user. For instance, say you have a ComboBox that displays a list of employees and you want to add a message as the first item, specifying something to the extent of “Select an employee”. Typically, an item would need to be added to the dataProvider of the ComboBox at index 0. Then the issue arises where you will then need to take this item into account when it is selected so that it will be ignored.

Well, like most things in Flex there is an out of the box solution!

The solution is the prompt property which can be utilized to facilitate exactly this sort of thing. I stumbled across this property accidentally while extending ComboBox and viewing the source code. The prompt property simple adds an item to it’s data provider at -1. Since Array indexing begins at zero, this item is ignored and you do not have to take it into account when working with the data provider.

Hope this helps someone down the road.