If you’re not familiar with how OpenID works, here’s a quick summary.

1. User goes to an application (Usually a web-app)
2. User types in their OpenID URL to that app
3. They get forwarded to their OpenID page where they can either grant or deny access.
4. That page then forwards them back to the original web app with an authentication token set.

Obviously, it’s kind of hard to redirect back to a desktop application.  I was thinking up some wacky work-a-rounds for this but then it hit me.

In the AIR app I can just use the HTML component and point it towards the login form of the web services.  The user can then log in using either username/password or OpenID just like they do on the website.  Now, here’s the cool part…  The AIR HTML component shares a network stack with the AIR/Flex NetConnection object.  That means any session/cookies/whatever opened in the HTML component carry through to the remoting calls I want to make from Actionscript. So I can authenticate using a web form, but then consume BlazeDS/LiveCycleDS/AMFPHP/Red5 services using AMF over Netconnection.

I did up a quick proof of concept and it works on both Windows and OSX.  I was able to successfully call a remoting service that requires an authenticated session.  So this was actually a much easier problem to figure out than I had feared.

Now, I’ll just need to make the web page that loads after a successful login somehow indicate to the AIR app that the user is successfully logged in.  I’ll probably either use a tiny Flash component that signals over LocalConnection, or I’ll just make the AIR app watch for when the HTML component gets to a specific URL. I’m pretty sure I can get this to be a completely seamless experience for the user.

Oh, and as a bonus… the user can sign up for a new account instead of log into an existing one from "within the app" instead of going to an external website to do that.

We added a

var options:Object = canvas.prepareToPrint( canvas );

Before the print and a

canvas.finishPrint( options, canvas);

After the print, and it seems to have solved our problem even though the documentation says we shouldn’t ordinarily need to explicitly call those.

The XRayViewer has been broken for quite some time. I had originally done it with an AIR beta, and that has since stopped working. So there’s now a newly compiled version just waiting for you to grab.

What is the XRayViewer?

So you may be asking yourself What exactly is the XRayViewer?

All this little app does is host the XRay connector and let you load a local swf. Then it displays the swf with some simple controls to play/stop/advance/back. The big benefit is you can then use XRay (By John Grden + Others) to inspect the swf without changing any code around.

There’s three new (very minor) features in this version:

1. There’s a button to launch the XRay interface in your default browser.
2. The path to the loaded swf is displayed in the top toolbar. (You can copy & paste that into Xray so you don’t have to navigate as far into the hierarchy)
3. New logo / icons

Now Open Source!

The entire project is now licensed under the MIT license. If you install the application and then right click on it you can “View Source” to get the source code for it.

I’m going to call these “large” applications since they go a lot deeper than a simple toy or small experience site that most Flex apps seem to be.  Your definition of “large” may differ.  These are full blown desktop applications, not a web-app ported to the desktop or a simple desktop app to augment a web-app.  All three were planned on being desktop apps from the start.  It’s not a common target audience for AIR, but I believe in the platform for this use.

A description of the projects

First, a quick rundown of the apps.

AgileAgenda

This was my entry for the Adobe AIR Derby so the beginnings were a rapid no-holds barred get-something-out-the-door effort.  There was no good planning that went into this, and no framework used.  This is one of my solo projects.

It’s since gone through several major UI revisions, with some parts of the application completly changing how they work or look several times over.

It’s a project scheduling application focusing on allowing users to create a schedule by entering tasks, priorities, and durations while letting the software calculate start/end dates.  Besides that it’s got some nifty sharing functionality, a PDF export, and a few different ways to look at your data.  I’ve been selling it commercially for while and not doing too bad, take a look and let me know what you think.  I’m always interested in feedback.

AgileTracker

AgileAgenda was doing pretty good, and a time-tracking application to work with it seemed like the next logical step.  I had been looking around and found Parsley and was fairly impressed so I decided to give it a shot. This is also one of my solo projects.

The AgileTracker allows you to subscribe to a schedule in AgileAgenda to get your list of tasks.  Then you can use the built in timer, or manually enter time to keep track of how long you spend on various tasks.  Someday, it’ll have full read/write capabilities to AgileAgenda for a full round trip exchanging of data.

TimeLiner XE

