Introduction

In iOS to Android we explored some of the differences between iOS and Android devices from a programmer’s point of view. We will cover here in more detail the adjustments that were needed to port an app from iOS and Adobe AIR to Android.

The app in question was described in more detail in the article About WebKit. It helps people learn foreign language vocabulary, similar to digital flash cards running on mobile devices as well as on desktop computers.

We were able to port the app to Android in three weeks, from scratch. This includes downloading, installing, and learning to work with Eclipse, the Android SDK, and PhoneGap for Android. To rewrite the app in Java, probably would have taken three months. I should add here that for business reasons, the app in its current form is not available on the public market. The port to Android was a feasibility test, to verify the theory that WebKit combined with PhoneGap, would allow us to port to different operating environments with minimal difficulties. As such, it is a success.

There were, of course, several hurdles. We shall review them here.

Eclipse

Eclipse is a standard development environment for Java, and therefore, for Android. The downloading and installation takes time, but is fairly straightforward. The Android doc recommends pairing it’s SDK with Eclipse Classic or a derivative. This was fine for the Java code, but on the Eclipse Indigo system as I had installed it, the environment treats JavaScript as a static resource, and not as code, and would not copy the new files into final program. I had to quit and restart Eclipse altogether in order to freshen the code. It worked, but was tedious. It turns out that Eclipse for JavaScript Web Developers, aka Helios, works fine with the Android SDK. It helps, however, to set the Preferences for Android | Build | Build Output to Verbose, to be able to verify in the console that all the files are being copied over. I will add that installation of a .apk app file onto the Android emulator is shockingly slow. It probably is faster to just install it directly onto a real phone for testing. I will have to time it.

PhoneGap

Installing PhoneGap takes several steps, and unfortunately, there are 2 versions of instructions : http://wiki.phonegap.com/w/page/30862722/phonegap-android-eclipse-quickstart, and http://www.phonegap.com/start#android. I wound up following the “Creating A New Project” section in the first one. It includes an onDeviceLoad function that we need. Both versions have the same useful note about what to do if Eclipse does not recognize the libs/phonegap-1.0.0.jar file. This works. A second gotcha to be aware of is that the phonegap-1.0.0.js for Android is NOT the same as phonegap-1.0.0.js for iOS, even though they have exactly the same name. When porting your code back and forth between environments, it’s probably better to give them different names.

Scrolling

The biggest challenge porting this app is the lack of scrolling within a static html frame on both iOS and Android. In our case, we have a list of words that we need to scroll through vertically, but want some tabs and buttons to remain in place above the list. We had to add on iScroll (mini) to make the mobile WebKits work as their desktop cousins do. There are other more complete frameworks (Sencha Touch, JQuery Mobile, Jo) that also have a similar workaround, but iScroll seemed to offer the simplest solution on both mobile platforms.

Local Storage

The app needs to keep track of which words the student learned, and which chapter they were last working on from session to session. What we needed was essentially persistent cookies. PhoneGap’s localStorage facility works fine, and was easy to get up and running.

Sound

The app needs to play mp3 recordings of the words as spoken, but HTML 5’s <audio> tags do not work in the WebKit webview on either device. Again, PhoneGap’s Media facility works – after we figured out from reading the open source code in AudioPlayer.java that we needed to add “/android_asset/www/” to the front of the path to the sound file in order for the system to find the local file. The example in the standard doc only shows how to load a sound file off the web.

Back Key

Android has a Back/Quit key as well as a Search and Menu keys that iOS does not. We wanted to intercept Back/Quit presses to prevent quitting the app without first asking for confirmation from the user. The doc at http://docs.phonegap.com/phonegap_events_events.md.html#backbutton explains how to do this, and it was simple to install.

Success

We now have an app that works nearly identically on iOS, Android, Windows, Mac and Linux using 90% the same code. Doing it this way is not for amateurs, as learning to work with the XCode, Cocoa, Objective-C, Eclispe, Java, and, if desired, Adobe AIR environments takes time. But once learned, the increase on productivity is enormous.