Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Handhelds Programming Book Reviews Hardware IT Technology

MIDP 2.0 Style Guide for J2ME 38

Posted by timothy from the gee-look-at-all-the-letters dept.
nut writes "MIDP 2.0 is the latest version of the most common J2ME Profile. It comprises the Java Connected Limited Device Configuration (Usually referred to just as the CLDC) and a Java API for handheld wireless devices -- i.e. mobile phones, PDAs, etc. The MIDP 2.0 Style Guide for the Java 2 Platform, Micro Edition is one of a class of books that every application developer should read, and that not enough do, much like Nielsen's classic Designing Web Usability. It provides cheap access to knowledge that is expensive to obtain. The title is almost a misnomer; Call it a usability guide and give a better idea of its usefulness." Read on for the rest of nut's review.
MIDP 2.0 Style Guide for the Java 2 Platform, Micro Edition
author Cynthia Bloch, Annet Wagner
pages 260 pages approx.
publisher Addison Wesley
rating 8
reviewer nut
ISBN 0321198018
summary A comprehensive guide to usability in MIDP 2.0 programming.

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.
This discussion has been archived. No new comments can be posted.

MIDP 2.0 Style Guide for J2ME More

MIDP 2.0 Style Guide for J2ME

Comments Filter:

  • Let me get this straight... (Score:5, Funny)

    by Jhan ( 542783 ) on Monday September 01, 2003 @01:51PM (#6845281) Homepage
    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?

  • abstract commands - a Good Thing (tm) (Score:5, Insightful)

    by wfmcwalter ( 124904 ) on Monday September 01, 2003 @01:56PM (#6845305) Homepage
    MIDP UI's "abstract commands" (for which Wagner is largely responsible) are just about the cleverest part of any UI in current production (in mainstream systems). It's the best evidence yet that a declarative style of UI specification beats tired old procedural programming for >90% of the "real world" activities one is likely to do on a limited UI device (excepting games, naturally).

    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.

    • Re:abstract commands - a Good Thing (tm) (Score:1, Informative)

      by Anonymous Coward
      Uh, MIDP 2.0 won't solve any of the "works on Nokia 12232" stuff. The Handset manufacturers have loads of device-specific bugs in their KVMs. Also, the differing screen resolutions, bit-depths, font sizes, etc. make it nearly impossible for any graphically rich J2ME program to work on more than one device without making the JAR too large.

      Hell, Sun's own MIDP 2.0 emulator doesn't even properly emulate MIDP 2.0's GUI! (Layouts don't work)
    • 'We're already seeing "works only on Nokia 1234 or Ericsson Tfoo platforms" midlets'

      It's usually only games that are limited to specific brands - the reason being that plain ol' MIDP is just too limited for throwing graphics around. MIDP2.0 goes a long way to fix this but we'll never totally be rid of phone specific versions.
    • The problem is to find the right level of abstraction. In some places of MIDP 1.0, "abstraction" seems more like an excuse for under-specification. For example, the 1.0 "abstraction" did not cover anything that maps to "clickable" links. Thus, for implementing a browser, one would need to go to the graphics-only mode, which does not seem to be the right level of "abstraction" for that kind of application. I agree that pixel-positioning widgets is a bad thing, especially on limited devices. However, ignoring
  • MIDP1.0 will last about Ten years..its currently on 7 years

    MIPD2.0 will last aboput 15 years its currently on about 3..

    Sun WTKs if you have 1.4jdk you should use wtk2.0 for mIDP1.0 unless you want to mess aroudn setting compiler flags for 1.3 jdk binary compaitibilty..

    As the handsets using MIDP2.0 are not offically out in high numbers and since the spec is what actually the vendors implement..this book is more for maybe hardware implementors rather than appplications developers..

    just your humble J2ME de

    • Re:Corrections (Score:3, Informative)

      by LiamQ ( 110676 )

      Sun WTKs if you have 1.4jdk you should use wtk2.0 for mIDP1.0 unless you want to mess aroudn setting compiler flags for 1.3 jdk binary compaitibilty..

      Sun's J2ME Wireless Toolkit has worked out of the box with JDK 1.4 for ages--since J2MEWTK 1.0.3 at least.

      If you're developing for today's phones (all MIDP 1.0), you should use J2MEWTK 1.0.4_01 rather than J2MEWTK 2.0 (which is for MIDP 2.0).

      • j2mewtk 2.0 works excellently for developing nowadays(midp1.0) phones, you just must remember to set the microedition profile to midp1.0 when you create a new project and not to use midp2.0 classes(obviously, i'm not sure though if they would even compile when you have midp1.0 device selected, the emulators for midp1.0 phones for wtk1 work with wtk2).

        there's another reason to use it though, the obfuscator/cruncher in it doesn't choke on (for example) nokias extensions.

  • MIDP ... bad choice ? (Score:5, Informative)

    by marmotzel ( 523645 ) <marmotzel_org&yahoo,com> on Monday September 01, 2003 @02:24PM (#6845390)
    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.

    • Re:MIDP ... bad choice ? (Score:4, Informative)

      by LiamQ ( 110676 ) on Monday September 01, 2003 @02:42PM (#6845465)
      If you stick to standard MIDP 1.0 and take care to dance around device-specific bugs, it's possible to have an application that works on a wide variety of devices. In my previous job, I wrote a Web browser [reqwireless.com] that works on about 70 different phones from 10 different manufacturers--all running the same JAR.
      • Yes, it can be done, but you have to make (too) many sacrifices. For example, the Reqwireless WebBrowser doesn't use the FullCanvas so it uses a smaller display area (options, back ... keys could have been hidden and displayed on keypress or other key combination). Most Java enabled phones (and, usualy, phone = small display) have small displays and this is really a HUGE sacrifice in this case.

  • Mostly useless (Score:4, Insightful)

    by iamacat ( 583406 ) on Monday September 01, 2003 @02:36PM (#6845434)
    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.

    • Re:Mostly useless (Score:5, Interesting)

      by LiamQ ( 110676 ) on Monday September 01, 2003 @02:49PM (#6845489)

      J2ME is a dedicated programming environment optimized for cell phones. If it included the full selection of java.util classes, it would be too large to fit on a lot of cell phones.

      Do you really expect a lot of J2SE code reuse when you're limited to a JAR size of about 64K? (The limit varies depending on the device, but applications larger than 64K won't work on many MIDP devices. To work on all MIDP devices, you need to be under 30K.)

    • Yes. By crippling the runtime, all you get are crippled apps.

      If you look at the phones in a UK phone vendor, say
      [virginmobile.com]
      Virgin Mobile, you will see that java is not sold directly, instead 'downloadable games'. And they list it second, after 'downloadable ringtones'.

      So there we have it, the cross platform language intended to replace the windows API is, in its sole 'post-PC' client configuration, used to sell phones, after downloadable ringtones.

      Maybe the next iteration will improve, but the 1.0 version was so
  • I have the Nokia 3650, and while I am not a programmer, from a strictly end-user perspective, I prefer Symbian to the MIDP applications. Symbian just seems so much more solid, and it 'looks' more like the rest of the apps on the phone. MIDP works fine enough, I love MIDP-Man, which is an exact replica of Pac-Man. But I have purchased no MIDP apps (fortunately most are freeware), and I have purchased several Symbian apps.

    Also you can tell the MIDP stuff is 'different'. Apps do not appear in the main menu of

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close