This is probably where I learned the most.  I acted as the project lead on a 3-5 engineer team that grew or shrunk throughout the process depending on other needs.  It was developed in a commercial setting (at Tom Snyder Productions, my day-job, which I’ve been very fortunate to find)  We’ve got a formal art, engineering, and QA team over there.

TimeLiner XE is the 6th major revision of one of the best selling desktop applications my employer publishes.  Previous versions were written in C++ with a proprietary cross platform layer.  It was a big gamble betting on Flex/AIR instead of sticking with C++, but we’ve been pretty happy so far.  The built in WebKit HTML renderer made one of our features (a web based research mode) a “killer feature” and doing that in a cross platform way in C++ would have been a huge investment compared to what we accomplished in AIR fairly simply.

You can see a pre-recorded webcast seminar at the TimeLinerXE web page. http://www.tomsnyder.com/timelinerxe/
If you jump to about the 3 minute mark, that’s where they start actually showing off the software. 

Quick summary…

LoC numbers above are just to give an idea of the scope of the project and does not include code from libraries (either internally developed or open source).  There’s a similar coding style in all three, so it’s purely meant to give an idea of the relative size of the projects.  The AgileTracker is larger than listed, because it reused a bunch of code from AgileAgenda which isn’t reflected in those numbers.

Things we did right

QA / Bug Tracking

Tom Snyder has a first class QA team. Having them involved early in the project helped direct it to be a project that was easier to test, and of higher quality than might otherwise have been possible.  Having a dedicated and passionate QA team is the single best thing that can happen to any software project.  We’re using Bugzilla for tracking which works pretty well, but will be moving to HP’s Quality Center in the near future (which I hope works even better!)

On the AgileAgenda side of things, this wasn’t so great.  I’m looking to rectify that in the near future, but finding the right person (at the right price) is difficult.  Since it’s a simple 1-person project I’ve been using TaskPaper to keep track of my list of bugs, my list of future features, and my general todo list.  I’m currently looking for a good end-user bug reporting system, but haven’t found anything that really fits my needs yet.

Open Source!

All three applications use some very good open source projects.  Without these, the development would have taken a lot longer, and been a lot more labor intensive.  Two of the more important libraries were…

Object Handles (Open Source)

ObjectHandles is a library I wrote a while back that makes it easy to create interfaces that let the user drag and resize components around the screen.  It’s amazing how having a library like that can make you add that type of functionality into places where you may not have wanted to spend the time implementing without it.  Take a look at AgileAgenda’s Light Table.  The Light Table is one of the features I get the most positive feedback about.  It took an afternoon to implement with this libray.  Without it, it would likely have taken a week and would have never gone into the 1.0 version.  Almost the entire TimeLiner interface was build with this library.

AlivePDF (Open Source)

The printing in AgileAgenda is completly done with AlivePDF. This lets the usercreate a PDF to print, send to a colleague, post on a website, etc.   It’s amazing easy to use and creates high quality PDF’s.  (Yeah, AgileAgenda doesn’t deal with margins well right now, that’s my fault and not AlivePDF’s).  

Parsley (Open Source)

Parsley is great, unfortunately it was only used in the AgileTracker.  Using an IoC container for applications like these makes perfect sense, and the MVC infrastructure it provides makes it super easy to stick to the MVC model without being tempted to just have the UI muck around with your data.  The only frustrating thing I’ve found with it, is that it’s harder to debug a parsley based application when problems occur.

When you’re using Java/Spring on the server side, it’s also helpful to use a client side framework where you can think in the same way. 

Perforce

We use Perforce for the version control system for all the mentioned projects.  It rocks, hardcore.  Even for my single-developer projects I find myself more organized with less of chance for losing something important because of it.  Subversion, CVS, whatever other version control system you use is fine too, but just make sure to use one!

ANT

All three projects can be fully built through a single ANT command.  The release builds of all the projects are made in this way.  It doesn’t matter if a developer updates his build environment, or if your FlexBuilder license gets funky, you can always make a known-good build through a simple single command line. 

For AgileAgenda we actually end up making several builds (ready why), plus update the download page all automatically from the build script.  No more creating a release version from FlexBuilder, copying it to the web directory, using FTP to transfer it and editing a file to update the version on the website!

