Attaching a Bitmap – AS2 vs AS3

A common task that has changed drastically in ActionScript 3.0 is loading a library image via its linkageID into a BitmapData object and attaching it to a movieclip. In ActionScript 2.0, this can be done like so:

In ActionScript 3.0 movieclips and bitmaps are not attached or created like this – everything is created with the new keyword. Also, a BitmapData object should be dropped into a new Bitmap, which can be added to the stage with the all-important addChild() method.

Since a library bitmap inherits from BitmapData, you now set the class of the bitmap its Linkage Properties in Flash CS3, instantiate it and wrap it in a Bitmap object that you add to the stage:

Attaching a bitmap in AS3

Where ‘Butterfly’ refers to the bitmap library item you’ve given the class definition ‘Butterfly’. The Base class is generated automatically. These five lines of code can be shortened to one, but is less readable:

Note that in Flex Builder, unlike Flash CS3, you would embed an image using the embed meta tag, associating it with a variable, instead of its Linkage Properties dialog:

Building SWFs in Flex Builder is a whole different topic – so stay tuned!

XML within a class

I was recently asked about the problem of loading XML from within a class to trigger an arbitrary method. The problem was: the onLoad event triggers on the XML instance, not the class creating it. This could probably be worked around with the Delegate class, but in the past I’ve simply extended the XML class itself, overriding the onLoad handler and adding a callback object that’s passed in (along with some error checking). It’s partnered with an XMLLoader class, the source and simple demo of which you can download here.

A load of garbage collection

I recently had the pleasure of debugging an AS3 image viewer application that was crashing after an hour. It seemed to be some kind of memory leak, so I looked for objects not being cleared up by the Flash Player’s garbage collector. I found that, even with AS3’s mark and sweep garbage collection, BitmapData objects left stranded (with no external references) still hog RAM, even when their DisplayObject is deleted.

A similar problem existed in AS2, but will be more acute in AS3 I think, because removing a child DisplayObject from a display list does not delete it (as removeMovieClip() would in AS1/2). Try the following example with your Windows Task Manager or Mac Activity Monitor running, you should see what I mean:

Once the cleanup function runs, all of main’s sprites are removed from the display list, with no more references to them – so the garbage collector should clean things up. But it won’t dispose of the BitmapData objects automatically, so you eventually run out of RAM! This problem of memory hogging occurs even if you keep references to all the clips (in an array for example) and set them to null after removing them from the display hierarchy.

I can see a lot of problems occurring as developers move to AS3 without a firm understanding of how garbage collection works. One answer would be to manually dispose of BitmapData objects or handle the REMOVED_FROM_STAGE event and perform a cleanup as necessary. Here’s quick and dirty fix that cures the memory leak:

Design Patterns

I went to an interesting talk on Enterprise Integration Patterns at SkillsMatter the other day. Though aimed primarily at Java developers, there was not a scrap of code and the concepts discussed could apply to development in almost any language.

The focus of the talk was: good, simple code design versus just using lots of clever inheritance to create complex-looking, unmaintainable frameworks. Common sense really – it’s the kind of ‘form over function’ approach that we’re all too aware of plaguing the creative world that applies to programmers too. I’m sure many developers (especially us contractors) have personal experience of this. Be it having to use over-complicated web services, where three lines of PHP would do the trick. Or being forced to base a project on some client’s ailing framework, written in the dark ages, with little or no support.

However, it’s the reality of having to integrate with a host of unknown systems that keeps the job interesting, I suppose. It does mean, however, that the Holy Grail of code reuse (even across similar projects) doesn’t often happen the way we’d like. How many times have I heard “it’s OK, this half-finished project is all in classes, so it should be easy to repurpose”?

With such specific requirements to any individual project, some classes and knowledge can be reused, but the more complex the program structure, the more difficult it is to grasp mentally. Also, design patterns mean exactly that: patterns. Not: “this is the way we do every project”, but general approaches you learn from experience are more apt for a given task.

Back to school

As you can see, I’ve started a blog. I’ve also officially made the leap to ActionScript 3.0 for all my production. Some things I have noticed:

  • Your memory management needs to be fastidious to avoid memory leaks and weird behaviour (more on this later)
  • It feels more like a real programming language at last
  • It runs A LOT faster. Tell a client this, if they’ve got you maintaining some AS2 dead horse

I’ll be posting stuff I learn about AS3 that you should know as I go… so stay tuned.

making cool things