- intro slide -
Good morning everyone!
Before I start, I just wanted to say that I think its awesome that you guys are here, and on a Saturday no less - that makes you the truly hard core, and I salute you.
My name is Steve Chipman. I'm a software engineer at AOL - I've been there for all 4 different CEOs, and have worked on everything from AOL.com to our registration backends. Currently I am working on our Lifestream product, and before that I was working on AIM Express which is the Flash version of AOL's IM client, and is how I not only learned, but learned to love AS3.
Today I wanted to talk a little about the Lifestream desktop app, its architecture and use it as an example of how you can write desktop applications with stuff you already know - namely, HTML, Javascript and CSS with as little (or as much) AS3/Flex that you feel your application requires.
- slide 1 -
AIR, for those who may be unfamiliar with it is Adbobe's Integrated Runtime and their answer to getting Flash on the desktop. It launched in 2007 under the name Apollo, and only very recently did Adobe release the 2.0 version of the runtime which introduces interesting things like native installers and has a bunch of performance improvements.
It runs on Windows, OS X and Linux, is extremly easy to get up and running, compared to say, xcode which I found cryptic and vaguely horrifying, and the IDE is Eclipse which I'll wager a bunch of you are already familiar with.
-- slide 2 -
Some of the cooler stuff about AIR is that aside from being really easy to get running with, are its slick APIs for desktop integration. You can do everything from make the dock icon of your application bounce up and down to reach out to native processes to do cool things that might not necessarily be available directly with just Flex and AS3. An example of that would be if you application has to do a bunch of super complicated calculations - you'd want to do that in something like C++. This sort of thing allows you to write that component and make it available to your AIR app as an externally referenced library, which is pretty sweet. OR, even simpler - you could call the command line utility grep.
-- slide 3 --
Of course, the most interesting thing you can do, and what I wanted to talk about today, is that you can write almost the entire application in HTML, Javascript and CSS without having to deal a whole heck of a lot with AS3 or Flex unless you really want to. So, knowing what you already know about Javascript you can write desktop applications.
-- slide 4 --
And literally this is all you have to do. Open up the IDE, start a new Flex project, check the radio button for AIR, add this line of code and go. You now, have at its simplest form, a desktop application running that is an html page out on the web somewhere.
-- slide 5 --
This is what you'll end up with - this is Flex if you aren't fmiliar with it. A bunch of code that the IDE will generate for you, our mx:HTML object and a script tag that lets us write AS3 code if our application needs that. Thats it. I don't imagine it can get a whole lot easier than that.
-- slide 6 --
So - this is the Lifestream desktop client. For those of you unfamiliar with it, its a social network aggregator. We pull in and post to facebook, twitter, myspace, foursquare, and a bunch of others. What you see here is all HTML. The entire application is powered by Javascript.
So why is that important? Lifestream has existed for a while as part of the AIM network, and there is a Lifestream tab in all of the major AIM clients - windows, mac and AIM Express. Around the end of 2009 we started thinking that it would be cool if we had a stand-alone experience of Lifestream for people that might not neccesarily be using our AIM clients. So, when everyone got back from the holidays we started working on that in earnest based on a prototype that a guy on my team had worked on while he was bored over the winter break.
Then, someone got the idea that it would be really awesome if we were to launch our clients at SXSW. If you've not been to SXSW, its an annual geek event that happens in Austin Texas in March. Lots of drinkgin, carousing, mingling and occassionally a panel worth attending. So - we needed to write a desktop application, have it QA's and ready to go live with a meaningless "beta" emblem stuck on the logo in around two months. We kicked a lot of ideas around, but ultimately decided that it would be foolish of us to do this with anything other than HTML and Javascript.
We could probably do it in Objective C, but then where would our windows app be? And Linux users would, as per the norm, be left out utterly. So AIR was very attractive in that respect. We also knew that since we had a REALLY tight timeline, we would need to be able to fix any odd bugs that QA might happen to miss - what better way to do that than to have our applications code base remotely hosted? This is one of the key awesome features about this means of serving your app - we host everything on our CDN. When we do an update, we can do so without the user knowing anything about it. Find a bug? No problem, fix it, test it, update it on the CDN, flush the proxy and the next time a user starts the app, they have the latest and greatest without having to have agreed to an update dialog or lift a finger. Thats alone is worth the price of admission.
-- slide 7 --
And not to be outdone by Adobe, this is a photo of the Lifestream bus that cruised around Austin this year. I wasnt able to make it this year, but the other two guys on my team went and they said it was quite a party. And apparently, those decals on the side of the bus are suprisingly flammable.
-- slide 8 --
So this shows the same application running in Safari. I show you this not only to say "See? it really is html", but also to illustrate that you can build your application in an environment you are already comfortable with, with the tools you are accustomed to using. I use Safari as my development platform for this particular application because one, AIR ships with webkit which is awesome, since you only have to deal with a single rendering engine. If this were a standard web app, we'd have increased QA time by an order of magnitude just making sure that the thing worked and looked right in the myriad of browsers on AOLs support matrix. I feel like the developement tools for Safari have matured beyond what Firebug can offer - what kind of debugging tool causes bugs, anyway? So, build your app however you are comfortable building it, with the tools you want to use (I use textwrangler to write markup and javascript) and then run it later via Flash Builder to ensure that everything works the way you want it to.
-- slide 9 --
So now here we are actually integrating our HTML app with Flash components. The window hovering above the status input area there is Flash - its a nativeWindow component, with its opacity tuned and its chromed disabled. When the user clicks that "add photos" button, its actually making a call into the AIR application itself which then pops open a file picker dialog. We import the image, and render it there.
-- slide 10 --
So how does that happpen? How does javascript talk to AIR? So we have a public object that we've cleverly named "airBridge" that, if you are familiar with object literals in Javascript - its the same thing in AS3. Every property on the airBridge object points to a public function in the AS3 source. So anything that we want javascript to be able to do, like bounce the dock icon when we get a new status update, or upload a batch of photos, or remember the timestamp on the last viewed notification, we set those up on airBridge. If you;ll recall, we gave our mx:HTML Flex component an id of "html". That is its identifier in the AS3 code. the HTML componenet has a domWindow property which allows you access to the Document Object Model of the HTML page it is hosting.
So then you see here where we are calling back into AIR via the airBridge to make a call to the uploadPhotos function.
-- slide 11 --
So obviously if you can call in to AIR, you should also be able to call out to javascript from AIR. And not only can you call functions that exist in your HTML document, or access native window methods, you can access HTML objects and manipulate them from within the AIR application.
Now - interesting side note here. There are no domain of origin issues like you'd have on the web when you load an url into one of these components. We do facebook authentication, and there was a bug in one of the pages we serve from facebook. Rather than wait for them to fix it for us, I just manipulated the DOM of the page to fix it myself. So thats a plus.
-- slide 12 --
The installer ... if you've ever installed an AIR app, you are familiar with this dialog with the black background and the spooky text letting you know in no uncertain terms that installing this application could mean the end of the world as you know it. Despite the fact that its a signed application with a verified publisher. I think Adobe went to a lot of trouble to make people aware that they were installing an AIR app - which is, of course, nothing the user ever needs to know.
These complaints are specifically against the AIR 1.0 installer. The new 2.0 runtime allows you to release native installers - you'll get a .dmg for mac, a setup.exe for windows and an .rpm for Linux. But there's a catch! To do this, you need to build the native installer for each OS on that particular OS. You can't build a windows installer on a mac. I don't know why this is ... but its annoying.
Another somewhat lame thing is that the version of webkit that ships with AIR is a slightly out of date. This is much improved with AIR 2, but it still doesn't support drop shadows. Though it DOES support transformations and things like that, which is pretty cool.
And of course, like any Adobe product, Flash Builder has a steep price tag. There is a 90 day trial version so you don't have to commit to anything straight off the bat, but thats certainly something to keep in mind.
The memory footprint for its not too bad - when running the Lifestream app, and running the same HTML codebase in Safari they both take up about the same. The AIR app takes 72MB, and Safari takes around 80MB. This is with AIR 2 - AIR 1 had a more significant memory footprint.
-- slide 13 --
Now, beyond AIR - and why I feel like building applications this way. What you see here is the same codebase running on an iphone, as well as a chrome extension. At some point in the near future, when you visit lifestream.aol.com on an iphone or android device (which currently does not have an experience optimized for mobile devices) this is what you'll be served.
This is fantastic portability. The codebases between these implimentations are identical. We just built in a "mode" switch that tells the codebase to pull in a mode.css file. So if I pass "mode=mobile", then it dynamically pulls in a mobile.js and a mobile.css. Those files do things like over-ride methods, redefine parameters, etc. For example, over 3G it can take a little longer than you'd want to pull in and render 100 status updates, which is the default number that we pull in. So, mobile.js redefines the paramters that sets that value to 25.
The css file moves things around and changes the way things are rendered. You'll notice that when we are running in AIR or Chrome, the status update area scrolls while the header remains in a fixed position. This is not possible on the iphone given the way its viewport works, so mobile.css just changes the overflow properties of those elements so that the entire page scrolls.