Eric Giguere

Depends what kind of handheld you're talking about. For PocketPCs or Symbian devices, Java is definitely an option, it's here now. For Palm devices it's just starting to be viable: you really need to use a special product like IBM's J9 or esmertec's Jbed to do serious work. Sun's Palm solution right now, MIDP4Palm, is simply not good enough.

MIDP defines a system property called "microedition.locale" that defines the device's locale.

Originally posted by Horaci Macias:
I agree with Andres, I find your tech tips very useful. Just some suggestions:

Thanks!

* I tryed to download your source code of "PARSING XML IN CLDC-BASED PROFILES" and I can't. The url is http://www.ericgiguere.com/techtips/XMLTest.zip. Is there another location for this file?

There seems to be some kind of internal configuration error with my web server. I have contacted my hosting service so that they can fix it. In the meantime, you can send me mail and I can send it out to you.

* I've read a lot of tech tips from http connections to xml parsing, but I haven't found any tip comparing j2me toolkits or IDEs, and how to write/compile/debug with them. I think it would be useful a tip describing how to debug MidLets, to avoid System.outs or other kind of traces.

The format of the J2ME Tech Tips is set by Sun and must be vendor-neutral, so I can't do that kind of thing, sorry.

Finally, I think people would send you more feed back if you created some kind of "competition". I mean, if you explain how to use RMS and finally you suggest a little exercise like "how to read/write from/to RMS minimizing memory use and time" and present the readers' solutions compared you would get (in my opinion) more feedback.

Again, the format is not up to me. You'd have send feedback to Sun (there's an address at the end of the tech tips) and suggest it.

Glad you like them. All of the tech tips are available for reading online on Sun's JDC (Java Developer Connection) website. There's a link to the page on www.j2medeveloper.com.
Eric

As some of you know, I write a monthly set of J2ME Tech Tips for Sun. I don't get much feedback on them, (which generally means it's positive, I think) so if you have any feedback I'd like to hear from you. I'll often base my tips on questions that I get that involve more than just a paragraph or two.

MIDP's RMS does not provide direct access to native databases. Yes, RMS record stores are implemented using native databases, but the format is undocumented and can change at any point. If you really want to write a conduit, you can do it providing you understand that what you're doing is not officially supported.
The upcoming Personal Digital Assistant Profile (PDAP) will hopefully address these kinds of things. MIDP isn't really powerful enough for PDA-type devices, it's really meant for cellphones and other VERY constrained devices.

Why wait on the O'Reilly book? I published the first book by _anyone_ on J2ME, and just published a book devoted to MIDP. Either of those would be a great starting point for you. You can see the table of contents and sample chapters for them at www.j2medeveloper.com. There are also several other good books available from other publishers.

Your application is using too much memory. You have to change it to create less objects, to allocate less memory for arrays, etc.

After you guys get your copies of the book, Enrique & I would appreciate it greatly if you'd post reviews of it up on Amazon.com. Be honest, and try to be as detailed as you can. Thanks!

The example in the Tech Tip works, I know, I wrote it. The initial readInt in the client is important because it tells the client how many strings it should read.

If the VM runs on top of BREW, then yes, I'd expect some performance loss. However, the VM can easily be written to run directly on top of the native OS and to coexist side-by-side with the BREW runtime, in which case it wouldn't be so much of a problem. It's really up to the device manufacturers, I think, to decide which way to go.

The classes in the high-level UI API are not meant to be subclassable by outside developers. In other words, there's no way to write your own custom controls that work on forms. You can write custom controls that work on a canvas, but then you have to do everything yourself.

It's up to the device/emulator to decide whether a "pause" button pauses or destroys the application. That's not something covered by the spec. In this case you're seeing it destroy the app.

There is no way to activate a MIDlet from another MIDlet. If the two MIDlets are in the same suite, though, they can use the same classes and the same record stores and they can share information that way. But the MIDP spec is silent on what it takes to activate a MIDlet -- it's dependent on the device.

The KVM and the CVM are both Java virtual machines. The KVM is meant to run on very constrained devices and does not support the full feature set of a standard J2SE VM. The CVM, on the other hand, supports all the features of a J2SE VM but it is a new VM written with portability and modularity in mind.
From an application developer point of view it doesn't really matter which VM is being used, what matters is which J2ME configuration (CLDC or CDC) is being used. It's up to the device manufacturer to supply a VM that supports the configuration, and they may choose to license the KVM or CVM from Sun or else write their own from scratch or use someone else's.