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.
 
Search WWH ::




Custom Search