If you’re making release builds of your software from within Flex Builder, you really are missing out and wasting a lot of time.

CruiseControl (Continuos integration)

For TimeLiner we’re automatically running builds through CruiseControl after every single code checkin.  When you have between 3 and 5 developers, it’s very easy to submit code that builds for you but nobody else.  By using CruiseControl, whoever submits a change to perforce like that gets an email telling them within 10 minutes.  No more yelling “Who forgot to add SomeWeirdClass.as to version control?”

For a while we had it running our unit tests as well, but unfortunately we don’t anymore (see below).

We didn’t try to hire Flex developers

Well, we did try, and then gave up.  Flex Developers are hard to find.  Really hard.  Many people out there claiming to be a Flex Developer are really just coders and not software engineers.   Going into TimeLiner there was Me and one contractor that knew flex well.  Everyone else was either completely new to ActionScript or only had Flash experience.  But every single one of our developers was a good engineer.  Having smart people who can get things done (certainly not my original idea) was the best way to go, especially given the duration of the project.  Teaching an engineer flex is easy compared with teaching a flex coder to be a flex engineer.

I think a big part of the problem here (besides Flex being so new) is Adobe doesn’t really focus on the developer market all that much.  A lot of (non-flash/flex) developers out there still see Flash simply as a way to make annoying advertisements where you punch a monkey or watch a video of a kid setting himself on fire.  Adobe is really great to their developers, but I really wish they would go after those developers letting them know what most of us know, that Actionscript is a full featured application development language, and Flex provides a great set of components.  When do we get to see Kevin Lynch on stage shouting “DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS“?  Of course, I hope they never lose their designer focus, it’s what sets the platform apart.

Design / Artwork

Having a great design team on TimeLiner really made the project.  It looks amazing.  Unfortunately, I didn’t have the budget for that in AgileAgenda.  I ended up getting my design from three main sources.

1) An eager student in France was willing to do some of this for me.  Unfortunately as time went one his priorities changed and it was hard keeping that relationship going.  (You rock Olivier)

2) I bought a pack of icons from IconShock.  I don’t know how I lived without these.  Now, whenever I’m creating something new I can look through that library of images and pop on an icon that really spruces things up and maintains a consistent feel throughout the app.  Just imagine this, without any icons, booooring.

3) And lastly, I needed a logo.  For $150 I ran a contest on a logo design website and got my final design.  You can’t beat that price, and it’s better than anything I could have done myself.

It may not win any awards, but it looks pleasing enough and the process of creating it didn’t distract me too much from the development of the software.

Things we did wrong

Plan for modules

The biggest thing I learned is to plan for modules in large applications from the start.  At one point during the TimeLiner development we were approaching compile times of 2-3 minutes.  Making a 1-line change and then waiting for several minutes kills productivity.  We abstracted all of our styles, graphics, and sounds into modules and got that back down to a semi-reasonable compile time, but I think if we had properly planned for modules and broke the application up in a logical manner it would have been even better.

Printing (AlivePDF for screen grabs)

If you’ve been reading along, you might have noticed AlivePDF above and be suprised to see it listed here as well.  Well, it’s not a problem with the library, but a problem with how we chose to use it in TimeLiner.  We made the mistake of thinking we could take an on screen visual timeline, grab a screen scrape, and dump it into a PDF for all of the benefits mentioned above.  Turns out that the antialiasing of text looks horrible after you print one of these out.  It’s a problem with the difference in resolution from screen to print.  We wrote a lot of printing code targetted at AlivePDF and it turned out not to be high enough quality when we put those PDF’s on paper.  Luckily, at least 80% of that code was re-used to create a printing system using the normal Flash/Flex printing API.  So in TimeLiner, you can now use a file->export command to make a PDF using AlivePDF to get a PDF that looks great until you print it (and then it just looks “ok”) or you can use the File->Print command to get a great looking printout.  This lets people share it either in paper or digitally with decent results in both.

Using AlivePDF’s methods to add text does not have this type of problem.

Unit Tests

For a while we were running our unit tests as a part of the TimeLiner build, but AIR 1.0 broke our unit tests and we never found the time to go back and fix them.  I wish we had, because it would have prevented some bugs from going through the QA/Fix/Verify process and saved us some time.

