Motorola Key Codes
Posted by Brian on Thursday March 31st 2005, 10:46 am
Filed under: Development, Mobile

Thu Mar 24 07:27:55 EST 2005
Here is yet another example of how immature the mobile space is, and unfortunately another example of how carriers and device manufacturers have made decisions for reasons that simultaneously baffle and frustrate the developers who will be making the very mobile applications that will drive the sales of devices and data services. I can’t leave the J2ME standards body out of this equation either, as I feel that they also have a role in making standards that insulate developers from things like this.

Somewhere after the V600, Motorola decided to almost completely change the numeric keycodes that its handsets generate for keypress events in J2ME. Here are the keycodes generated by Motorola J2ME handsets prior to and including the v600, versus the keycodes for all handsets produced after the v600:

Physical Key Old keyCode Game Action New keyCode
Up 1 lcdui.Canvas.UP -1
Down 6 lcdui.Canvas.DOWN -6

Left 2 lcdui.Canvas.LEFT -2
Right 5 lcdui.Canvas.RIGHT -5
Center Select 20 lcdui.Canvas.FIRE -20
Softkey Left 21 -21

Softkey Right 22 -22
Softkey Middle 23 -23
Send (Green) -10 -10

At first glance, it may seem fairly insignificant that they simply changed all the signs from positive to negative but this creates several significant problems for developers who are trying to realize the (admittedly near-impossible) promise of write-once-run-anywhere code.

First of all, it means that code written for previous generations of Motorola handsets will no longer function properly on their new handsets. This requires developers to make changes to their code and re-test on both new and old handsets just to ensure compatibility with Motorola devices.

Second, and worse yet, Motorola’s new keycodes actually conflict with the keycodes used by other device manufacturers. For example, here is a subset of the current keycodes used by Nokia Series 40 and 60 handsets:

Key Key code (decimal) Key name example

Scroll up -1 Up or up arrow symbol
Scroll down -2 Down or down arrow symbol
Scroll left -3 Left or left arrow symbol
Scroll right -4 Right or right arrow symbol

Notice anything alarming? The new keycodes chosen by Motorola actually conflict with those used by Nokia Series 40 and 60 devices! In the previous example, it was still actually possible to write a single switch statement that would correctly handle both old and new Motorola keycodes (via absolute value or simply hardcoding both sets of keycodes into the switch statement). However, given that the keycodes from Motorola and Nokia now conflict, it is impossible to write a single switch statement. As a developer, you must now build into your application additional knowledge about the device on which it will run, or build a mechanism that allows your application to determine this at runtime and use the appropriate keycode set. In my opinion, this is an incredibly irresponsible choice by Motorola, and makes a statement about their attitude toward developers, but also points to weaknesses in the J2ME standard.

Third, building on the two points above, the lax J2ME standard coupled with decisions like this made by carriers and device manufacturers further erode any hope of write-once-run-anywhere, and force developers to spend time and resources to engineer solutions that will insulate them from seemingly arbitrary changes such as this. Instead of simply coding to a J2ME-defined set of constants, developers have to concoct additions to their build scripts, or create inheritance abstractions to deal with the would-be simple problem of descriminating user key presses.

Bookmark and Share

No Comments so far
Leave a comment



Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

(required)

(required)