Month: September 2007

As an AIR developer, I am in the position to feel it's problems more than it's capabilities. AIR's lack of extensibility is not an issue because that can be dealt with early enough to be a non-issue. Currently, my deepest concern lies with memory management: how do I keep memory consumption under control?
I am aware of all the potential sources of memory leaks (why are'nt event listeners using weak references by default? why does GC have to be so dumb that it'll dump ongoing HTTP request when nothing is holding a reference to URLLoader? Isn't an activity a reasonable reference?) so I've tried to deal with them proactively but, lacking sufficient tools, I haven't been able to pinpoint and address all the memory leaks, the kind that prevents my app from running for days. My AIR app starts off under 20mb on PC and 50mb on Mac (I have no idea why AIR burns more memory on Mac than PC) then starts adding about 10 meg per day. Reactive nature of AIR GC is not the issue because I've tried forcing GC proactively and can still observe leaks. As it stands, I can demo my app but it's definitely not ready for deployment because of the memory creep.
If Adobe wants AIR to succeed, they must offer better tools that enable developers to get a better handle on memory management because it's all too easy to make leak memory in AIR apps (try writing an Ajax-Flash hybrid AIR app, a double whamy of leak heaven). BTW, I am not interested in direct contact by AIR team to resolve my problems because, when I blog about a problem, it's almost never about just my problem.

Update:

Memory situation has been greatly improved by beta2 release of AIR. I still need to do more testing but memory footprint appears to be 10%~20% less and leaks down from torrent to trickle. I can sleep at night at this level. 🙂 Only sour part is that profiler will only be in the professional version of Flex Builder 3. Oh, well. I tried.

I use Aptana plugin to write Flash/Flex/AIR in Eclipse. For AIR in particular, Aptana's AIR app launcher is great. However, one key component missing from Aptana is ActionScript 3 (aka AS3) editor. I've been limping along by mapping .as files to Java editor but I just remembered an old Eclipse plugin that used a template to control syntax coloring. So I went looking and found it here: color editor. It was still being maintained. Woot.
It comes with AS2 support but not AS3 so I went searching again and found the mode file for AS3 here: actionscript 3 syntax hilighting for jEdit. The color editor reuses jEdit's syntax coloring mode files. Almost there.
I expanded the color editor jar file into Eclipse 3.2 plugins directory then dropped the jEdit AS3 module ("actionscript.xml" file) into it's 'modes' directory. Restart Eclipse and used Open With to open some .as files. Eeeks. Too colorful to say the least. The color editor came with color preference settings panel so I changed the colors approximately match that of Java colors. Better.
Then I noticed that some keywords were missing (new, delete, super, etc.) so I added them to the actionscript.xml file and went back to coding. Note that Color Editor doesn't fully understand AS3, just enough to add some colors which I find useful.
BTW, TextMate Bundle for AS3 can be found in TextMate code repository.

Update:

Color Editor was hanging on some seeminly innocent looking javascript code so now I am back to using Java editor to edit ActionScript. Damn.