December 2010

Well, over the past several weeks I've made an unanticipated veer into AIR for Android, really fun stuff. Here's some background...

AIR for Android

Several weeks back a friend called with a software problem: his client has a fleet of about 50 trucks, and each driver carries a camera so they can take pictures of the equipment they're working on. Drivers upload these images to the company server, but the upload process is a hassle and it's slow: after taking pictures the driver has to return to the truck (where a laptop is bolted to the dashboard) and then "manually" transfer the images to the laptop (via USB or card reader) and then use my friend's web-based UI (.NET) to upload the images. Since these laptops use a mobile 3G connection performance isn't great when uploading multi-MB images. This was the source of my friend's problem: to speed things up he wanted to compress the images before upload but he was having problems running client-side compression because of sandbox constraints (remember, he's using .NET, not Flex).

When I heard all of this I had two questions:

• Currently each driver is issued a camera, but by any chance are they also issued a camera phone?
• If they do have camera phones, are they Androids?

It was the answers to these questions — yes to both — that triggered my veer into AIR for Android development. Why? Because thanks to some demos at the NYC Flex User's Group I'd seen the prerelease of AIR for Android. And I knew that an Android app could liberate these drivers from their cameras and streamline the current process. That is, drivers could use their Android phones to take the pictures and then an AIR for Android app could upload the image to the company server directly from the phone. This app could also address my friend's original problem, resizing/compressing the image before uploading.

As of this writing the first iteration of this simple little app is done. It does the following:

• uses the new AIR for Android (so, AIR sdk 2.5) classes CameraUI and CameraRoll to let the driver capture or select an image
• collects metadata on the image from the driver (including using swipe-enabled selection lists)
• runs the image through a Matrix to rescale it and uses an async derivitive of the Alchemy JPEG encoder to compress/encode it
• sends the metadata to the server (not just the driver's input but also GPS info obtained through the Android-specific Geolocation class)
• sends the image to my development server using the AIR-specific File class (much nicer than FileReference because you don't have the sandbox restrictions, you can initiate the upload() without user interaction).

Below are some screencaps: first, the main view at startup (i.e., before the user snaps/selects an image) is shown in both phone orientations; then the metadata collection view in vertical mode; and then the view displayed while the image is optimized and then sent to the server. Simple UI, but all that's needed here.

There's more functionality — e.g., it honors the Menu and Back softkeys just as you expect with an Android app — but I'll save the details for a future post on AIR for Android development.

...and Hero and Burrito

In addition to the above, I'm also about to dive into Adobe's next generation mobile development environment, since I really shouldn't be developing a mobile app using classes from the Flex sdk 4.1 (Adobe recommends using AS-only projects for Android apps until Flex 4.5 is released). So, I'll be installing the prerelease versions of Flex 4.5 and Flash Builder 4.5 (code named Hero and Burrito, respectively) shortly. I'll post something on this experience when I get a chance.

UPDATE: February 2011

Well, the project is on hold until the final production release of Flex 4.5 ships. In the meantime I've created a Hero version of the app and also now have a new primer on using Hero (Flex 4.5).