In ActionScript 3, class constructors can only be set to public. Adobe has stated that this is because the ECMAScript specification is not yet complete, and they did not want to break forwards compatibility with the specification. This makes a lot of sense, but it leaves AS3 developers without a clear way to implement the Singleton design pattern. Luckily, there are a couple ways of faking Singleton functionality. Both solutions are kind of hack-ish, but they get the job done.

Continue reading →

I think one of the handiest new features in ActionScript 3 is the Dictionary object, which lives in the flash.utils package. It is a new object type that allows you to associate a value with an object key. This is similar to how array associates values with numeric indexes, and how you can use a generic object to associate a value with a string key.

// Arrays use numeric indexes:
var arr:Array = new Array();
arr[0] = "value";
// Generic objects use string indexes:
var obj:Object = new Object();
obj["key"] = "value";
// Dictionary uses object keys:
var dict:Dictionary = new Dictionary();
dict[myObj] = "value";

Continue reading →

I will be dealing with this in the next installment of my resource management series of articles, but I thought it was important enough to warrant a quick post in the interim.

I’ve been blogging about how important resource management is going to be in ActionScript 3, and also mentioned that we have some new tools to deal with it. One of these new tools is the ability to have weakly referenced event listeners. A weak reference is one that is not counted by the Garbage Collector (ie. it is not counted in reference counting, and it is not followed for mark sweeping). This means that if the only references remaining to an object are weak, it will be available for collection on the next GC sweep.

References associated with event listeners are often forgotten by developers, which normally results in the listener never being removed from memory. This is why weakly referenced event listeners are so handy in AS3 – if you forget to remove the listener, you will not impede the Garbage Collector’s ability to collect the object.

Continue reading →

ActionScript 3 has empowered Flash developers with faster code execution and a ton of API enhancements. Unfortunately, it has also led to the need for a much higher level of developer responsibility than ever before. In order to prepare and educate developers on how to deal with some of this new responsibility, I am writing a series of articles on resource management in AS3, Flex 2, and Flash 9. The first of these articles discussed the mechanics of the Garbage Collector in Flash Player 9. This article will focus on the implications some of the new features of AS3 have on resource management, and the potential headaches they could cause you even in simple projects. The next article in the series will introduce some of the new tools we have at our disposal to deal with these issues.

The biggest change in AS3 that affects resource management is the new display list model. In Flash Player 8 and below, when a display object was removed from the screen (with removeMovie or unloadMovie), it and all of its descendants were immediately removed from memory, and halted all code execution. Flash Player 9 introduces a much more flexible display list model, where display objects (Sprites, MovieClips, etc) are treated the same as normal objects. This means that developers can now do really cool things like reparenting (moving a DO from one display list to another), and instantiating display objects from loaded SWFs. Unfortunately, it also means that display objects are now treated the same as every other object by the Garbage Collector, which raises a whole slew of interesting (and possibly non-obvious) issues.

Continue reading →

In the comments of my previous post about how the garbage collector works in Flash Player 9, Cédric Néhémie asked a great question about why using delete on a property of a sealed (non-dynamic) class throws an error in ActionScript 3, and whether it will delete the actual object in memory.

There isn’t a lot of documentation on this topic, and what there is is hard to find, so much the following is conjecture and interpolation from related exploration, but I think it is fairly accurate. If not, please let me know in the comments – I don’t want to lead anyone astray.

My understanding is that the delete keyword deletes the actual variable definition, not just the variable’s value. This of course frees any reference it was holding, potentially freeing that object for garbage collection (as described in my previous article). It will not delete the referenced object from memory directly.

Continue reading →

I’ve been playing around with AS3 for a while now, and am really excited by its capabilities. The raw execution speed by itself will create so many possibilities. Toss in E4X, Sockets, ByteArrays, new display list model, RegEx, a formalized event and error model, and a few dozen other features for flavour, and you have a pretty heady brew.

With great power comes great responsibility, and this will be very true for AS3. A side effect of all this new control is that the Garbage Collector is no longer able to make as many assumptions about what it should tidy up automatically for you. This means that Flash developers moving to AS3 will need to develop a very strong understanding of how the GC operates, and how to work with it effectively. Building even seemingly simple games or applications without this knowledge can easily result in SWFs that can leak like a sieve, hogging all of a system’s resources (CPU/RAM), and causing the user’s system to hang (potentially even forcing them to hard reboot their computer).

Continue reading →