Java Reference
In-Depth Information
Personally, I find it a little creepy that you ask a
Control
for an object to place on the
display, but that's how this works: the
VideoControl
instance's
initDisplayMode
takes a flag
and an
Object
as an argument, and returns a visible component for the display. You pass
the
VideoControl.USE_GUI_PRIMITIVE
value to indicate that the instance should return an
instance of an object in the GUI hierarchy for the device. This example runs on the MIDP
platform atop the CLDC, so the object that
initDisplayMode
returns is actually a subclass
of
Item
. Platforms that support the AWT (such as some CDC platforms) return an
instance of an object that subclasses
Component
.
■
Note
On MIDP devices, if you want to render the video full-screen, you can pass the
VideoControl.
USE_DIRECT_VIDEO
value to
initDisplayMode
to instruct it to draw the video directly to a
Canvas
object.
Pass a reference to the desired destination
Canvas
object as the second argument. Set the
Canvas
you
passed to
initDisplayMode
as the current
Displayable
item using
Display.getDisplay.setCurrent
,
place the
Player
instance in the started state, and voilà!
As I note in the previous section,
Player
objects are best used in their own thread.
Much of what they do is asynchronous and typically spans the entire stack of hardware
and software on a device. It's important for you to have a way to get information about
what the
Player
instance is doing. A simple way to do this is to use its
getState
method,
which returns the current state that the
Player
instance is in. This is fine for coarse-
grained control, especially if you manage an instance from different threads, but to
really see what's going on, you can add a listener to the
Player
instance using its
addPlayerListener
method. The object you pass to
addPlayerListener
must implement
the
PlayerListener
interface, which specifies the
playerUpdate
method that the
Player
instance invokes with information about media rendering. The event system defined
by the MMAPI is extensible; the
PlayerListener
interface defines a number of events,
which are shown in Table 16-4. The
PlayerListener
interface also lets individual
Player
objects pass proprietary events as values in a
String
. Your application might use some
of these to provide fine-grained updates to its user interface—for example, to indicate
that the device is buffering a stream.
Table 16-4.
Events Provided by Player Objects
Event
Purpose
PlayerListener.BUFFERING_STARTED
The
Player
instance enters a buffering mode.
PlayerListener.BUFFERING_STOPPED
The
Player
instance leaves the buffering mode.
PlayerListener.CLOSED
The
Player
instance is closed.
PlayerListener.DEVICE_AVAILABLE
The exclusive device seized by the system has been
returned to the
Player
instance.