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:

Is still there any Java ME Programmer Thinking in Object?

About Object Programming
Technorati Tags: , , ,

11 thoughts on “J2me mobile development practices”

  1. You are wrong when you say that the only way to handle specific JSRs on a single code base is to use preprocessing.

    There is this little known trick to use “static final boolean USE_JSR = true” and wrap all JSR calls with that. To remove all of that from the code, just set this variable to false. You must use an obfuscator because the obfuscator does remove code that is not used and by defining “static final” it knows that code has got to go.

    Using this technique you can easily setup different builds from the same source code without preprocessing directives. You can arrange “static finals” into one class/file and have only that file preprocessed or simply modified by an Ant script (for example – simple search and replace will do it).

    Most of these “Assembly Java” tricks are very bad for code maintanance and nowadays are really not needed since most phones have plenty of memory and processing power. A lot of times the bottleneck is at a completely different place than anticipated and you can only find out by using profilers and disassembler (for decreasing .class size).

    Carlos.

  2. I did not say it’s the only way, there are others ways. But it’s one of the way to do it when you have mutliple constraints at the same time.

    As I said, this is changing with time. In recent phones, this is quite useless, but on older, or very constrained devices, some are still valids, believe me.

    And doing “search and replace” on a file is like preprocessing, no?

    I give you an example: on J2ME, supporting both Floating point on CLDC1.0 and on CLDC1.1. Of course, I could use a Float class for both, and wrap CLDC1.1 float type on an object.

    But then I have a HUGE penalty of creating a lot of interim Float object, and loose benefit of natives float. This is obvious on some devices like blackcberry, where garbage collection is very costly…

    But may be there is another option?

    (and yes, I do use an obfuscator, don’t worry!)

  3. Why not let the jme developers use all of the OOP constructs/patterns they’re use to and ADD a step into the build process that preformats (preprocesses) code into a 1 midlet class then? I mean we have all this knowledge about jme oop shortcomings to our avail. All I’m saying is, Just dynamically reverse engineer OOP at compile time so that you end up with Netbeans ‘Visual Midlet’ style code subject to obfuscation to decrease mem foot even more?

    -s4111

  4. If you want to do preprocessing why not use a tool like j2me polish to sort out your issues.

    I think good compilers to should also be able to inline methods that are declared static and final.

    And with regard to the comment:

    Most of these “Assembly Java” tricks are very bad for code maintanance and nowadays are really not needed since most phones have plenty of memory and processing power.

    As a developer, I try to always push the perfomance of my code. If I can find anyway to decrease startup and increase performance, I will put it into the code.

  5. Mindinhand: You’re right, J2mepolish is another tools to do some preprocessing…

    And I agree, that most of these “tricks” slowly tends to disappear. However, there is still always some “tricky” cases from time to time

    Charl: you are right, it’s another option too. But one of the issue with this approach, is then it’s very hard to debug on someplatform, and this could generate some more complex problem to debug if your tools does not do exactly what is expected.

  6. Yea Tom, This would be alot of overhead in fulfilling a need that’s slowly fading as micro devices mature.

    Mindin.: I wasn’t referring to standard preprocessing (polish shud be the standard ;-). I’m hinting at some kind of code optimizer that would convert multiple classed midlets into a one classed “Netbeans Visual Midlet” style midlet.

    I think we’ll all be old and grey by the time that surfaces.

    Tom: What r ur thoughts on using a DisplayManager class with public members used for requesting Displayables in midlets? This currently ensures that displayable objects will only ever be instanciated once.

  7. I don’t like the idea of making sure things are instanciated just once.

    I run into the outofmemory wall quite often on my app that has different screens. One screen users a parser to read data from a file. I’d much rather instanciate the objects as I need them, and then be really clean with my de-referencing to make sure garbage collection works well. With the approach of just instantiate everything once, you end up having stuff reside in memory when it isn’t needed.

  8. I think the idea of preloading everything or loading as needed is really decided by the targetted handset. Some phones work well with unloading and loading lots of objects whenever you need them. However, on other phones, even if you are really careful to unload and reload properly, fragmentation still occurs and you eventually still have problems with being out of memory. The best practice is probably to wrap loading in a function where you can change loading as needed. This way if the handset benefits from having things preloaded, you can do it seemlessly without messing with the rest of the codebase. If you are working on such a phone like the Nokia 7210, which needs the minimal amount of things loaded, you can handle this too…either way this can’t be a black and white issue as with any issue in mobile development…especially mobile game dev.

  9. Hi there! Do you have any tips on creating a clone of the game Q-bert in j2me. I am really struggling. I have gone to school for programming at both the college and university levels, and started when Java just came out….well that was my 2nd or third year, so I am an old-school C++ girl and I’m trying to get this working! I have painted my pyramid on the screen using a tileset of ‘parts of cubes’, but I am now at the point where I need to do the animations. I have all the points calculated that the sprite needs to move to. The board is displayed using block data. Since the board is really a binary tree, should I create nodes that reference each block? HELP!!!! PLEEEEESE!?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>