Java Reference
In-Depth Information
The Xlet shouldn't erase itself on pause; it may still be a visible part of the screen, just
not focused. Consequently, pausing this Xlet is trivial, because it doesn't do anything; the
pauseXlet method simply logs to the console the fact that the application manager trig-
gered a transition to the paused state.
Similarly, destroying this Xlet is also trivial; the AMS handles removing the frame
from the root container, which triggers the destruction of the UI, so all destruction does
is log the fact that the Xlet was destroyed. (There's no need for the Xlet to hide itself,
either, as the application manager does this for you.)
Understanding Xlet Dependencies
It's worth observing that this Xlet, while simple, actually has two key dependencies
beyond the CDC, and these dependencies are challenges you may face in designing your
own Xlet. First, and most obvious, you must remember that the Xlet isn't a CDC class; it's
a PBP class. What that means to you is that just because a device supports the Java ME
CDC, that doesn't necessarily mean that it provides the Xlet runtime, unless it imple-
ments the PBP. Fortunately, the vast majority of today's CDC devices do include at least
the PBP, so in practice this isn't likely to be a problem.
Second, the core CDC provides the Java class hierarchy for connected Java ME
devices, but it explicitly delegates the responsibility of determining how applications run
and what window toolkit is available to the various profiles atop the CDC. In addition to
providing the Xlet model, the PBP also provides a small subset of the Java AWT: compo-
nents and containers. Specifically, the PBP supports those AWT components that have no
peers in the operating system, letting application and framework developers implement
their own window toolkit. In fact, several platform vendors have done just this, and if
you're working with Java ME on some devices, you may not be using a standard window
toolkit like the AWT at all, but instead a different component framework provided by a
third-party vendor.
Fortunately, there are other options for many more capable devices. Several JSRs
detail specific user-interface packages for CDC-enabled devices, including Scalable
Vector Graphics (SVG), available in a mobile profile format suitable for CDC-enabled
devices. JSR 226 defines an interface that supports SVG via the javax.microedition.m2g
package, and JSR 287 defines the second iteration of that interface with support for
events and the SVG Document Object Model (DOM). In addition, on some devices,
three-dimensional graphics may be available via the Mobile 3D Graphics API that JSR
184 defines, or the OpenGL ES Common profile interfaces defined in JSR 239.
Significantly more useful for many Java developers is the AGUI that JSR 209 defines.
This defines a reasonable subset of both Java AWT and Swing user interfaces that facili-
tates porting Swing applications to Java ME devices. I discuss the AGUI in more detail in
Chapter 10.
 
Search WWH ::




Custom Search