Java Reference
In-Depth Information
• Determine whether the screen supports color or grayscale
• Determine the number of colors and alpha levels supported by the display
• Get the border style and user-selectable color for the foreground and background
• Flash the display backlight
• Obtain the best image bounds for an
Alert
• Get the currently shown
Displayable
• Set the currently shown
Displayable
• Vibrate the device using the vibration motor
What exactly is the
Displayable
interface for? The hierarchy in Figure 5-2 shows the
relationship between the
Display
, what it can display (
Displayable
classes), and
Item
classes, which
Displayable
s contain to make up complex user interfaces.
As you can see in Figure 5-2, the
Display
must have a corresponding
Displayable
object to display to the user.
Displayable
objects come in several flavors. The
Canvas
class
provides the lowest level of access to graphics, permitting you to intercept raw events and
draw directly to the screen. Its subclass,
GameCanvas
, provides some simple abstractions to
facilitate porting applications to a variety of devices. For a more high-level approach to
the user-interface layout, there is the
Screen
subclass and its subclasses
Form
,
Alert
,
TextBox
, and
List
. The last three are high-level abstractions, handling all of the layout and
event handling, while
Form
lets you group one or more
Item
objects—things such as text
and date fields, for example.
If you're familiar with either Java AWT or Swing, it's important to realize that the user-
interface model for MIDlets is very different. Two key differences affect how you design
your user interface from the outset. First, you have no real control over the layout of your
application. Unlike the rich Java UI frameworks provided by AWT and Swing, the layout
of your user interface is completely controlled by the
Screen
class and its subclasses,
which typically have a simplistic layout policy. Second, MIDlets have no implementation
of the model-view-controller (MVC) paradigm, so if you're used to using MVC, you will
need to implement it yourself.
The architects of the MIDP imposed these limitations to permit MIDlets to run on
the widest possible variety of devices and to ease application porting between devices
without requiring a heavyweight all-Java user interface such as that provided by Swing.
Unfortunately, these limitations do come with a downside: it's nearly impossible to create
a truly bespoke user interface. Different devices generally present the user with differing
user interfaces; these changes may be small or may grossly affect the appearance of your
application. If you're looking to create a UI with a very specific control appearance and
placement, you'll need to code that from the ground up using the
Canvas
or
GameCanvas
classes. I discuss that later in this chapter.