Data Binding directly to the model

TimeLiner and AgileAgenda’s interface both used to bind directly to the data model.  That’s fine for smaller applications, but for things of this complexity they break down.  Try using AgileAgenda sometime, the interface feels sluggish.  That’s because I haven’t done anything about it over there yet.  But we did do something about it in TimeLiner. Instead of binding the user interface to the data model, we created intermediary “model adapters”.  These adapters act as delegates to the model and only pass on the events that cause binding updates when they’re active.  This makes it easy to “turn off” a big part of the UI in on central place.  It also makes it easy to present the model data in different formats so we can do things like summarize a table of data for a “totals” label right inside these.  Using these adapters, it’s easy to turn on or off access to the model to various parts of the UI without complicated logic in the UI iteself.  The work we did covered about half the binding that was in place and makes a noticeable difference.  Given more time, I’d convert the entire app over to data model adapters.

Cairngorm

Cairngorm is a great framework.  It’s a good implementation of the command pattern and does define a decent set of methodologies of doing things.  It suited TimeLiner well and hasn’t given us many problems.  It has certainly solved far more problems than it has caused.  The only reason I place it in the “things done wrong” category is I believe Parsley to be superior, I wish we had used it for all three projects.  Parsley solved all the problems that Cairngorm solved for us, but it also managed to solve a few more.

Also, Cairngorm needs an easier name to say and spell

Not using AIR distribution

For business reasons, we’re not using the AIR distribution model for TimeLiner.  It’s a shame that we have to ship a physical CD to our customers since keeping a .air file on a website somewhere is so much more cost effective. Making an installer, pressing CD’s, printing a user’s guide, and shipping all of that is just a pain and keeps the software away from the end user for an extra few weeks after the end of development.  Plus, it’s a whole lot harder to get program udpates out there.  (AgileAgenda does not suffer from this problem)

Problems with the tools

Disclaimer… I like Flex Builder.  It works well and gets the job done.  With Thermo focusing on the designer crowd and Flex Builder reportedly re-focusing on the developer, I think most of these problems will be worked out in future versions.

Eclipse/Flex Builder doesn’t do the “Run in background” thing very well and will constantly re-pop that compile progress dialog up.   Before going the module route, this absolutely killed TimeLiner.  Afterwards, it was still a constant annoyance.  Even with modules we might be interrupted, at seemingly random times, by the “Building workspace” dialog for 5-25 seconds.  If the little “stop” button would always work instantly, this wouldn’t be a problem.  But it doesn’t.  Turning off automatic compiling can help, but then you don’t get all the functionality of FlexBuilder.  When FDT gets decent MXML supprt, I’m going to seriously look into it.  In the past I’ve used it on AS2 projects and problems like this simply didn’t happen over there.

Coming from an Eclipse/JDT and an Eclipse/FDT world, FlexBuilder is missing a lot of functionality.  Snippets, decent code generation, and refactoring like “extract method” or “create delegate” would be very helpful.  From what I hear, with Thermo coming out, the FlexBuilder team will be focusing on developer-centric ideas like this which will be great.  If Adobe just made it easier for people to extend FlexBuilder, I’m sure those things would get written by the developer community.

The Flex compiler will sometimes, seemingly randomly, start throwing unknown variable errors in code completely unrelated to what we’re working on.  Doing a clean build doesn’t fix it.  Going in, editing the file where the “error” is found by deleting and re typing a character, and letting it rebuild seems to be the only solution.  I think this has to do with the Flex compile cache, but I haven’t had time to investigate it further.  It happens at least once a day to me.  

Much of the development was done with Beta versions of AIR and Flex Builder.  I underestimated the impact that would have on development.  Beta versions are buggy, and they do suck time out of your schedule.  Little things like installing new versions every few weeks, or crashing more often add up.  But I do think the benefit of using those vs. using the older stuff was worth it this time around.  Unfortunately, I don’t know if that would always be the case, and I don’t know how to judge that impact before a project starts.  I guess I’ll just tend to opt for released versions unless the project requires something in a beta version.

The future

