Using the MIDP User Interface Classes
Regardless of whether an application makes use of the high or low-level APIs, there are some core classes that are always needed. One of these classes is Display. Display allows access to a device's display mechanism. The following code demonstrates how to gain access to the display.

Display theDisplay = Display.getDisplay(myMidlet);

The call to getDisplay() requires a reference to the current MIDlet. An instance of the device display context is returned. An application uses the Display instance to show a screen on the device:

theDisplay.setCurrent(myDisplay);

or to query the display instance to find out what screen is currently shown.

Displayable currentScreen = theDisplay.getCurrent();

Another class that makes up the MIDP user interface framework is Displayable. Displayable is an abstract class that forms the basis for what can set as the current display. It is in the subclasses of Displayable that high-level and low-level APIs diverge. Figure 1 illustrates this divergence.

Figure 1. The Top-most Part of the javax.microedition.lcdui Class Hierarchy: The diagram shows the split between the high-level and low-level APIs.

The Screen Class
As shown in Figure 1, the Screen class is where the high-level UI begins. Because Screen is a subclass of Displayable, instances can be passed to Display.setCurrent(). When this occurs, the instance becomes the currently visible display and consumes the entire display. There are four different types of Screens: Form, List, TextBox, and Alert. Each one of these is discussed in detail in this article, beginning with TextBox.

TextBox
TextBox is a type of Screen that is used for text entry. A TextBox can be configured to use Input Constraints in order to provide some built-in validation and formatting of the data associated with the control. For example, setting the constraints of a TextBox to TextBox.NUMERIC tells the TextBox to only accept numbers in the field. An input constraint such as NUMERIC also will prevent the keypad from cycling through the non-numeric characters.

Using the PHONENUMBER constraint tells MIDP that the data is a phone number. If the device supports making phone calls, using this constraint can provide the ability to initiate a phone call when the field has focus.

Table 1 is a list of constraints that apply to TextBox:

Table 1. A TextBox can be configured to validate user input based on any of these built-in constraints.

Constraint	Description
ANY	alphanumeric
NUMERIC	numbers only
EMAILADDR	email address format
PHONENUMBER	phone number format
URL	URL format
DECIMAL	positive and negative real numbers

Modifier flags can be added in conjunction with the input constraints using the bitwise "|" operator (OR). For example ANY | PASSWORD would allow alphanumeric entry into a TextBox and the input characters would be masked with a character such as an asterisk (*). Table 2 lists available modifier flags.

Table 2. These modifier flags can be used with the constraints in Table 1 to improve data validation and user experience.

Modifier	Description
PASSWORD	Masks input with a character such as an asterisk (*).
UNEDITABLE	Makes the TextField or TextBox read only.
SENSITIVE	Used to let the underlying implementation know that the data being entered is sensitive and should not be added to predictive databases for quick entry, etc. A credit card number is an example of such data.
NON_PREDICTIVE	Used to let the underlying implementation know that predictive prompting to assist user input should not be used. This is helpful in cases where the data is unlikely to exist in a predictive text database on a device.
INITIAL_CAPS_WORD	Indicates that the first letter of each word should be capitalized.
INITIAL_CAPS_SENTENCE	Indicates that the first letter of the first word of each sentence should be capitalized.

Figure 2 shows an example of a TextBox as the current display.

Figure 2. Example of a TextBox as the Current Display: Note that the label is set to "TextBox Example:"