I ran a smack into possibly serious problem with AIR on Sunday. The problem was that a closed Window (mx.core.Window) was not GCing because there were about 100 references (according to Flex Builder 3 even after forced GC) to the window instance after it closed, none explicitly by my code btw. There were all references from within (children of or owned by the window) or bindings from parts of the window (all too easy to do with MXML magic like an online jailbait dating service) to my model layer.
Looking at Window.close method, all it does is tell its native window to close and remove itself from the system manager it belongs to. Hmm. Supposedly, child controls are smart enough to recognize when it's taken off the 'stage' and removing references but, apparently, it's not happening. And looking at binding implementation and generated glue code, I don't see how anyone can avoid memory leak problems with even moderately complex application lifecycle scenarios.
But then, by the time you find yourself in serious need of a diaper, you would have invested enough time to write a small mound of code and paid $700 (for FB3) to see a nice table of leaks. Gosh, all this is making me happy enough to wet my pants. What a Sunday.

Unless I am mistaken, US stock market's about to break it's back. All the charts I've read just smells wrong and I fear this leg will be a long one, could be longer if China's crazy stock market shatters as result. Oy. I hope I am wrong.

Looked at APML (Attention Profiling Mark-up Language) spec this morning. First impressions are that it's doesn't offer enough and unnecessarily verbose. Essentially, APML models a person's attention with an open set of 'concepts', name/value pairs where name is subject of interest and value is degree of interest or disinterest (-1.0 to +1.0).
Their model for attention seem to simple. For example, time factor has strong influence on what a person is interested in. How do you represent duration and immediacy of interest? Also, interest is often goal-driven and expire as soon as associated goal is met. For example, I was interested in Prius when I was looking for a car for my wife but now I am not. Note that time and goal are related factors.

Anyway, I've joined APML mailing list. 

I don't know if Facebook traffic is tanking or not but I do know that I haven't been visiting Facebook as often as before and noticing more spam-like notifications from Facebook in my mailbox. And it's pretty difficult to find even a handful of Facebook apps I can point to as being really useful.

I doubt MySpace will fare better with their upcoming upgrade. Silos just don't make great application platform and mashups are just windows bound to be closed. Something has to give here and now.

Appily will show ads in the final version (maybe even sooner to test various approaches). Frankly, I dislike inline ads like Pownce displays because mixing ads with messages from friends is just plain icky. Maybe others feel differently but I think the most boring approach, AIM, is the best way.

While the format is likely to be old-fashion, content will be very different. More on this later. I would like to talk to interested ad networks to discuss ways to integrate new types of ads.

Whether comment support is essential for blogs or not, I think blog comments can be improved on. Simple list of comments is just too flat and boring. And best comments tend to be buried in a pile of me toos, silly jokes, and troll craps.

I think post writer should be able to highlight comments they like so they stand out. Post writer should also be able to exile comments they don't like to a secondary unindexed comment page where comments from unverified commenters can go as well.

I also think post readers should also be able to 'favorite' comments, digg-in-a-bucket like.

Just dumping ideas to reduce brain fart before starting work. ;-p

I am happy to see AIR b2 released but the tailwind it caused some minor migration head scratching. Change list in AIR release notes was helpful so don't miss that. The main problems I had were:

1. Getting adt to work again because code signing is now required. Solution: generate a self-signed cert (see below).
2. Embedded WebKit browser wasn't firing event handlers injected dynamically using innerHTML. Solution: hook them using DOM methods. JQuery comes in handy for this.

A common hassle is routing hyperlinks in DHTML to default browser. I haven't found a way to do this automatically so I am marking all external links with 'xlink' CSS style and injecting click event handler that block default behavior and route href to air.navigateToURL, messy but easy with jQuery.

Generate self-signed cert:

adt -certificate -cn Foo [-ou org_unit][-o org_name][-c country] ("1024-RSA"|"2048-RSA") {pfx_file_name} {password}

Sign AIR file using the cert:

adt -package -certificate foo.pfx -password 123456 … 
 

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.

Since Dave Winer is working on OPML 2.0 spec again, I thought I should write about an idea I had that'll help people discover, document, and reuse extension attributues. The idea is to create a wiki for OPML attributes and use wiki page URLs as namespace URIs. The wiki should have three URL types: namespace, attribute, and profile.
An OPML namespace wiki page lists attributes in the namespace. An OPML attribute wiki page documents the attribute and its value. An OPML profile wiki page is intended to capture common practice by listing attributes used in practice. A namespace qualified extension element in OPML head could simply point to the profile page attributes used can be understood in context of the application domain.
That's it. This suggestion requires no change to the spec and one optional extension element in return for a place where all OPML attributes and common profiles can be documented. I think it's a bargain. A step beyond this is introducing wikified-microformating to generate schema info from then pipe that to OPML validators so that OPML documents can be validated throughly without skimping on extensibility.