Tag Archives: desktop

Repurposing PhoneGap Apps as Desktop Apps

I was inspired to write this post by several recent conversations.  I was in a debate about whether with the Flex/Flash platform you could easily repurpose content to the desktop using Adobe AIR (and vice-versa), but that you couldn’t easily do that with PhoneGap applications. (My stance was that yes, you could repurpose content.)

I wanted to make sure that people were aware that you can repurpose your content, and here’s an example of how.

A while back, I wrote a sample PhoneGap application that allows you to browse information from the 2010 US Census.  You can read more about this application and download the source code here. This application supports lots of platforms… iOS, Android, BlackBerry, and web (everything except IE because I was targetting WebKit browsers).

While this application is a mobile app wrapped in the PhoneGap container, I actually didn’t use any PhoneGap-specific libraries, so it was very easy to repurpose as a desktop application.   I created an AIR version of this application, which you can download at:

US Census Browser in OSX

You can build complete AIR applications using HTML and JavaScript, even with full access to AIR APIs (network, file access, etc.).   You can read more about building AIR apps with HTML and JavaScript at: http://help.adobe.com/en_US/air/build/WS5b3ccc516d4fbf351e63e3d118666ade46-7ecc.html

I had to use my Android 2.x branch of the US Census Browser code because the WebKit instance inside of AIR doesn’t support SVG.  I also changed the container scrolling to use normal CSS “overflow: auto” instead of using iScroll for touch-based scrolling. There were a few other one-off CSS changes to tweak the layout in the AIR web container, but otherwise the code is identical.

You just need to create an AIR application XML file and point it to your HTML content, and then package it using ADT.

Here’s my AIR application XML:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/air/application/3.1">
<name>US Census Browser</name>
<minSize>800 600</minSize>

Notice that the “content” node just points to my “index.html” file.

Here’s the command to package it:

[bash]adt -package -storetype pkcs12 -keystore sampleCert.pfx HelloWorld.air HelloWorld-app.xml *[/bash]

You can read more about this process in the Adobe AIR documentation.

If you were using PhoneGap APIs, you would have to migrate your code to take advantage of AIR APIs, but all other HTML/CSS/JS could be reused with minimal changes.

Even though I used AIR for this example, AIR isn’t the only game in town for HTML-based desktop applications…   There’s an open source project called MacGap, you can use HTA for Windows, and it’s not hard to write a HTML/Web View wrapper for any platform. It’s even been reported that you are going to be able to write apps for Windows 8 purely using HTML & JS, and you would be able to repurpose your code for this as well.

You can check out the AIR version of the US Census Browser at:


AIR 3.0 Captive Runtime

If you hadn’t heard yet, Beta 2 of AIR 3.0 and Flash Player 11 are now availabe on Adobe Labs. The AIR 3.0 beta release is sporting some great new features, including hardware accelerated video playback for mobile, iOS background audio, android licensing support, front-facing camera support, encrypted local storage for mobile, H.264 software encoding for desktop applications, and last, but not least, captive runtime support for desktop and Android applications.

If you are wondering what “captive runtime support” is, then I’ll try to explain… Currently all AIR applications that are deployed on the desktop and in Android require the 3rd-party Adobe AIR runtime. If you are familiar with the process for developing mobile AIR applications for Apple’s iOS devices, then you may already know that these applications don’t require the 3rd-party runtime; they are completely self-contained applications. These AIR applications for iOS already take advantage of the captive runtime. All necessary components of the AIR framework are bundled into a self-contained, compiled distributable application that has no dependence upon other frameworks.

With AIR 3.0, you will have the option to bundle the AIR framework into your applications to eliminate the 3rd-party dependency. However, one thing to keep in mind is that you can only export mac application packages on Macs and Windows EXEs on Windows. You can’t target native installers or bundled runtimes for cross-platform development. You can only have a single app that targets both platforms if you export a .AIR file (which requires the 3rd-party AIR runtime).

Instructions for using the captive runtime:
First, make sure that you extract the AIR runtime SDK from the archive. Instructions for extracting the AIR SDK are located at: http://kb2.adobe.com/cps/495/cpsid_49532.html

Next, add a compiler argument for swf-version=13.

Then use the ADT command line utility to build and package your application. If you run the ADT tool on the command line without passing any arguments, it will show you all of the packaging options.

For the Android captive runtime, you just need to select the target “apk-captive-runtime“, as identified by:
[bash]adt -package -target ( apk | apk-debug | apk-emulator | apk-captive-runtime ) ( CONNECT_OPTIONS? | -listen <port>? ) ( -airDownloadURL <url> )? SIGNING_OPTIONS <output-package> ( <app-desc> PLATFORM-SDK-OPTION? FILE-OPTIONS | <input-package> PLATFORM-SDK-OPTION? )[/bash]

For the desktop captive runtime, you need to select the target “bundle“, as identified by:
[bash]adt -package SIGNING_OPTIONS? -target bundle SIGNING_OPTIONS? <output-package> ( <app-desc> FILE-OPTIONS | <input-package> )[/bash]

Exporting AIR Mobile Apps as Desktop Apps

A great question came out of the comments on my last post “Why Can’t I Run My App in the iOS Simulator” asking if it is possible to export the mobile simulator from Flash Builder to allow you to distribute builds for functional testing/validation.   The quick answer is yes (but you don’t really export the simulator).

Let me explain… When running or debugging a mobile application directly within Flash Builder’s environment, you really are running a local desktop application within the ADL executable (AIR Debug Launcher) that is part of the AIR SDK.  The size/layout of ADL in this case is locked to imitate the experience of a particular device/configuration.  The mobile application isn’t running in a device-specific simulator.

All Flex/AIR mobile applications can actually be exported as .AIR files that can run within the desktop runtime environment.  This enables you to easily repurpose an application from mobile to desktop.

Keep in mind, this does not mean there will be a 100% parity between desktop and mobile features, interaction, and performance.  Interaction paradigms, such mouse vs. touch, keyboard vs. hard-keys vs. soft-keys, form factor, as well as hardware (CPU/memory) may all have critical impacts in the overall experience.  Again, if you are targeting mobile devices, then it is imperative that you test your applications on real, physical devices to identify any kind of performance issues, bugs, or UX issues.

To export a mobile application for desktop usage as a .AIR file, just select the “Signed AIR package for installation on desktop” export option within the “Export Release Build” dialog.

Flash Builder Export AIR Options

The exported AIR file will use the standard AIR runtime, inclusive of cross-platform features and the AIR installer.  Note: I used a local dev certificate in this example, with just the default options.

AIR Installer

At runtime, it will look like any other AIR application.  You can configure the AIR app-xml descriptor files to customize it.

Runtime Mobile AIR Application on the Desktop