TomSoft

J2me mobile development practices

It’s a long time that I am in the mobile industry, before J2me, and at a time where cell phone where not a mass market product!
I’ve followed the evolution of mobile development practices, especially in Java. So I agree partially with this article: The 10 principles of Assembly Java who gives good hint and tips for mobile development, but I also think that hopefully most of them will start to disappear slowly.
It’s a really strange industry, where on one hand people are talking of “MobileAjax” as the killer app, where the cost of one Ajax line is probably equivalent to the cost (in terms of CPU, memory used,battery) of a full Midp1.0 application, while other are strugling with putting everything in a single class to fit in constrained devices.

So the truth is as always, probably in between. These principles are mostly applicable if you want to deploy on older handsets (including MIDP1.0) or generally speaking phones older than 18 months, which is the biggest market in terms of installed base, but might not be the biggest one in terms of usage, but that’s another story.

MIDP is improving and got more memory, so I think that a few OO principles can be back. So I just compiled a few more advices, and I would be happy to discuss of them:

• Use carefully inheritance, but use it. J2me is an object oriented language and framework. Using inheritance could save a lot of code and time. Use this time to optimize other things.
• Reduce the number of classes to the minimum, but do not put everything in a single class; It’s better to have an elegant three classes design than a single classe optimized one. The benefit of the later will be killed by the complexity.
• Avoid setter/getter unless it creates too much constraints. For instance, if accessing directly to a variable and changing it haves no side effect, keep it without accessor, but if you change it and then you need to change a second variable, do accessor.
• Apply OO principle of high level classes, and “Assembly Java” on small granularity elements. A small granularity element is something that might be instancied (if it was OO) a lot of time in your program. For instance, do not create a 3D animation program with Objects like vertices, points, etc.. but keep things like World, or eventually Meshes as object.
• Use preprocessing! This is usually considered as a bad thing from OO point of view (which I agree) but it’s a good way sometime to solve embedded problems in a good way. The issue is then that you need to have a complete chain that will support this. In other words, if you generate several different binaries, you must have an easy way to provide to the end user the right binary. That’s something well handled by big companies, but hard for freelancer. The ideal situation (but require a lot of work) is to have only two or three binaries, one for low end, one for mid end, and one for high end devices. Typically Opera Mini achieve this very well. One real issue, is to deal with various JSR. On some Java implementation, it’s not possible to include in your J2Me some classes (like bluetooth) even if you do not use them because these are part of the javax.xxx package. The only way to solve it is through preprocessing.

Other links on this topic: