--- title: Experiences Rapidly Porting J2ME Apps to Android description: Experiences Rapidly Porting J2ME Apps to Android image: https://blog.masabi.com/hs-fs/file-3502426064-png/blog-files/microemu.png --- [![](https://blog.masabi.com/hs-fs/hubfs/masabi%20186.png?width=150&name=masabi%20186.png "masabi 186.png")](http://www.masabi.com/) 15-Dec-2010 12:43:51 by [Tom Godber](https://blog.masabi.com/blog/author/tom-godber) # Experiences Rapidly Porting J2ME Apps to Android - [Tweet](https://twitter.com/share) 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. [![](https://blog.masabi.com/hs-fs/file-3502426064-png/blog-files/microemu.png?width=295&height=37&name=microemu.png "microemu")](https://blog.masabi.com/hs-fs/file-3502426064-png/blog-files/microemu.png) This is achieved using an automated Jar-to-APK conversion tool built into the open source [MicroEmu project](http://www.microemu.org/). The steps for a basic conversion go something like this: 1. Check out the entire microemu project from Subversion: `http://microemu.googlecode.com/svn/trunk/microemulator` 2. 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…) 3. 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](http://www.htc.com/www/SupportViewNews.aspx?dl_id=1062&news_id=806) 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”*: ![](https://blog.masabi.com/hs-fs/file-3502426074-png/blog-files/settings.png?width=668&height=326&name=settings.png "Android Settings") ## Picking The Right MIDP Jar Our [Nokia](http://www.masabi.com/passengers/nokia/) and [Blackberry](http://www.masabi.com/passengers/blackberry-handsets/) 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 an `RGB_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 using `setColor` - `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](http://developer.android.com/guide/practices/screens_support.html) 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](http://developer.android.com/resources/dashboard/screens.html), 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. ### Written by [Tom Godber](https://blog.masabi.com/blog/author/tom-godber) [ ### San Joaquin Regional Transit District Launches Open Payments with Masabi, Delivering “A Faster, Easy Way to Pay” Across Stockton and the Central Valley Jul 2, 2026 ](https://blog.masabi.com/blog/san-joaquin-regional-transit-district-launches-open-payments-with-masabi-delivering-a-faster-easy-way-to-pay-across-stockton-and-the-central-valley) [ ### How SaaS Fare Collection Keeps Getting Faster at Scale Jun 30, 2026 ](https://blog.masabi.com/blog/how-saas-fare-collection-keeps-getting-faster-at-scale) [ ### Tap, Ride, Repeat: How Masabi Is Scaling Open Payments Across North America Jun 30, 2026 ](https://blog.masabi.com/blog/tap-ride-repeat-how-masabi-is-scaling-open-payments-across-north-america) ### Menu [Fare Payments as a Service](http://www.masabi.com/fare-payments-as-a-service/) [Justride Platform](http://www.masabi.com/justride-mobile-ticketing/) [Account Based Ticketing ](http://www.masabi.com/account-based-ticketing/) [Mobility as a Service](http://www.masabi.com/mobility-as-a-service/) [Mobile Ticketing ](http://www.masabi.com/mobile-ticketing/) [Contactless EMV](http://www.masabi.com/contactless-emv-ticketing/) [Blog](https://blog.masabi.com/blog) [Content ](http://www.masabi.com/resources/) [Careers ](http://www.masabi.com/we-are-hiring/) [Contact Us ](https://www.masabi.com/about/) [Request a Demo ](https://info.masabi.com/justridedemo) ### About Justride Masabi’s Justride is the leading Fare Payments platform for public transport. Transit agencies and operators can sign up to mobile ticketing services, enable Mobility as a Service (MaaS) and deploy an account-based system allowing passengers to simply tap a contactless bank card, mobile device and smartcard to travel, without needing to buy a ticket or understand fares. With over seventy agencies of all sizes across ten countries signed up, Justride is leading the movement away from bespoke and expensive ticket systems to Fare Payments as a Service. ### About Masabi At Masabi we believe a new Fare Payments system allowing passengers to just tap and ride, without needing to buy a ticket or understand fares, should be available to every passenger and every transit agency around the globe, without prohibitive costs or taking years to deliver. By providing a Fare Payments platform which is constantly improving and connected with leading mobility applications (for full first-last mile journeys) Masabi is helping passengers move seamlessly from A to B, attracting more people to conveniently ride public transit. ### Masabi Newsletter © Masabi Services - All Right Reserved. **