Creating a User Interface - Beginning J2ME: From Novice to Professional - page 61

screen from seeing your secret password. For every character you enter, the password field
shows an asterisk or some other symbol. As you type your secret password, all that shows up on
the screen is a line of asterisks. On mobile phones and other small devices, this is less of a concern
because the screens are smaller and much more difficult to read than a typical desktop monitor.
Furthermore, the difficulty of entering data on a small device means that it will be hard to
correctly enter passwords if you are typing blind. Mobile phones, for example, typically require
you to press keys several times to enter a single letter. On Sun's toolkit emulator, pressing the 7 key
twice enters the letter “Q.” On a real device, you would have to enter a password “gandalf” with
the following sequence of key presses: 4, 2, 6, 6, 3, 2, 5, 5, 5, 3, 3, 3. Without visual feedback, it
would be extremely easy to make a mistake when entering a password. (“Did I press the 5 key
two times or three times?”) The J2ME Wireless Toolkit emulator shows the current character,
but previously typed characters are shown as asterisks. Good passwords typically have mixed
case, numbers, and possibly punctuation; these would be hard to enter correctly.
Password fields (whether or not they use the PASSWORD flag) should be protected with the
SENSITIVE flag so that the password doesn't show up in any system dictionaries or pop up
unexpectedly when the user is entering other text.
A method in the TextBox class called setInitialInputMode(String characterSubset) is used to
suggest to the implementation what input mode would be best suited to the expected text. You can
only suggest the input mode, and you have no way of knowing whether the implementation has
honored the request. The string passed to the method can be one of the constants from the J2SE
java.lang.Character.UnicodeBlock class, prepended with “UCB_”. For example, you might pass
“UCB_BASIC_LATIN” or “UCB_KATAKANA” to this method. You can also use input subsets
defined by java.awt.im.InputSubset by prepending them with “IS_”. For example, “IS_LATIN”
or “IS_KANJI” would be valid. Finally, the character subsets “MIDP_UPPERCASE_LATIN” and
“MIDP_LOWERCASE_LATIN” are also defined.
The input mode is complementary to the text constraints and flags. You might specify ANY
for the constraints, then call setInitialInputMode("MIDP_LOWERCASE_LATIN") to request that
the implementation begin by allowing lowercase input. This doesn't prevent the user from
changing the input mode, it just starts things off on the right foot.
Using Alerts
An alert is an informative message shown to the user. In the MIDP universe, there are two
flavors of alert:
•A timed alert is shown for a certain amount of time, typically just a few seconds. It displays
an informative message that does not need to be acknowledged, like “Your transaction
is complete,” or “I can't do that right now, Dave.”
•A modal alert stays up until the user dismisses it. Modal alerts are useful when you need
to offer the user a choice of actions. You might display a message like “Are you ready to
book these tickets?” and offer Yes and No commands as options.
MIDP alerts can have an associated icon, like a stop sign or question mark. Alerts may even
have an associated sound, although this depends on the implementation. MIDP alerts are very
much the same concept as modal dialog boxes in windowing systems like MacOS and Windows.
Figure 5-6 shows a typical Alert .