Programming a Custom User Interface - Beginning J2ME: From Novice to Professional - page 244

The following methods are called whenever the user presses and releases a key:
protected void keyPressed(int keyCode)
protected void keyReleased(int keyCode)
The key code that is passed to these methods will most likely be one of the constants
defined in Graphics , from KEY_NUM0 through KEY_NUM9 and including KEY_STAR and KEY_POUND .
Devices may have more keys than this, which will be returned as device-specific key codes.
Assuming there's an obvious mapping between the key and some Unicode character, the rule
of thumb is that a key should have a code equal to its Unicode character value. Keys that don't
have a Unicode mapping should use negative values. This means that, given a positive key code,
you can find out the corresponding Unicode character by casting the int key code to char .
Note that key presses and key releases are separate events, which allows you considerable
flexibility in how you design your user interface. The time between the press and the release
could determine how high a game character jumps or how powerful a laser blast will be.
Depending on the device and the MIDP implementation, a key that is held down may
spit out repeated key events. You can find out if repeated keys are supported by calling
hasRepeatEvents() . If repeated key events are supported, the keyRepeated() method will be
called with these events.
Finally, you can find a text description of a given key code by calling getKeyName() .
The Game API offers a mechanism to bypass the key event callback methods. You can poll
the state of the device's keys directly using a method in GameCanvas . For more information, see
the following chapter.
Game Actions
Key codes may be useful in certain situations, but they're fairly specific to a device. MIDP offers
a simple abstraction called a game action that makes it easier to map user key events to events
that will be useful for games and other applications with specialized user interfaces.
The concept is simple: supply a key code to getGameAction() , and you'll receive a game
action—one of the following values: UP , DOWN , LEFT , RIGHT , FIRE , GAME_A , GAME_B , GAME_C , or GAME_D .
Basically game actions are a way to map the physical keys on a device to a set of video game
buttons such as you might find on game platforms like Sega Genesis or Nintendo Game Boy.
To understand how this maps to a physical device, think about how you might map the UP ,
DOWN , LEFT , and RIGHT game actions to keys. On the WTK emulator, there are navigation keys
that have an obvious relationship to these game actions. Think about a simpler phone, however,
one that has only a numeric keypad. In this case, you might want to map UP to the 2 key, DOWN to
the 8 key, LEFT to the 4 key, and RIGHT to the 6 key.
Using game actions saves you from having to make these decisions yourself; the MIDP
implementation simply provides a reasonable mapping for the device. To find the game action
for a key code, pass the key code to getGameAction() . You can also find the key code for a game
action by calling getKeyCode().
The following example listens for key presses in the keyPressed() method. It converts the
key code to a game action and displays the game action on the screen.