Fabrizio Giudici is a Senior Java Architect with a long Java experience in the industrial field. He runs Tidalwave, his own consultancy company, and has contributed to Java success stories in a number of fields, including Formula One. Fabrizio often appears as a speaker at international Java conferences such as JavaOne and Devoxx and is member of JUG Milano and the NetBeans Dream Team. Fabrizio is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Some Considerations About Developing MIDP Applications

06.30.2008
| 6300 views |
  • submit to reddit

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.

Published at DZone with permission of Fabrizio Giudici, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bruce Fancher replied on Mon, 2008/06/30 - 7:48am

J2ME is obsolete junk so why are you still messing around with it?  There's only one mobile application platform that's any good.  Go ahead and download it and see what you've been missing.

Fabrizio Giudici replied on Mon, 2008/06/30 - 7:56am

Great idea - so my applications would be able to run on less than 1% of the phones around...

Shai Almog replied on Mon, 2008/06/30 - 8:29am

Its amazing to see an iPhone fanboy calling something obsolete... You guys are still stuck in 2G and you are calling everyone else obsolete ;-)

The funniest thing is how Steve himself derided the slow speed of the existing iPhone now that they have "finally" built a 3G device barely a year after badmouthing 3G. Can you point at a single iPhone SDK feature that is missing from MSA/Java ME?

Fabrizio Giudici replied on Mon, 2008/06/30 - 8:56am

But the UI is so cool... that's what most Apple buyers need. :-)

Brian Sayatovic replied on Mon, 2008/06/30 - 1:01pm

Keep in mind that StringTokenizer tokenizes a String on multiple separator characters.  In most cases you find you only have one separator character.  Creating a custom StringTokenizer that specializes in a single-character separator can yield huge benefits (in an old Java 1.3 app, we had a page that went from being unusably slow to decently fast!).  This may be less important on modern desktops, but on a mobile device, the difference may yet prove noticable.

Brian Sayatovic replied on Mon, 2008/06/30 - 1:02pm in response to: Bruce Fancher

That link must be broken...  it didn't take me to Android.

Bruce Fancher replied on Mon, 2008/06/30 - 1:26pm in response to: Fabrizio Giudici

[quote=fabriziogiudici]Great idea - so my applications would be able to run on less than 1% of the phones around...[/quote]

 I guess it depends.  If you're writing something simple and you're goal is to get it on as many handsets as possible, then targeting the iPhone might not be the best option.  However, if you're writing a custom application for a corporation and you want to be able to write the most powerful, sophisticated application possible, then choosing the iPhone as the corporate standard, just as many companies have currently done with the Blackberry, is not unreasonable.

 

Bruce Fancher replied on Mon, 2008/06/30 - 1:35pm in response to: Shai Almog

[quote=sa74997]The funniest thing is how Steve himself derided the slow speed of the existing iPhone now that they have "finally" built a 3G device barely a year after badmouthing 3G.[/quote]   Huh.  I don't remember hearing Steve badmouth 3G.  The first generation of the iPhone didn't support it for reasons of cost and battery-life, but the new generation does, so if 3G is important to you then this is no longer an issue. 
[quote=sa74997] Can you point at a single iPhone SDK feature that is missing from MSA/Java ME?[/quote]  Are you joking or have you just not given the iPhone SDK a look?  J2ME is a klunky primitive piece of junk, and I've done J2ME development professionally so I know what I'm talking about it.  If you haven't already done so, go ahead and download the iPhone SDK and take it for a spin.  Try laying out an interface using Interface Builder and writing your application using the APIs.  Or go to the Apple web site and watch the WWDC keynote where several iPhone applications were demoed.  Can you point to any applications on any other mobile platform that even come close?  The iPhone SDK is a real platform, which comes much closer to developing a desktop applications than any other mobile platform currently available.

Shai Almog replied on Mon, 2008/06/30 - 2:02pm in response to: Bruce Fancher

[quote]Huh.  I don't remember hearing Steve badmouth 3G.  The first generation of the iPhone didn't support it for reasons of cost and battery-life, but the new generation does, so if 3G is important to you then this is no longer an issue. [/quote]

Steve lied about 3G and battery life/form factor dismissing it as unecessary compared to Edge... He very specifically said that it wasn't important. This is obviously BS since this phone: http://www.sonyericsson.com/cws/products/mobilephones/overview/w880i?cc=us&lc=en was available about a year before the iPhone and has 3G with video phone front camera not to mention the size of the old iPod nano... 

 [quote]Try laying out an interface using Interface Builder and writing your application using the APIs.  [/quote]

Try LWUIT and pretty soon Matisse for it. 

[quote]Or go to the Apple web site and watch the WWDC keynote where several iPhone applications were demoed.[/quote]

Saw every single one of them and haven't seen anything impressive. The 3D looks reasonable but not much better than JSR 184 (M3G) which we had for ages, since its a standard OpenGL ES 1.1 implementation thats hardly a big deal... Not even version 2.0 so no shaders or anything special... 

 [quote]Can you point to any applications on any other mobile platform that even come close?[/quote]

http://www.sumea.com/

http://www.superscape.com/

[quote]The iPhone SDK is a real platform, which comes much closer to developing a desktop applications than any other mobile platform currently available.[/quote]

It comes close to developing Mac applications which is a HUGE pain and requires a Mac (which sadly I own, its a terrible computer but I digress). 

Its very easy to build an SDK for one platform with one phone that has one resolution and not too many features, push is apparently a modern concept for iPhone developers... The SDK is weighed down by limitations both in access and licensing making it the typical Apple encumbarence nightmare. 

Java ME is far from a panacea, its got its huge list of problems both compared to Java SE and to the iPhone. But you can do with it pretty much every single thing you can do with the iPhone and more. You can even do with it most of the things you can do on Android.

So its not the best platform in terms of development ease, deployment, uniformity or quality... However unlike the iPhone, people actually have devices that really work with this.

Apple has had a history of being developer hostile, canceling support for API's and dumping platforms despite strong guarantees in the past to support them. Very strict unapologetic licensing, limitations and lawsuits. If you want to develop for these guys, then enjoy but there is no technical superiority in the iPhone when compared to Java ME.

Fabrizio Giudici replied on Mon, 2008/06/30 - 2:30pm

Bruce, of course if you have a specific deployment target, you can go with a specific model. Apart from the cool factor, the iPhone doesn't look to me the best option either, since its SDK is completely proprietary and you would get into a strong vendor lock-in.

Said that, "J2ME is a piece of junk" is not enough to convince us that there are things the iPhone can do and J2ME doesn't. BTW, I can say one thing that J2ME can do (on many platforms) and iPhone can't: multitasking. Jobs says it's for the battery life again (I think he should get more fantasy when he has to hide behind a corner), but that's clearly not true, because the competitors can. It's clearly a point about forcing people to develop with a specific model, which relies on network pushes and make you waste money with your telco. Also the impossibility of distributing my own application with my favourite channels, as I'm forced to go through Apple iStore, is bad (please no excuses about securiry: there are billions phones with Java support out there and no major security issues when you just go with digital signing).

Sorry, too many constraints. In the XXI century I'm not saying that people have to necessarily go with open source, but at least with reasonably open platforms. Most of the other mobile platforms supported by J2ME are (BTW, Symbian has just got open sourced too).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.