During a recent project of ours we found ourselves in the position where the developer creating the server-side code was a full 5 time zones away. This meant that we often had to do debugging over email. This was, as one would expect, excruciatingly slow. The issues that arose during integration almost always resolved around how we were mapping the servers .Net classes to our AS3 classes - one small change to the server class could break things on our end in a non-obvious way.

Luckily early in this process we discovered a piece of shareware called Charles, a web debugging proxy that’s available for Mac, PC, and Linux. Once you fire Charles up it acts as a proxy for all of your web traffic. This lets you capture, view, and even throttle the data that’s flowing between your machine and the web server. And best of all for us, it lets you view inside of AMF packets and see exactly what’s coming over the wire. Once we got Charles up and working we able to tackle kind of issues that used to take us hours and resolve them in minutes.

We haven’t done a done with Charles yet, but so far our only wish is that we knew about it sooner. Suffice it to say that we found the $50 registration fee to be well worth it!

Branden and I were working in the office today when Branden came over and asked me if I’ve ever run into the following problem:

You are creating tweens using the Tween class in AS3. These tweens are inside of a method (or a loop). The tweens appear to work fine, except, they stop in the middle without explanation. As it turns out, I had run into this problem before. While working on a previous project, I had a series of tweens moving around a Rectangle object inside a class method. Halfway through the tween, it stopped for no apparent reason. After using everyone’s favorite inter-web fast-food chain, Google, I determined that the issue must be due to garbage collection. I typed in “AS3 tween garbage collection”, and found that my problem had been solved and discussed by Scott Morgan. Here’s his blog post about it.

The solution, as described by Scott is to create class properties for your tweens instead of local variables. As I described this to Branden, he noted a potential problem with this solution. When you use class properties, the Flash player will allocate space for those properties, even when you are not using them. Why is this a problem? Well, imagine you can potentially have hundreds of instances of a class, where each instance contains private properties for 5 tweens. This could significantly hurt the performance of your application since you will have allocated space for all of those tweens, even though the tweens are not running. Needless to say, while this is a good solution, and great in a pinch, ultimately, you will have problems for large numbers of tweens.

So, how do you solve the secondary problem of allocating space for tweens that are not running? Is there a way to use a class property to store the tween (so it is not killed by the garbage collector), without actually allocating space until the tween is needed?

The answer: DICTIONARY!

Instead of creating a property for each tween you use, instead, create a single property of type flash.utils.Dictionary. The Dictionary class allows you to create a set of dynamic properties, without allocating the space for them until the property is actually created. Additionally, you can also use an object reference as a key in a dictionary, which can be a very powerful tool. Once you have your dictionary, inside the method (or loop) that creates the tweens, store the tween object reference as the key in the dictionary. Once your tween is complete, delete the key and your tween will be collected by the garbage collector.

Here’s an example:

• Source Code

Branden and I were working in the office today when Branden came over and asked me if I’ve ever run into the following problem:

You are creating tweens using the Tween class in AS3. These tweens are inside of a method (or a loop). The tweens appear to work fine, except, they stop in the middle without explanation. As it turns out, I had run into this problem before. While working on a previous project, I had a series of tweens moving around a Rectangle object inside a class method. Halfway through the tween, it stopped for no apparent reason. After using everyone’s favorite inter-web fast-food chain, Google, I determined that the issue must be due to garbage collection. I typed in “AS3 tween garbage collection”, and found that my problem had been solved and discussed by Scott Morgan. Here’s his blog post about it.

The solution, as described by Scott is to create class properties for your tweens instead of local variables. As I described this to Branden, he noted a potential problem with this solution. When you use class properties, the Flash player will allocate space for those properties, even when you are not using them. Why is this a problem? Well, imagine you can potentially have hundreds of instances of a class, where each instance contains private properties for 5 tweens. This could significantly hurt the performance of your application since you will have allocated space for all of those tweens, even though the tweens are not running. Needless to say, while this is a good solution, and great in a pinch, ultimately, you will have problems for large numbers of tweens.

So, how do you solve the secondary problem of allocating space for tweens that are not running? Is there a way to use a class property to store the tween (so it is not killed by the garbage collector), without actually allocating space until the tween is needed?

The answer: DICTIONARY!

