Masabi has a fully integrated Android app launching early next year, with a UI carefully crafted to fit the current best interface guidelines for the platform, adapting to different device form factors (just as we do with our MIDP apps) and integrating into the OS and other apps using carefully designed intents, content providers etc.
We have always believed in tailoring an app’s UI to the platform, following the expectations of the user rather than seeking a consistent brand experience across devices – because the user only uses the app on one platform and is entirely geared to understanding how their own phone works. Any app that breaks those conventions risks annoyance by being awkward to use.
However, with Christmas rapidly approaching, and our BlackBerry and Nokia apps proving extremely popular, we realised it made sense to offer a high quality interim Android app to meet the immediate needs of this rapidly growing user base.
While it would lack the complete integration of our native Android app launching in a month or so it was essential that the app provide a simple, quick, attractive and above all user friendly means for looking up train times and buying tickets. But how could this be done?
MicroEmu To The Rescue
If you have a working touch-screen app in MIDP, it is remarkably easy these days to get that code running on Android – it’s by no means a standard “Android app”, but it is an app that users can use and as an interim measure that can be very attractive.
This is achieved using an automated Jar-to-APK conversion tool built into the open source MicroEmu project. The steps for a basic conversion go something like this:
- Check out the entire microemu project from Subversion:
http://microemu.googlecode.com/svn/trunk/microemulator
- Build the entire microemu project using Maven – for me, this worked from the command line (default target – so just type “mvn” in the root), but did not work from the Eclipse M2 plugin (no idea why…)
- Point the microemu-android/build.xml Ant file at your jad and jar, and run the package-apk target.
At this point, you should be able to install the APK through a cable (eg. using HTC Sync on a Desire) or via e-mail or a web server. Remember that you may need to visit the Settings app, go to the Applications section and check “Unknown sources – allow installation of non-Market applications”:
Picking The Right MIDP Jar
Our Nokia and Blackberry MIDP app runs using our own custom application framework inside a Canvas
, which brings advantages and disadvantages. Therefore converting LCDUI components using MicroEmu was a new approach; however, if you have your own Canvas based framework here are the considerations for making the conversion work well:
- Touch-screen enabled, working a lot like Android’s UI (and other modern touch interfaces)
- Don’t show “soft key” style buttons in the footer (as used eg. in Symbian^3).
- Back actions should be triggered by MIDP physical key code
-4
- Don’t use an on-screen touch button.
- Accept QWERTY keypresses in the normal way
- Physical key codes are the key character’s ASCII/UTF-8 value.
- Accept Up/Down/Left/Right keypresses using
Canvas.UP
, etc key codes; - Optionally, trigger any Search features using the Search physical key code
-84
; - Optimise graphics for screens ranging between 320x480 and 480x800.
Tidying Up The Conversion
The basic conversion introduces a number of compromises, which we solved by forking our local copy of MicroEmu. We opted not to push these back to the original project because the changes we made were simply to allow us to launch a specific app in a short timeframe, rather than being fixes of wider benefit to the community. Issues we encountered included:
- Tweaking font sizes to match our layouts;
- Turning off anti-aliassing in AndroidDisplayGraphics
setAntiAlias
to false instead of true wherever possible;- If anti-aliassing is on then a number of MIDP graphics techniques – eg. drawing adjacent lines to create graduated fills – fail, ending up looking very blurry and semi transparent
- The screen buffer now uses an
ARGB_8888
Bitmap instead of anRGB_565
- This increases the colour depth, and leads to nicer looking graphics;
- For this depth to then make it onto the screen, it proved essential to turn on dithering on the CanvasView inner class of the AndroidCanvasUI.
AndroidDisplayGraphics
was adjusted to honour an alpha channel set usingsetColor
getColor
always masks off alpha channel;- This allows us to plot semi-transparent features on the screen, without resorting to PNG24 images.
- Screen rotation was turned off by fixing the app to portrait orientation in the manifest
- MicroEmu interacted very badly with the MIDP Canvas.sizeChanged event method, and it was easier to turn rotation off then fix the bug.
Compromises
The key compromise is that resource loading bypasses Android’s own rather nice versatile resource loading system which would usually load appropriately sized resources for you.
In our case, this meant that we had to drop support for “small” Android screens – anything around the QVGA mark – because images that looked good on “normal” and “large” screens totally failed to work nicely on small screens. As of August 2010, these two supported screen sizes cover well over 90% of Android handsets, though as Android devices are pushed into the cheaper end of the market the share of small screens will grow. We will support the remaining segments of the market with our future full Android application.
Needless to say our preference is for native apps and this is ultimately what we will always deliver. However, this exercise has illustrated that it is perfectly possible to develop highly compelling Android apps in a timely manner based on ports from different platforms. Undoubtedly there will be some die-hard Android users who love native apps and their unique UI features (this most certainly includes us!) but if you want to deliver a great looking app that’s highly user friendly based on a different platform it’s clearly achievable if the right steps are taken.