My Photo

About Me

  • Hello you. I'm a 38-year old MSc student, studying Advanced Computer Science at Sussex University. I'm especially interested in Internet and mobile software, sensors and pervasive computing, user interfaces, and the process of developing great software.

    Before that I spent 11 years running Future Platforms, a software company I co-founded which makes lovely things for mobile phones, and which I sold in 2011.

    I read a lot, write here, and practice Aikido and airsoft. I live in Brighton, a seaside town on the south coast of the UK, with two cats and a clown.


Stalk Me

  • Email me:
    twhume at gmail dot com
Blog powered by Typepad

« W3C processes | Main | Thoughts on the demise of Trutap »

November 29, 2008



As someone else wishing the porting headache would go away for a very long time as well, I found your presentation at FOM interesting

We have always taken an approach similar to what you describe 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

Tom Hume

Kieran: well yes, the subtext of what I'm saying is that you still need to know what you're doing. I'm fortunate to have a team that know their onions - it sounds like you do too :)

We tend to avoid JAD parameters for switching capabilities on and off, and try to embed this logic inside the MIDlet itself: the more we can automate, the less chance there is that someone will mess up a setting manually.

And I know what you mean re iPhone: very attractive platforms indeed (though numerically dwarfed by J2ME-capable devices still). We're beavering away and will have our first apps out in the next month or so ;)

The comments to this entry are closed.