[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
doubles.
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:
http://www.synclast.com/ui_api.jsp
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!
David
Other related posts:
