J2ME Porting

There's an interesting take on the mobile porting issue at MobHappy, which because of the way it was pitched to the author did read a little bit like a straight plug for Innaworks' mBooster. It's a mighty impressive compression tool with a price tag to match, but it doesn't in itself address J2ME porting. I'll expand on my comment a bit below, as porting is a huge issue with J2ME that seems to put a lot of people off.

Unless you are writing a very trivial or ugly app, no IDE will be able to seemlessly port across all devices, and a lot of the reasons for that are not specific to Java. Claiming that the restrictions imposed by handsets are tied into Java is disingenious - Java has become so widespread because some flexibility had to be given in the specs, and this has made it the only mass market platform worth developing for (except BREW in a few countries).

Any open platform which becomes deployed on multiple vendor’s devices starts to fragment, as Flash Lite is doing despite having tiny market penetration split between two largely incompatible versions. (More coming on Flash Lite at some point from Thelf I believe...)

You can adopt a one-jar-fits-all approach for simple/ugly apps, and sometimes it is forced on you when eg. you have no specialist hosting capable of delivering device-specific binaries; in these cases tools like mBooster are a particular help because they can minimise the overhead of all that redundant cross-device code. However it’s the wrong approach for most mobile apps because in the end you are forced to either needlessly restrict the app for the lowest common denominator, or more seriously you must ignore the mass market low-end phones to concentrate only on the easier high-end devices.

A well designed build system that can deliver device-specific Jars from a common codebase is essential to proper mobile development, as is a hosting system capable of pushing those Jars to the right devices. Many hosting systems are available, including all those which power the operator portals like End2End, QPass and ProvisionX and some smaller players like Mobile365; a lot of these are based on the WURFL and its absolute URL matching approach, which means every time a firmware digit changes the handset isn't properly supported for a few months until the WURFL is updated, but I guess you can't blame them for that and there are simple algorithms which can improve on it. The build system side is something you refine over time - obviously the big gaming guys will have them, and I'd imagine some of the older specialist mobile houses like Future Platforms, Masabi and Cellectivity also have equivalents, or you can pull one in from Polish (if you don't have much money) or Tira (if you do).

Here’s an incomplete summary of differences you (may) have to factor into porting:

Java

• (many) handset-specific bugs, which get the most press but really once you know them can safely be ignored / abstracted away
• The exact MMAPI code needed to play sounds efficiently (one of the worst areas)
• Key codes, whether release events are handled reliably, etc (though some of this can be abastracted away)

Handset

• UI considerations:
• Pen vs QWERTY vs Suretype vs standard numeric
• Available keys
• Graphics optimised for the different screen sizes
• JPEG support
• Alpha transparency support
• PNG loading bugs (eg. Sagem tearing, Samsung white/transparency misloading)
• Supported sound formats
• Optional API support
• Jar sizes, and what functionality you have to drop for the small ones

mBooster is a useful tool for your arsenal which helps with the last point, good for squeezing in extra functions but not really a substitute for writing efficient code designed for a constrained platform. DashO is another alternative (though not as good), and I’ve heard if you start with the right design you can achieve most of the mBooster savings with a few days of building custom tools.

I would argue it is better to ditch 90% of what you learnt about good OOP design principals though, coding for minimum memory footprint and heap fragmentation, etc etc. If you then still need extra space, as with any other tool you then assess whether the price justifies the gains and plan accordingly. Great to know it’s there, but I have heard the annual price per developer is quite some way north of Photoshop so not within everyone’s budget.

There’s a wide spectrum of approaches to the porting world. APIs like Polish can help with the porting alongside mBooster, as they also address a number of handset bugs and provide a rather lardy way of making the app look prettier than an lcdui interface. Systems like Tira Wireless’ Jump platform offer the next level of automated porting if you have some VC cash to spend and want to be further abstracted from the underlying issues. Finally you can actually know what you’re doing and learn all the handset issues the hard way, abstracting into an ultra compact reusable platform, which not everyone has time for - on the plus side that gives you absolute control over everything you put on screen, but on the minus side you then have absolute responsibility to put everything on screen correctly.

Your approach is dictated by your experience, your timeframes and your budget. mBooster can help whichever approach is best for you because it’s just a tool, and only a small part of the picture. If it all gets too much, give one of the specialists a ring, I'm sure they'll only be too pleased to handle everything for you!