Sound, Music, and Video: MMAPI - Beginning J2ME: From Novice to Professional - page 309

Figure 16-4 shows the results if you run MediaInformationMIDlet on the J2ME Wireless
Toolkit emulator (in the 2.0 beta 2 release). There are three things to understand about this list:

1. HTTP is a file transfer protocol, not a streaming media protocol. If you specify a media

file with HTTP, the whole file will be downloaded before playback begins. By contrast,
some devices may support real streaming protocols like RTP (see http://www.ietf.org/
rfc/rfc1889.txt ).

2. The “audio/x-tone-seq” content type is not really sampled audio; it's a special case for

tone sequences, which we'll describe soon.

3. The list includes some features and content types (video, MIDI, audio capture) from the

wireless toolkit's MMAPI implementation. If you want to see a bare-bones list of supported
content types and protocols, turn off the MMAPI support as described later, in the
section entitled “The Mobile Media API.”

Figure 16-4. MediaInformationMIDlet running on the toolkit's 2.0 beta2 emulator

To find out the content type of an existing Player , just call getContentType() .

Player Life Cycle
Because playing audio may use scarce resources on a MIDP device, and because sampled
audio files are relatively large, Player has a detailed life cycle that allows its behavior to be
closely controlled. The life cycle is described in terms of states , represented by constants in
the Player interface. The usual order of states in the Player 's life cycle is as follows:
A Player begins its life as UNREALIZED . This means that a Player implementation has been
created, but it hasn't tried to find the audio data it's supposed to render, and it hasn't tried to
acquire resources like the audio hardware.
A Player becomes REALIZED after it locates the media data, for example, by initiating a
network connection and sending headers.