bunnyhero dev

No new features: just rebuilt and repackaged to run on AIR beta 3. Note that the newest AIR beta properly displays animated GIFs, which makes this silly app look much better :)

I did have to make a change from the original version, to conform to the new AIR HTML security model. My original code used setInterval, with a string to execute as the first parameter. This is a no-no in the new security model (since the executable string is the equivalent of an eval). I could have put the whole thing into an iframe in a non-application sandbox, but instead I used the AIR-native Timer class, which did the trick.

Download the updated Monster Attack! (requires Adobe AIR beta 3)

My crappy cellphone pictures from the on AIR Bus Tour event. The food was amazing. Check out the chocolate fountain!

Also see public photos on Flickr from the event.

Well that was easy!

I made a quick AIR version of my monster attack “application”. The copy of AIR for JavaScript Developers Pocket Guide that they gave us at the on AIR Tour Bus event was very helpful (along with the demos that they actually presented at the event).

All I had to do was create the application descriptor XML file and add a bit of AIR code (in JavaScript) to maximize the window and make it “always on top” (or alwaysInFront in the AIR API), and voilà: monster attacking your desktop!

It’s not quite finished though. The biggest problem is that the current beta of the AIR runtime does not display animated GIFs correctly (it just displays the first frame), so the fires do not look right (this is a known bug and should be fixed by the 1.0 release of AIR). I may change the code to do the animations myself. Besides that, I have not created any application icons yet, and has only been tested on Windows, on a single machine :P No idea how well it runs on the Mac. UPDATE: After fixing the mime type for AIR files, it now downloads on Safari on my Mac and runs correctly. On top of that, the animated GIFs run properly on Mac OS X!

If you run this, be warned that it eats a lot of CPU time, which is not a surprise; after all, it’s a full-screen transparent window!

View screenshot

I’m pretty excited about the possibilities of JavaScript/HTML AIR apps that leverage the Flex libraries in JavaScript. Plus I think it might be a great way to learn the new Flex/Flash/AS3 APIs without having to learn MXML at the same time (especially since I don’t have Flash CS3 yet).

If you have the AIR runtime installed (available here), then give this a try.

Download monster attack!

I’m here at the Toronto stop of the Adobe AIR Tour. So far it’s been pretty keen with cool demos, including stuff like applying Flash filters (e.g. blur, bevel, etc) to HTML elements. Nice.

I still haven’t done anything in Flex or AS3 yet, but being able to use HTML/CSS/JavaScript with full access to AS3 libraries seems pretty powerful, with a much lower learning curve than jumping straight into full Flex.

Right now Akamai just announced the release of an AS3 Media Player Framework…

Oh yeah, I’m not liveblogging :P

I’m experiencing a strange problem: when running an Adobe AIR app, the Flash debug player trace() log stops updating!

The details: I’ve followed the steps in this article so that I can read the output of trace() while running Flash movies in the browser. I use cygwin and the tail command to view the log updating in real time (I’m running Windows XP SP2 Home).

Now, I’ve noticed that whenever a new instance of the Flash player loads, it clears the flashlog.txt file. The tail command reports this as “tail: flashlog.txt: file truncated“. This happens when, say, I reload a Flash movie in IE and then in Firefox. But in both cases, logging of trace() continues after the file is cleared.

However, whenever I launch an AIR app (for example, the excellent tweetr or kuler apps), not only does the log file truncate (as I would expect), but the flashlog.txt file stops updating, no matter what trace() commands execute in my browser movies. The file stays at zero length for as long as the AIR app is running. When I quit the AIR app, trace() commands resume logging to flashlog.txt.

It’s quite odd. Note that I am not the author of these (or any) AIR apps, so I do not know if those apps are using trace() at all. Perhaps it’s just a case of AIR locking flashlog.txt and not letting go until the app(s) are closed?

The upshot is that I have to close any AIR apps before following any trace() logs. A small inconvenience, but it took me a while to figure out :P