I’ll be moving AgileAgenda over to Parsley bit by bit. Thinking about that framework, it should be pretty easy to move smaller pieces over that I might be working on without disrupting the bigger picture.  AgileAgenda will most likely be in light continuous development for years to come.

The AgileTracker will continue on as-is.  I’m very happy with how it works and flushing out the rest of the features and functionality is “all” that’s left

TimeLiner will stay a Cairngorm application.  Due to the way commercial educational software companies work it will probably go through cycles of being untouched for months, and then heavy development for a new release.   Those months of quiet and then bursts of activity will give us further insight on how easy it is to maintain a Cairngorm app.  Someday, I hope we do a web version of the software.

Conclusion

Overall, I believe Flex/AIR is the way to go for cross platform applications like these. I’ve done both Java and C++/QT cross platform apps, and neither of those was as easy to get working consistently accross platforms as AIR and Flex. 

So, if I were to start a new project today I’d probably go with the Parsley MVC + IoC approach.  I found it to be easy to work in and it solved more of my problems than the Cairngorm approach. 

If I could find experienced Flex engineers, I’d make my team out of them, but it wouldn’t be a must-have since I’m convinced any smart software engineer can pick this stuff up. 

I’ll be using the data model adapter “pattern” instead of direct binding for now on for anything except the most trivial of applications.  I’ll write a full blog post really explaining this sometime.

Modules will be planned from the start.  I think a lot more in all three applications could have been split into modules without any additional labor if we had just kept it in our minds from the beginning.

Disclaimer – I’m an employee of Tom Snyder Productions.  Anything said in this blog post should be considered solely my own opinion, and may not be representative of my employer.

One of the best things about AIR is it’s application distribution model.  It’s just so darned easy for people to install apps.  One of the worst things about Linux is application distribution.  There’s just too many package formats and different ways to install.  I really hope AIR can bring a single, simple, installation method for AIR apps to all of the popular distributions.  Something that my wife could sit down at a Linux computer and do.

We’ve all seen the AIR installation badges that let you install an AIR application from a website. But the API exposed to do that lets you do more than just a simple badge. I’ve been working on a web-based service for AgileAgenda. One of the components of that is to manage the list of files you’ve saved to the service and be able to open those in the desktop AIR application. So right from within the online Flex based app it sure would be nice to detect if the application is installed, give the user the option to install, and then launch it for them and automatically open the desired file. Something like this…

To implement that we need to:

1. Detect whether or not the application is installed.
2. Display the version number if it is. (Disable the “Open schedule in…” button if it’s not)
3. When clicking on the “Open” link, launch the application with a few parameters so it know what to open.
4. When clicking on the “Install” link, install the application and pass a few parameters so it know what to open when it launches directly after the install.

Doing things like that falls outside of the normal AS3 web development API. But Adobe provides a swf that you can load at runtime and them make calls to. You can read all about that over here: http://livedocs.adobe.com/air/1/devappshtml/help.html?content=distributing_apps_3.html.

But there’s an annoying thing with that. You need to load up that remote swf and then access it like a dynamic object. No compiler-time type checking. Not the standard event mechanism. And no code-completion from within Flex Builder.

Luckily for you, I went through and made a wrapper class that you can download from here:

http://rogue-development.com/uploads/AirSwfAPI.zip

This will handle the loading of the remote swf, dispatching events when it loads (or fails to load) and then wraps the API for the entire process. There’s nothing revolutionary in there, it’s mostly takendirectly from that livedocs page above.

So now that you have that handy-dandy wrapper class, lets look at how to actually get something done.

Setting up your AIR application to work with your website (Important)

First thing, go into your AIR application’s -app.xml file and make sure allowBrowserInvocation is set to true. By default it’s set to false.

<allowBrowserInvocation>true</allowBrowserInvocation>

If you don’t do this, you won’t even be able to query version information on your application. But, be careful. By doing this you’re letting any website launch your AIR application from a web page. You need to be careful in how much your app trusts command line arguments passed to it. For instance, you should never pass a file to delete on the command line.

Now that you’ve set allowBrowserInvocation to true, create a new .air file and post that to your website somewhere.

Using the wrapper class to interact with your application

Either open an existing Flex or Actionscript project in FlexBuilder and put the source to the AIRBrowserRuntime.as somewhere that the compiler will find it. Somewhere in your main application, create an AIRBrowserRuntime object, set some event listeners, and call the load() method to load the air.swf file from Adobe’s servers.

