J2ME Fragmentation, limiting builds to solve the porting overhead

Posted by Kieran on November 30, 2008 under J2ME, Mobile | 2 Comments to Read

After attending FOM 2008 and seeing Tom Humes presentation on the strengths weaknesss and trade offs of mobile platforms, The slides of which can be found here

http://www.slideshare.net/twh/strengths-weakness-and-tradeoffs-of-mobile-platforms-presentation/

The mantra of fewer builds rather than customising for each individual handset where ever possible is something I have long believed in and practiced

I have always taken an approach similar to what Tom describes in trying to get any application in to as few rather than as many possible unique builds, usually using a combination of preprocessing and mainly through basing GUIs on the resources that they have available to them, be it fonts or graphics.

Whilst I can see how certain applications such as Trutap can achieve this with great success, (we ourselves have managed one application that only had 2 builds small and large, by using a clever graphics set, clever jad and conditional logic in the code).

What happens when conditional logic for testing APIs breaks down (JSR 205 on certain Samsung handsets for example) that will report availability, however will work with undesired results, To solve this we moved in to JAD parameters to conditionally switch our code.

However whilst getting the number of builds down the root of this problem is still that the team that is developing the application still needs to know all the niggles with J2ME, luckily as you state we are no longer limited to 64kb and sub 100kb builds where the conditional code was too “expensive” to consider including in a generic midlet and preprocessed out.

Layer on top of a now completed functional build signing via Java Verify, Operators, manufacturer or in house signing via a CA such as Verisign, all of which root certificates may or maybe not been present on a particular operator handset combination, and the necessity to bring builds down to a handful is very apparent

However is the effort not just being pushed up to the logical place of the main application rather than trying to fork for each build, with the main advantage being that for a tested, signed and certified application you already have support in a given build, rather than having to port for a fresh handset. This is really just leveraging years of experience into an elegant solution, for people new to the mobile market you quickly see the appeal of platforms such as the iPhone and Android.

These new platforms have effectively made the problem worse for J2ME once you get into the realm of connected applications as people are now expecting to be able to access their contacts, connect to a network and save information without having the continual nags of a Java application that even trusted third party signing does not fully negate!

For anyone who needs introducing to the headaches of J2ME, Intohand published a white paper back at the beginning of this year
http://www.intohand.com/javamobilepdf.php