Some Considerations About Developing MIDP Applications
Taking the opportunity given by a small consultancy in the MIDP field, which gave me the excuse of working with the Micro Edition, I've added some features (and bug fixes) to windRose (a MIDP application for delivering navigation services to a PDA/CellPhone with a connection to a GPS receiver) and a version 0.5.0 will see the light in July. The most important set of new features is the support for waypoints, which is a step towards the trip planning features for blueMarine.
Below I share a few points about MIDP development:
- With the exception of some specific GPS stuff (see below), the silliest waste of time so far has been writing a StringTokenizer and a readLine() method - I just can't believe that they are not part of the MIDP profile, since I just can't think of a real-world application that doesn't need them.
- So far, I've never used the NetBeans Mobility Pack for windRose (it was developed in 2006 and at the time you only had NetBeans 5.0). I must confess I didn't like it: while the idea of visually designing the navigation flow through MIDP screens is excellent, I really can't stand the generated code: everything gets into a single, bloated MIDlet class (with an ugly, single command listener method with a huge set of nested if-else constructs!). Whenever I consult about MIDP developing, I use NetBeans, I show my customers the Mobility Pack and then give them my opinion. They always appreciate the high productivity of the Mobility Pack and, reckoning that you always need to trade-off, many times I've been tempted to introduce it in windRose, but I never did. After the n+1-th consultancy, I've forced myself in trying it. Well, I must confess I developed the new features at warp speed when comparing to the work in 2006. Since my time is a precious resource, I've decided to keep the Mobility Pack for the next windRose improvements.
- But I still don't like the generated code! In addition to the points mentioned above, I can't stand the fact that every form gets flattened into the same Midlet - I'd like to encapsulate UI items in their own Form. I've tried alternative routes: for instance, subclassing Forms (and encapsulating their items) and then importing them into the Palette, thus using the Visual Designer only for the navigation. But if you go that way, you loose the capability of visual designing a Form, which is a waste of time.
Given that, and back to MIDP development in general, the most annoying problem so far has been the JSR-179, a.k.a. Location API. It's great, but it's not supported on Palm OS, so I had to write my own implementation. Now, my code can't use java(x).* packages because of security restrictions, so I've put it into ext.javax.microedition.location. It works fine, but now I'd like to start supporting officially some other kind of mobile appliance, such as Nokia (my most probable next buy). How can I write the same code that in some cases should depend on ext.javax.microedition.location and in others on javax.microedition.location? The NetBeans Mobility Pack introduces another specific feature, that is a pre-compiler with #ifdef for conditionally including or excluding code - apart from the fact that it's the fourth feature that I don't like at all, it doesn't work for conditional importing stuff.
Of course you usually address this problem with another layer of classes that delegate to the correct implementation, but JSR-179 has got many useful entity classes such as Coordinates, QualifiedCoordinates, Location, and I'd really like to avoid re-defining a delegate for each of them. So, my question: is it possible, using a specific procedure, to "augment" the libraries of a MIDP installation, I mean the equivalent of putting a JAR file in to $JRE_HOME/lib? Specifically, I'm talking of the IBM J9 for Palm OS.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)