var api:AIRBrowserRuntime;

…

api = new AIRBrowserRuntime();

api.addEventListener(AIRBrowserRuntimeEvent.READY, onReady );

// Optional: api.addEventListener(IOErrorEvent.IO_ERROR, onAirFail );

api.load();

Once the READY event is dispatched, you can start calling methods to query application versions, install apps, or launch applications.

Checking if AIR is installed

To see if the AIR runtime is installed, call the getStatus() method. It will return one of three values.

available – The AIR runtime can be installed on this computer but currently it is not installed

unavailable – The AIR runtime cannot be installed on this computer.

installed – The AIR runtime is installed on this computer.

Example:

switch( api.getStatus() )

{

case “available”: trace(“AIR is available, but not installed.”); break;

case “unavailable”: trace(“AIR is not available for this computer.”); break;

case “installed”: trace(“AIR is already installed on this computer.”); break;

}

Checking the version of an installed application

The getApplicationVersion method will check to see if a given application is installed and give you the version if it is. This method operates asynchronously so you have to create an event listener before you call it. If you look at the method signature…

public function getApplicationVersion(applicationID:String, publisherID:String) : void

You’ll see that it takes an applicationID and a publisherID. The applicationID is just value of the <id> tag of your application descriptor (the -app.xml file). It’ll probably be something like this, but you need to make sure to make each application unique:

<id>com.agileagenda.AgileTracker</id>

The publisherID is a little trickier to find. That doesn’t get assigned until you actually sign your .AIR file with your code-signing key. I know of 2 ways of finding it, but there’s probably an easier way (please leave a comment if you know how).

Warning about Publisher ID:  If you change the key your sign your app with, the publisher ID will change.

Option 1: Get it at runtime.

In your application’s main MXML throw up an Alert message with the publisher ID. Then build a .air, install the .air and run it. Copy & Paste the result.  Example:

<?xml version=”1.0″ encoding=”utf-8″?>

<mx:WindowedApplication xmlns:mx=”http://www.adobe.com/2006/mxml”

    creationComplete=”init()” >

  <mx:Script>

  <![CDATA[

    protected function init() : void 

    {

      Alert.show( nativeApplication.publisherID);

    }

  ]]>

  </mx:Script>

</mx:WindowedApplication>

Which results in something resembling:

It’s hard to see in that picture, but the publisher ID is: F49A4D8DF78A1FEE7A3BE440DC11BAB18D922274.1 as it wraps to two lines.

Option 2: Get it after install

This is probably a bit easier, but I’m not 100% sure where this directory goes on a windows box.

On OSX (maybe on Windows, I’m not sure exactly where) the application storage directory that gets created for your application has the publisher ID appended to it. So if you look in your user directory -> Library -> Preferences, you should see a directory that starts with your application ID and ends with your publisher ID.

As you can see there, we get the same publisher ID value as Option #1.

On to checking installed version

Now that you have your application ID and your publisher ID you can make a call from your web application to the API to request the installed version of your AIR application.  This operates asynchronously so you’ll need an event listener for the result.

Example:

api.addEventListener(AIRBrowserRuntimeEvent.APP_VERSION_RESULT, onTrackerVersionResult );

api.getApplicationVersion( “com.agileagenda.AgileTracker”, “F49A4D8DF78A1FEE7A3BE440DC11BAB18D922274.1″ );

…

protected function onTrackerVersionResult(event:AIRBrowserRuntimeEvent) : void

{

trace(“Tracker version installed: “ + event.detectedVersion );

}

The event.detectedVersion that comes back will be the value in your application descriptor version tag.  Mine looks like this:

<version>v1</version>

So the trace output looks like this:

Tracker version installed: v1

Launching an installed AIR application

Assuming you followed along in the previous section, you have an Application ID and a Publisher ID ready. To launch an AIR app from a web app you just call

api.launchApplication( “com.agileagenda.AgileTracker”, “F49A4D8DF78A1FEE7A3BE440DC11BAB18D922274.1″ );

