Java Reference
In-Depth Information
developer. Please refer to the SDK documentation for more details on
obtaining media using the player creation methods of the Manager class.
2.9.3 Playing Media Content
Because of the complexity of what a Player does, there are necessarily
several stages (or states) it has to go through before it can play (see
Figure 2.20). As we have just seen, the first stage is the creation of a
Player object via the Manager factory class. This involves the creation
of a DataSource object, which provides a standard interface to the
media content. Unless you are working with a custom DataSource ,
the creation is done on your behalf. It's worth noticing that creating the
Player object does not initialize the data transfer, which begins at the
next stage.
Figure 2.20 Lifecycle of a Player object
On creation, the Player is in the UNREALIZED state. Calling the
realize() method causes the Player to initiate data transfer, for
example, communicating with a server or a file system. Peer classes to
marshal the data on the native side are typically instantiated at this point.
When this method returns, the player is in the REALIZED state. Calling
prefetch() causes the Player to acquire the scarce and exclusive
resources it needs to play the media, such as access to the phone's
audio device. It may have to wait for another application to release these
resources before it can move to the PREFETCHED state. Once in this
state, the Player is ready to start. A call to its start() method initiates
playing and moves it on to the STARTED state. In order to interrogate the
state of the Player ,the getState() method of the Player class is
In many cases, of course, clients of MMAPI will not be interested in
the fine distinctions of which resources are acquired by which methods.
The good news is that you are free to ignore them if you wish: a call to
start() on a Player in any state other than CLOSED results in any
Search WWH ::

Custom Search