Slashdot Mirror
MIDP 2.0 Style Guide for J2ME
MIDP 2.0 is also a fairly new specification -- in fact, the final release only came out in November of last year. Some phone and handheld manufacturers are already supporting it, however. Nokia, for example, have announced support for MIDP 2.0 on their Series 60 devices quite recently, and I would be very surprised if the competition hangs back in the wake of the success of the MIDP 1.0 specification.
A lot of the content in this book can be usefully applied to the many MIDP 1.0 devices. There is in fact a MIDP 1.0 style guide, now available online, but I would still recommend this book for the wealth of extra content that it has.
The MIDP 2.0 Style Guide is a widget-by-widget guide to best-practice programming with the MIDP 2.0 API. The information contained within comes from established design principles, J2ME programming and implementation experience, and usability studies. Usability studies, especially, don't come cheap. Such labour-intensive research is well out of the reach of most individual programmers and small companies, so there is real value for money here.
The layout is very browseable, with most of the sixteen chapters each being a set of recommendations for a specific widget such as a text box or a gauge. The first three chapters (this includes the introduction) are more concerned with defining the goals of the book, the technology it relates to and the bones of a user-interface design process. For the most part, each chapter follows a standard format that is defined in the introduction.
Some of the later chapters cover topics that have less to do with user interface design, such as application installation and management, and the security API. The table of contents is comprehensive, listing not only chapters but two layers of headings within chapters -- useful in a reference book.
There are two target audiences here: J2ME developers and MIDP 2.0 implementors. For the former, it's an excellent resource. For the latter, I would say it was required reading. This is because it ends up defining what amounts to a contract between MIDP implementors and application developers.
For instance, from two successive recommendations on text boxes:
Application Developers
"Use [The NON_PREDICTIVE] modifier in a textbox that has a URL, EMAIL, NUMERIC, or DECIMAL constraint. Email addresses and domain names are not typical words, so turning off predictive text input ..."
And in the next paragraph,
MIDP Implementors
"If the application specifies the NON_PREDICTIVE modifier, allow users to enter one character at a time without any predictive input facilities."
Clearly the first recommendation is only meaningful if the second has been followed already. There are lot of these sort of co-dependent recommendations, covering areas such as default actions for abstract commands, list selection defaults, field constraints, etc.
There is still a lot of slop in the MIDP 2.0 specification. Its scope is, after all, fairly broad -- encompassing forms and form widgets, graphics canvases, game canvases and sprites, command design patterns, messaging and networking, security and application delivery APIs. Besides which, large chunks of the spec are optional, or can be implemented in more than one way. In part this is to preserve backward compatibility with MIDP 1.0, but it also means that your UDP-based streaming video application might work on only some the devices that support the same standard.
This looseness is only to be expected in such a young technology, but it means that books such as this may help to define the standard if people use the recommendations they provide. I would expect many of the recommendations in here to become part of future versions of the MIDP specification.
NOTES:
For more information on J2ME in general, and MIDP in particular, I also recommend Programming Wireless Devices with the Java 2 Platform, Micro
edition [2nd ed.] and, of course, there are all the specifications and tutorials at Sun's Java site.
The J2ME Wireless Toolkits versions 1.0.x and 2.0 are good starting points for development as well. Version 2.0 of the wireless toolkit supports MIDP 2.0.
You can purchase MIDP 2.0 Style Guide for the Java 2 Platform, Micro Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
So, if I RTFA correctly, the J2MEP MIDP2 which is CLDC w. API's gets a book which will tell you how to design good GUI's for PDA's ASAP?
I choose to remain celibate, like my father and his father before him.
The challenge of any style guide (whether it's for MIDP, SVG, HTML, or whatever) is trying to get developers to stick to writing content and not interfere with the user agent (the MIDP environment on a specific phone in this case) and its job of actually representing the UI in concrete form.
It's the same challenge UI framework designers have always had, and there's always l33t fanboyz who insist on implementing (generally very badly) their own widgets, just so they can have animated bass-relief shaded transparent buttons. Egomanical "I'll write all the pixels myself" content creators make the web a pain (flash, applets, mad DHTML), but on more varied and less forgiving mobile-device platforms this will simply result in stuff that just doesn't work.
We're already seeing "works only on Nokia 1234 or Ericsson Tfoo platforms" midlets, which are the MIDP equivalent of "works best with IE5" banners (which naturally should be subtitled "I'm an abject fucking moron who doesn't know how to write portable stuff, or doesn't care").
So this isn't just a style-guide. It's a weapon in the eternal struggle between good and stupid.
## W.Finlay McWalter ## http://www.mcwalter.org ##
The MIDP implementation on Java enabled phones seems to be a really bad choise for the moment. Although, Java was intended to make an application run an all (hardware compatible) devices, each phone manufacturer has created phone-specific classes, and in most cases this wasn't necessary. For example Nokia implements the FullCanvas (full screen), an extension to Canvas (the screen without the command area -- the lower side of the screen where commands can be mapped to the phone's "function keys") and Siemens has a totaly different implementation of the same concept. The problem is that there's no way to make an application fully compatible withouth re-writing the code. If all concepts were implemented in the base MIDP classes, this could have been avoided. Hopefully this problem will be solved soon :)
For the moment, the J2ME defides the "one application for all devices" concept, the base of the JAVA language.
Romanian Linux Help (#RoLinux, #LinuxRo -- undernet) http://marmotzel.net
I can't understand why Sun bothered with J2ME. Without even java.util implementation, there is practically no code reuse for J2SE programmers. In this case, why not a dedicated programming environment optimized for cell phones? Given the current J2ME "applications", a flash player would be far better at the job.