Java Reference
In-Depth Information
■
Note
Wondering why the
List l
is declared as
final
in Listing 5-4? It's because the variable
l
is
referenced in the closure created when you declare the anonymous
CommandListener
subclass. The
local class doesn't really access
l
, but instead a private copy of
l
. If
l
were to change after it was
declared but before the platform invokes the closure's
commandAction
method, the two notions of
l
would be out of sync with each other.
Working with the Canvas and Custom Items
Despite the flexibility of the
Screen
and
Item
class hierarchy, there are some things you
just can't do with these classes. One notable example, of course, is creating a game; more-
over, nearly any truly bespoke interface is out of reach, because of the high level of
abstraction provided by these classes.
There is another way, however. The MIDP provides the
Canvas
, which is a base class
for writing applications that need to handle low-level events and perform low-level
drawing. Instances of
Canvas
or its subclass
GameCanvas
encapsulate event and drawing
behavior by passing events to the instance and permitting the instance to draw using the
Graphics
object passed to the instance's
paint
method. These classes bring you as close as
you can come to the bare hardware of a MIDP platform.
Sometimes, though, you may want to take advantage of all the abstractions that the
Screen
and
Item
classes provide, yet you may need a custom
Item
to present particular
data. You can do this using a
CustomItem
subclass, which lets you implement a UI widget
that works within the framework established by the
Screen
and
Item
subclasses.
■
Caution
Don't venture into Java ME programming thinking the
Canvas
class is like the
Canvas
class in
Java SE! They are two very different beasts.
Controlling Drawing Behavior with a Custom Canvas
Subclassing the
Canvas
class gives you the opportunity to manage events and drawing
behavior at the lowest level. An implementation of
Canvas
must be able to do the
following:
