[CoMoDev] Re: The state of Java for Palm OS

  • From: David Beers <david@xxxxxxxxxxxxx>
  • To: <comodev@xxxxxxxxxxxxx>
  • Date: Thu, 10 Jun 2004 10:01:38 -0600

Sue made a great J2ME presentation last night.  I started out taking a lot of 
notes, but quickly realized that her slides where going to be a lot more 
comprehensive than anything I could take down.  Before long those should be 
available as a download here: http://www.denverjug.org/presentations/index.html 
 There's a LOT of good information in there because this was condensed from her 
2-day J2ME bootcamp.  Perhaps "speeded up" as much as "condensed"! ;)  S'ok, I 
like it fast and furious!

A couple of factoids that I found interesting to throw out there right now:

* There are 250 milliion Java enabled devices out there today. (Devices? are we 
including PCs here or just "mobile" devices?)
* By 2006 that number is expected to increase to 1 billion. (OK, now that 
growth obviously can be attributed mostly to mobile devices)

J2ME is a catch-all phrase for various incarnations of Java that are broken 
down first by "configurations" and then by various "profiles" that sit on top 
of each configuration, but most of the action these days is in the Mobile 
Information Device Profile (MIDP) which is part of the Connected Limited Device 
Configuration (CLDC).  When you hear MIDP, think mobile phones and 2-way pagers 
and think "subset of standard Java." 

There is a J2ME configuration called CDC ("Connected Device Configuration") 
that is actually a full-fledged implementation of Java 2 Standard Edition, but 
it's for more powerful devices with windowing systems (set-top boxes and stuff 
like that device I posted a link to a couple of days ago, perhaps?).  
Ostensibly, CDC with its "Foundation Profile" sitting on top is supposed to be 
good for devices like the powerful PDAs and smart phones we have today, and 
most likely there is a CDC/FP VM that would run fine on a PocketPC.  But as the 
fact that CDC covers *all* the J2SE libraries started to sink in with me I 
realized why Palm finally gave up on developing the PDA profile of CDC.  The 
Palm OS is not a windowing OS so how would something like Java's Advanced 
Windowing Toolkit work on a Palm PDA or smart phone?  I suspect that even if 
they had achieved it, it would have been at the cost of all the great usability 
and battery life of the Palm OS, so at that point it probably had questionable 
value.  This isn't to say Java won't become a popular programming platform on 
Palm-powered devices, just that for the time being it seems like J2ME apps for 
Palm will use the somewhat more limited MIDP.  IBM has been working hard to 
extend MIDP with optional packages to provide a satisfying experience for folks 
with powerful devices running Palm OS, Windows CE, Linux, etc. but since Sue's 
talk wasn't focused on Palm and PocketPC I don't really know yet how well they 
have succeeded.  One thing I can say: don't expect to be able to use floats or 

MIDP is evolving to try to keep up with the reality that "limited devices" are 
becoming less limited all the time and that people need stuff like secure 
network communications (enhanced UI and secure sockets are in MIDP 2.0) so 
that's probably the place where Java will remain the most interesting to 
PDA/smart phone developers.  At least it seems to offer some hope of enabling 
us to write an app that will run on Palm, PocketPC, Linux, Symbian (?), and 
that's what interests me.  Just what the limitations of that app would be, I'm 
still not completely clear.

An advantage of MIDP's phone-centricity is the fact that as of 2.0 it's got 
"over the air" provisioning (software installation) as a built-in feature.  So 
if you're doing a consumer product it sounds like downloads and installations 
directly to the device over wireless are easy.

One of the things Sue touched on that gave some insight into the world of Java 
for a guy like me who hasn't done cross-platform development is the dilemma 
posed by the UI.  Think about it for a moment.  You've got all these different 
OSes or embedded systems running on devices with very different screen 
resolutions, dimensions, and color depths.  Almost inevitably there are going 
to be trade-offs between portability and GUI features.  MIDP allows you to 
handle the trade-off by taking one of two approaches: abstraction or discovery. 
 Abstraction leaves a lot of the UI details (how things look, how they are 
positioned, etc.) to the Application Management System (part of the VM, I 
suppose?) to work out.  That means it is the most portable.  It's what Sue 
demonstrated and I can understand why: if you're targeting the wide consumer 
market you can't possibly test on hundreds of different devices, so leaving a 
lot of the details to the AMS, which is presumably fully compatible with the 
device it's on makes good sense.  On the other hand Sue kept talking about 
"giving hints" to the AMS of what you wanted the UI to look like, which frankly 
freaked me out.  I'd like to learn more about the discovery approach to the UI, 
even though this means finding out the device capabilities and then handling 
most of the drawing and painting yourself.  I'll bet there are some classes out 
there that can be used to draw nice UI objects.  Maybe something like this: 

There wasn't much time for Sue to go into a lot of details, but a couple of 
things got passing mention that made MIDP sound similar to the Palm OS.  One 
was the fact that MIDP doesn't rely on a file system for persistent storage. 
Instead it uses something called RMS, which is a device-independent 
record-oriented database.  (Of course, Palm OS does also use files, but only on 
removable media.)  The basic event-driven model was familiar in many respects 
as well.  Not surprisingly, you can do a lot of stuff with just a few lines of 
code, whereas even the simplest "Hello World" takes dozens of lines of code 
using the Palm OS C API.  As for using MIDP for PocketPC or MS Smartphone, I'd 
venture to say you'd have to have a great desire to support other platforms 
with your code as well, since the .NET Compact Framework has many of the 
advantages of Java and is quite a bit more complete than MIDP.

OK, that was more than I had time to write!


Other related posts: