Adobe onAIR Tour

To the future of applications

So yesterday I attended the Adobe onAIR tour at The Brewery in London’s east-end. And what a pleasant surprise it was as well. After being a little disappointed with the Colin Moock session a few weeks ago I wasn’t sure what to expect but the AIR team definitely turned up to impress.

Daniel Dura and Kevin Hoyt both made really interesting presentations about the flexibility of the AIR development environment and underlying interface. Particularly ion regards to integrating HTML and Javascript.

Dion Alamer from Ajaxian.com made a a great talk about Google gears and the 3rd party technologies you’ll be able to utilize within AIR. Pointing out the fact that this technology embraces the existing, rather than developers having to recreate the wheel.

Lee Brimelow finished off the show with some great mini applications demoing some key features of the app and supplying us all with a much needed laugh at the end of a long day.

Looking at the technology it’s definetely got some serious legs. At the very least the opportunity for web developers to create native applications without having to worry about learning the formalities of standard application development is great. The main sell of AIR has to be around the integrated web/desktop features. At initial review, the ability to drag-and-drop web data from your browser is brilliant but the possibilities that this opens up is just unimaginable. In a digital world where Google is taking over with online applications and slowly trying to bring your desktop to the web. An application that brings the web into your desktop and vice-versa is not necessarily in competition, but quite simply the personification of Marshall McLuhans “Global Village”.

I for one can’t wait to get my teeth stuck into developing some AIR applications.

http://www.adobe.com/go/air http://onair.adobe.com/

A new IE PNG Fix

A new fix for IEs lack of inline PNG transparency support

At the moment it seems our design team just keeps churning out sites that need PNG’s all over the place. We always try to use GIF’s where possible, but when those partially transparent, gradient-based nightmare assets pop-up, a GIF just doesn’t cut the mustard.

Until recently we’d been using Twin Helix’s solution by Angus Turnbull which, in general, was a great (and the only really viable) fix for most projects. That was until we discovered a major memory issue when using this in combination with the Google Maps API. Researching the issue (using Kevin Langdon’s immensely useful ServiceCapture) revealed pages with more than a healthy amount of PNGs, the .htc approach sucked-up some serious memory. The cause was not the script itself, but a result of executing the call via behavior(). This not only executes the script in an arbitrary order, but makes additional HTTP requests for the .htc file on each applicable element!

On a page with potentially dozens of PNG’s, IE was making too many HTTP requests, running multiple parallel processes and falling on it’s ass (which admittedly it does do oh-so-well). Consequently we decided it was time to write our own fix, in the guise of a plug-in for the wonderful jQuery framework.

The plug-in is essentially based on the original Twin Helix fix but focusing on reducing processes, speeding-up the render time and ultimately killing all those unneeded HTTP requests. At it’s most basic, the fix can be applied to elements as such:

$("img").pngfix();

Of course you’ll need to implement jQuery along-side this plug-in, but that’s a pretty simple affair. For full technical documentation, please go to the PNG Fix project page.

Download the Javascript source file (jquery.pngfix.js 8kb)