Instead of creating a property for each tween you use, instead, create a single property of type flash.utils.Dictionary. The Dictionary class allows you to create a set of dynamic properties, without allocating the space for them until the property is actually created. Additionally, you can also use an object reference as a key in a dictionary, which can be a very powerful tool. Once you have your dictionary, inside the method (or loop) that creates the tweens, store the tween object reference as the key in the dictionary. Once your tween is complete, delete the key and your tween will be collected by the garbage collector.

Here’s an example:

• Source Code

Just as a public service message - it’s not “auto-mata” - it rhymes with “manamana” as demonstrated by the Muppet Show:

(Thanks to Tom Pizer over at Performtech who dug up the video)

I’ve been dealing with piles of two types of files that are somewhat awkward to work with on the Mac - ZIP files and EPS files. On the PC I can just double click on a ZIP file and peer into what’s inside without actually unzipping it, on the Mac, not so much. When it comes to EPS files, I’ll open then with preview and then get a lovely spinning beachball while it is “Converting Postscript to PDF…”. Now admittedly it’s faster on Leopard that it was on Tiger, but still, that sucks. Luckily these are exactly the kinds of problems Quicklook was made to handle.

If you haven’t played with Quicklook, you just select a file and hit the spacebar - you then get a preview of the contents of the file. By default it works with iWork formats, and all the usual MS Office formats. The best part though is that third parties can write their own plugins for Quicklook - and developers have already made some for ZIP and EPS! Now I just select either file type and smack the spacebar and BAM! almost immediately I can peer inside of ZIP files or preview EPS files.

It’s times like these I *really* love the Mac developer community (and Apple ain’t half bad either, though I’m still not fully digging Stacks!).

• ZIP Quicklook Plugin
• EPS Quicklook Plugin

The slides from Branden’s presentation at FITC Hollywood 2007, Flash on the Beach 2007, and FITC Winnipeg 2007 - “The Nooks and Crannies of ActionScript 3″ are now available for download. Enjoy - and if you have any questions or comments drop us a line.

• The Nooks and Crannies of ActionScript 3

The slides from Branden’s presentation at FITC Hollywood 2007, Flash on the Beach 2007, and FITC Winnipeg 2007 - “The Nooks and Crannies of ActionScript 3″ are now available for download. Enjoy - and if you have any questions or comments drop us a line.

• The Nooks and Crannies of ActionScript 3

The slides from Branden’s presentation at FITC Hollywood 2007, Flash on the Beach 2007, and FITC Winnipeg 2007 - “The Nooks and Crannies of ActionScript 3″ are now available for download. Enjoy - and if you have any questions or comments drop us a line.

• The Nooks and Crannies of ActionScript 3

Branden will be speaking this weekend at The FITC Road Show - Winnepeg 2007. This will be Branden’s first time in Winnepeg and he’s hoping to not lose any vital body parts to frostbite!

The notes from his talk “The Nooks and Crannies of ActionScript 3″ will be available on the site soon.

Lately I’ve been dinking around with a wonderful library for Python called Twisted. Twisted is a networking library that makes creating custom clients and servers insanely easy.

Like a lot of good libraries Twisted starts off with a philosophy (think Ruby on Rails, etc) - in Twisted’s case it’s “You don’t call Twisted, Twisted calls you”. If that immediately makes you think “hey they must be doing some neat things with events!” then you’re right.

When you’re using Twisted and you call a function that needs to do some sort of work where it will takes some time for the result to be available you don’t have to wait for that result to come. Instead the function immediately returns an instance of the Deferred class. What is the Deferred class you ask? Well, I think the Twisted manual explains it best:

Twisted uses the Deferred object to manage the callback sequence. The client application attaches a series of functions to the deferred to be called in order when the results of the asychronous request are available (this series of functions is known as a series of callbacks, or a callback chain), together with a series of functions to be called if there is an error in the asychronous request (known as a series of errbacks or an errback chain). The asychronous library code calls the first callback when the result is available, or the first errback when an error occurs, and the Deferred object then hands the results of each callback or errback function to the next function in the chain.

I happen to think that’s a pretty neat take on chaining events and am seriously debating creating a similar system for a new little project I’m working on that will involve a lot of async programming.

In general finding this concept reminds me about why it’s so important to go outside of your usual mental playground and find other places where developers are playing. Almost every time I do this and go look at something like Python or Objective C or Haskell I end up finding a concept I want to port over to one of my usual tools.