Java Mobile Media API

The Mobile Media API (MMAPI) is an API specification for the Java ME platform CDC and CLDC devices such as mobile phones. Depending on how it is implemented, the APIs allow applications to play and record sounds and video, and to capture still images. MMAPI was developed under the Java Community Process as JSR 135.

Regardless of the protocol or media type involved, the Player moves through the same discrete states during its lifecycle. These states are listed in table below
+ Lifecycle states of a Player instance State Description Unrealized Initial state when a Player is created. In this state the player does not have enough information to acquire the necessary resources to process the media. Realized The Player moves into the Realized state once it has obtained the necessary information to acquire the resources. In this state it is likely that most of the resources have already been acquired to function. However, some resources may not have been acquired at this point, especially if there are system dependencies involved such as with an audio or video driver where exclusive access must be obtained. Prefetched The Player moves into the Prefetched state once all resources have been acquired, including scarce and system dependent resources. Once in the Prefetched state, the Player has everything necessary to perform its tasks. Started A Player in the Started state indicates that the content associated with the Player is being processed. Closed A Player moves to the Closed state at the end of its lifecycle. A Player in the Closed state must not be used again.

As with most Java ME specifications, implementations differ despite the best efforts of the specification authors to ensure consistency. Two obvious areas for differences are in the controls supported, and in the acceptable URI types in the first place. More obscure areas are whether mixing is supported; many games would like to play a MIDI music track and layer PCM sound effects on top. Another source of extreme variance is in performance. For example, if an HTTP clip is requested, at what point does the clip get downloaded? The specification recognises this by providing two Player methods that can be called in advance of actually playing: realize and prefetch. Depending on the implementation, these may do some of the work of getting the clip into a playable state, thus making it quicker to actually play the clip when it is needed. Some implementations are sophisticated enough to actually stream a clip on request whilst it is being played. Symbian OS contains a very complete implementation of JSR 135, but even this is highly dependent on the underlying multimedia capabilities of the device, and some device manufacturers may choose not to expose the more obscure parts of Java ME such as recording. Implementation consistency is ensured by forcing all implementations to pass the Java Technology Compatibility Kit (TCK). This ensures that each supported URI schema, MIME type and Control is tested, but does not test every permutation of these optional parts.