Browse DevX
Sign up for e-mail newsletters from DevX


Exploring the J2ME Mobile Media APIs : Page 3

The Mobile Media APIs provide a rich and extensible framework for playing and capturing a wide variety of media on mobile devices. Find out how to add sizzle to your application using these features.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Adding Control
Up to this point I've focused mostly on the Player and Manager. However, for each type of media there may be capabilities for controlling the flow and behavior of how the content is processed. To provide more content-specific behaviors players can make use of the Control interface. For example, if the media is a video, there may be a need to control the size of the display. Or, if an application is capturing audio there is a need to start recording and pipe the input to memory or a RecordStore. Control instances can be obtained by making a call to the factor method Player.getControl() and passing in a control type. The control type parameter is the class name of the control to be created. If the control type parameter is not a fully qualified class name, the package javax.microedition.medial.control is assumed.

There are two standard controls defined as part of the MIDP 2.0 Mobile Media subset: ToneControl, which used to define a sequence of tones, and VolumeControl, which can be used to control the volume as the media is processed. Within the Mobile Media APIs, many more Control interfaces are defined, such as VideoControl, TempoControl, RecordControl, and MIDIControl just to name a few. Implementers can also provide additional controls as needed.

Playing More Complex Media
Playing audio can be fun, but it's pretty basic. So far, all the code examples shown are supported within the MIDP 2.0 specification. Now I'll show you something only the Mobile Media API specification can provide. The next example demonstrates how to play video on a device. For the most part, showing video is similar to audio playback. The primary difference is that you need something to display the video on. This is where the Control interface comes into play.

String url = "http://java.sun.com /"+ "products/java-media/mma/media/test-mpeg.mpg"; Player p = Manager.createPlayer(url); p.realize();//must do this before getting the control //get the video controller VideoControl video = (VideoControl) p.getControl("VideoControl"); //get a GUI to display the video Item videoItem = (Item)video.initDisplayMode( VideoControl.USE_GUI_PRIMITIVE, null); //append the GUI to a form videoForm.append(videoItem); //start the video p.start();

This code retrieves an MPG video using HTTP, obtains an Item from the VideoControl that can be place onto a Form, and runs the video.

The Mobile Media APIs provide a rich and extensible framework for playing and capturing media content on mobile devices. I am only able to skim the surface in this article; however, there are interfaces and protocols defined for doing a lot of interesting things in your applications such as real-time streaming of Internet radio content, streaming other RTP (Real-time Transport Protocol) content, capturing audio, and taking pictures. However, an application can only do these things if the underlying content types and protocols are supported. To find out what is supported on a device, the Mobile Media APIs provide some query mechanisms to help developers discover capabilities and limitations of a device.

Knowing What Is Available
Let's face it: While the flexibility and power provided by the Mobile Media API is exciting, this excitement is tempered by the realization that support for Mobile Media features is likely to vary from one device to another. Even applications that support media only within the MIDP 2.0 specification must be able to adapt to the absence of certain media features and capabilities. For example, while audio playback may be supported, an application cannot assume that a device supports WAV, MP3, and AU formats. The specification does not require any specific audio formats. Furthermore, an application cannot assume that just because WAV format is supported that HTTP can be used to stream or download the content.

To address these problems applications can gain insight to the supported capabilities of a device by querying a couple of methods on the Manager class:

  • getSupportedContentTypes(), which accepts a protocol identifier, such as "http" and returns a list of content types supported by this protocol.
  • getSupportedProtocols(), which accepts a content type identifier, such as "audio/mpeg" and returns a list of protocols (such as http) supporting this content type.
In addition to the content and protocol support, there are other multimedia landmines to avoid. For example, the methods above may indicate WAV format is supported through HTTP, but can the device play 16-bit sound samples recorded at 44100 Hz? To gain insight to some of these details a few calls to System.getProperty() may be necessary. Table 5 lists some of the properties available.

Table 5. Mobile Media API system properties that can be accessed by calling System.getProperty().

System Property



Returns true or false. True indicates that at least two tones can simultaneously be played with Manager.playtone() and at least two players can play audio simultaneously.


Returns true or false indicating if audio capture is supported by the device.


Returns true or false indicating if video capture is supported by the device.


Returns true or false indicating if audio recording is supported.


Returns the details of audio formats supported such as bits, channels, rates, endian, etc.


Returns the details of video formats supported.


Returns the details of video snapshot formats supported when VideoControl.getSnapshot() is called.

Device Support is Developers' Challenge
The Mobile Media API provides a rich and extensible framework for incorporating media into J2ME applications. While there are a number of verification steps an application will want to perform in order to ensure a device can handle specific media content, the Mobile Media API does a good job of providing developers with enough information to make informed decisions regarding a device's capabilities. Fortunately, the competitive mobile device market that currently exists puts the odds in the developer's favor that most of the popular media types will be supported.

David Hemphill is the Lead Architect at Gearworks, a Minn.-based company that specializes in wireless workforce automation. He is also the co-author of "Java 2 Micro Edition" (Manning). David is also a member of the Sun-Certified J2ME Exam expert group.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date