launchApplication has a third, optional, parameter called arguments and is typed as an array. Anything you pass into that will be passed along to the application in an INVOKE event. This way you can pass information from the web application to the AIR application. Example:

api.launchApplication( “com.agileagenda.AgileTracker”, “F49A4D8DF78A1FEE7A3BE440DC11BAB18D922274.1″, ["Argument1","Argument2" ] );

Be careful, the arguments are very restrictive in what characters can be passed. Things like dashes, percent signs, underscores, all cause a runtime exception on the web application. You’re probably safest only using alphanumeric characters. I haven’t found a comprehensive list of what characters are or are not valid. If someone has that, please leave a comment below.  This was done for security reasons.

Installing an AIR application

To install an AIR application, all you need to do is call the installApplication with the absolute URL to the .air file you want to install. Example:

api.installApplication(“http://www.agileagenda.com/download/AgileTracker.air”);

This will take care of installing the AIR runtime, installing the application, and launching it for the first time. installApplication has two more optional parameters. The AIR runtime that the application requires, and arguments that can be passed to the application for it’s first run. Example:

api.installApplication(“http://www.agileagenda.com/download/AgileTracker.air”,”1.0″,["Arg1","Arg2"]);

That’s all there is to it.

So that’s it, pretty simple, huh? You might also want to look into using a LocalConnection to do realtime communication between your web-app and your air-app once the air-app has been launched. Recap of the links:

Wrapper Class:

http://rogue-development.com/uploads/AirSwfAPI.zip

Adobe’s Documentation:

http://livedocs.adobe.com/air/1/devappshtml/help.html?content=distributing_apps_3.html

My Blog (where any updates to the wrapper class will be posted)

http://www.rogue-development.com/blog/

The actual air.swf that does all the heavy lifting (This URL is wrong in some of the docs!)

http://airdownload.adobe.com/air/browserapi/air.swf

This means people with a Flash Player less than 9.0.115 should be able to first upgrade their flash player, and then use the easy badge installation method for AIR + the application. I gave it a try on Firefox + Safari on OSX and IE + Firefox on WinXP, all of them with a 9.0.47 flash player and it all seemed to work well. The code also displays a message suggesting people install Flash player or install the AIR application manually if they don’t have any version of Flash.

I’ve put together a small archive of the necessary files to make this work. It contains files from the swfobject guys released under the MIT license, and you can consider anything I wrote to make this work also under that license (which allows you to pretty much use it any way you like).

There’s a new version of AgileAgenda now available on the website.

It’s been updated for AIR Beta 3, and includes a lot of bug fixes and minor enhancements, with a couple large feature improvements thrown in for good measure. You can read the list on the project blog.

The biggest change for me is file open/save dialogs work on OSX Leopard! Yay.

This is from the AIR release notes:

Setting the mime type in your Web Server for AIR applications

In order for client browsers to recognize an AIR application when being downloaded, the Web Server hosting the AIR applications needs to map the following MIME Content Type “application/vnd.adobe.air-application-installer-package+zip” to the Apollo extension “.air”. For example, for an Apache Web Server you will add to the AddType section: AddType application/vnd.adobe.air-application-installer-package+zip .air

So for Apache, just add this to your config:

AddType application/vnd.adobe.air-application-installer-package+zip .air

I had some weird problems with the badge-installer not working on a couple OSX machines, I wonder if this will fix it.

1) Open up the Flash IDE and explore it
2) Add an instance of it to my project, and then use XRay to explore it.

Now, I have a third option. I can open it up in the XRayViewer AIR application I just put together and then use XRay to look through it.

XRayViewer.air

All this little app does is host the XRay connector and let you load a local swf (File->Open). Then it displays the swf with some simple controls to play/stop/advance/back.

But the real power is you can go off to the XRay interface and look through that loaded swf!

I’ve also been working with a young designer from France on some of the visual aspects of the software. He’s been making icons for a while now and agreed to let me use some of them in my project. On top of that he did a mockup on a screen that took my thoughts on design to a completely new direction. He’s working on a project of his own as well, I’ll make sure to post about it when it’s ready. Here’s an example of what the software might look like come release time:

Even that look still has a couple rounds of revisions left, but it’s getting closer.

We’re still accepting beta applications for anyone interested in trying this stuff out in the first round of beta.