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.
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.
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.
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.
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.
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.
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.