Archive for February, 2008

An Even Better Install Badge for AIR

Grant Skinner of has developed a new AIR install badge for us. This badge has a host of capabilities not available in the sample badge included in the SDK—plus it looks cooler. A description and download link are posted on the AIR wiki.

AIR 1.0 is Done; Now Redistribute It

Over the course of our beta releases I’ve fielded many, many questions about whether or not it would be possible to redistribute AIR and, if so, how that would work. We’ve promised this would be possible, but haven’t allowed it with the beta releases. Now that 1.0 has arrived, I’m pleased to be able to deliver on this promise.

If you’re interested in taking advantage of this, instructions are now posted. You’ll be asked to accept a distribution agreement and, upon approval, will receive the necessary files and instructions for redistribution.

A couple of quick highlights:

  • You cannot redistribute the runtime from your own web site. For web-based install, please use the browser API and our badged install capability.
  • Writing your own bootstrapper is not necessary. If you want to use the standard AIR installation UI, you can use the provided installer as-is.


Support for AIR Beta Applications After 1.0 Ships

If you’ve released an application based on one of the AIR beta releases, here are a few things to keep in mind when making the transition to 1.0.

The Adobe AIR 1.0 release will install side-by-side with any beta releases already on the target machine. Applications which are bound to the beta releases will continue to run on those releases until the beta releases themselves expire. That’s June 1, 2008 for Beta 2 and November 1, 2008 for Beta 3.

Users with either (or both) beta release installed will be automatically updated to 1.0 the first time they encounter an application bound to 1.0. This is true regardless of whether it’s a new installation or an update. I described this in more detail in this earlier post on the auto-update mechanism.

If your application is auto-updating itself, keep in mind that you must maintain its identity between releases.

For users who first install 1.0 and then encounter an application bound to one of the beta releases AIR will not automatically install the beta release. Instead, the user will see a polite message informing them the application requires an unsupported version of AIR and they should check with the application’s publisher for an update.

Users in this situation who can’t obtain a copy of the application for 1.0–e.g., if the application hasn’t yet been updated–can manually install the beta 3 release. They can also manually install the beta 2 release but the beta 2 release can only be installed before beta 3 and 1.0. Attempting to install beta 2 after any later release will, unfortunately, trash your installation.

Why don’t we support automatically installing the betas after 1.0 is already installed? It hardly seemed like the best use of our resources.


AIR extends the existing Flash URLLoader, URLStream, and FileReference classes with a new event type, HTTP_RESPONSE_STATUS. If you’re writing an AIR application, you probably want to use this new event instead of HTTP_STATUS. Both events are instances of HTTPStatusEvent, but there are two major differences.

Additional Properties The HTTPStatusEvent has two new properties, responseHeaders and responseURL. These properties are available for HTTP_RESPONSE_STATUS but not HTTP_STATUS.

Earlier Dispatch The HTTP_STATUS event is dispatched after the request is completed and immediately before the COMPLETE event itself is sent. HTTP_RESPONSE_STATUS is dispatched as soon as the headers have been processed, before the data is available. If your request contains a lot of data or is made over a slow link, this can be significantly earlier.

Why did AIR introduce the new event type, instead of just re-using HTTP_STATUS? Compatibility: We didn’t want to break any existing code.

iCal Scalability

I switched to using iCal when my MacBook Pro became my primary email machine a while back. Continuing to run Outlook was too much trouble because it meant keeping a virtual machine running all the time. I tried Entourage, too, but iCal was simpler yet sufficient for my needs. True, iCal doesn’t integrate with our corporate calendaring solution–but in my job that apparently doesn’t matter much.

I found that iCal under 10.4 was a bit on the slow side. Performance enhancements were rumored for 10.5; another reason to look forward to the upgrade. Yet after the upgrade, iCal seemed as slow as ever–and sometimes worse. It’s easy to find complaints about iCal on the web, I couldn’t find many practical steps for speeding up. Time to do a little digging.

My events are divided among five calendars. With all five displayed, even changing the view from week to week was slow. I’d seen one reference on the web about a particular calendar giving someone trouble, so I tried mine one-by-one. Sure enough, just one calendar–let’s call it “A”–was responsible for the slowdown.

This matched up with a hunch of mine: there was a repeating event on calendar A that was basically un-editable in iCal. It didn’t cause a freeze or crash, but it hung iCal up for so long that I never had the patience to wait it out. Searching through the calendar event-by-event for a troublemaker could take a long time; starting with this troublemaker seemed like a good idea.

First, I exported the calendar to an .ical file which–thankfully–is a line-oriented text format. It was over four megabytes. Running “grep SUMMARY A.ical | wc -l”–SUMMARY is the field that contains the name of each event–showed it contained about twelve thousand events. I’m busy, but I’m not that busy.

Following up on my hunch, I searched manually for the repeating meeting. There were many, many instances–over eleven thousand. That’s a lot–so many that if I’d been to this meeting once a day, every day since I was born I would had my eleven thousandth meeting just a few years ago.

How did there get to be so many instances? That I don’t know. I suspect it’s related to the fact that this meeting occurs four days a week, so there’s probably no built-in recurrence rule for it. Worse, on one of those four days the meeting is in an alternate location, so that’s an additional exception to the recurrence. Even so, eleven thousand is clearly excessive.

Should iCal have been able to handle this event without slowing excessively? Hard to say. It’s not a large number of events in absolute terms; someone with ten years of experience and eight meetings a day would have more events in their calendar. Still, I suspect iCal scales more gracefully across a large number of different events and that the culprit here is the bizarrely large number of instances for the same (recurring) entry.

I removed all instances of the meeting by hand, deleted the original calendar, and imported the patched up version. Result? iCal is fast again.

Bonus question: Given what little I’ve said about our development process, what meeting do I attend four times a week?

Tools: Procmon

Back to developer tools.

In the platform-specific category, Procmon is my favorite on Windows. It captures registry, file system, and process events for any process. You can use it to debug your own programs and just about anyone else’s, too. It’s originally from Sysinternals, now provided by Microsoft directly.

For example, I once used it to debug some custom build steps in Visual Studio that weren’t behaving. Using Procmon, I was able to determine which files Visual Studio was checking timestamps on. It turned out an incorrectly entered output list was causing Visual Studio to look for files that didn’t exist and causing the step to run every time. Sure, maybe I’d have seen that if I stared at the output list long enough. But it was easy to spot in Procmon.

A few features I’ve found most useful:

Filtering by process name. You can filter events in about a zillion ways, but the most useful is to exclude based on process name. Find an event from a process you don’t care about, right-click, and select Exclude. Procmon remembers these settings between invocations, so it’s easy to reduce clutter by excluding Explorer.exe, etc.

Filtering by event type. In the toolbar you’ll find three buttons to show/hide file events, registry events, and process events. Again, eliminates a lot of clutter if you know which type of event you’re looking for.

Saving log files. You can save your captured event logs. I encourage our QE team to use this feature and attach the log files to bug reports. I can open the logs back up in Procmon and get a good idea of what happened.

You’ll also be surprised at all the stuff that Procmon captures going on under the covers. For example, you can see all of the work your application does before it starts executing your code. Sometimes I’m amazed applications ever finish starting!