Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 32
Текст из файла (страница 32)
Note that these APIs do not themselves form partof the MIDP 2.0 specification, but have their own specifications derivedfrom a Java Specification Request (JSR) presided over by an expert group.3.4.1Mobile Media APIAs discussed in Chapter 2, one of the most commonly-cited limitationsof MIDP 1.0 since it was launched in 2000 has been the level of supportit provides for multimedia functionality. ‘‘Out of the box’’ there is noaudio capability and limited graphics support only through the Canvas156MIDP 2.0 AND THE JTWIprimitive.
This was reasonable for the mainly monochrome devices withmore limited capabilities at which MIDP was targeted, such as thepioneering Motorola i3000 phone and RIM BlackBerry 950 and 957wireless handhelds. Given these limitations, it is perhaps remarkable howmuch media-rich content has yet made its way onto the first generationof MIDP 1.0-enabled mobile phones.However, Symbian OS devices like the Psion netBook and the Nokia9210 were already providing a PersonalJava Application Environmentwith AWT graphics, audio playback support and color screens.
MIDP 1.0was not sufficiently attractive to present itself as an alternative Java runtimeenvironment for Symbian OS phones. It is interesting to note here that noSymbian OS phone has shipped without the MIDP 1.0 Java functionalitybeing complemented either directly by additional multimedia functionality or else by inclusion of a PersonalJava Application Environment. Eventhe Nokia 7650, which provided one of the least feature-rich Java runtimeenvironments among Symbian OS phones, extended the basic MIDP 1.0specification with custom Nokia extension classes. A sound packageallowed playing of several audio formats and a UI package provided APIsupport for such multimedia enhancements as:• full-screen display• vibrator activation• a number of graphics utilities.And when the Nokia 3650 was released a few months later, the mainenhancement to the programming environment it provided was in termsof MIDP multimedia functionality.The limitations of MIDP have been systematically addressed over thelast few years through the Java Community Process.
From this haveemerged a number of extensions that have been made to, or madeavailable to, MIDP runtimes.We note first in this regard the extensions made directly to MIDP 1.0in its upgrade to MIDP 2.0, which have been discussed in Chapter 2 andSection 3.3. This upgrade included, for the first time, an audio API underthe javax.microedition.media package. However, in recognitionof the need for a J2ME-based framework supporting wider multimediacapabilities, such as tone generation, photo capture (given the ubiquityof camera phones) and video playback/capture, a Java SpecificationRequest was initiated by Nokia under the Java Community Process.
Thiswas JSR 135, the Mobile Media API, which is the main subject of thepresent section. We shall follow here the convention introduced in thespecification of referring to it as ‘‘MMAPI’’.Given the wide scope that is encompassed by the concept of ‘‘multimedia’’, both in terms of the kind of content (e.g. video and audio) andOPTIONAL J2ME APIS IN THE JTWI157of its encoding (e.g.
JPEG and GIF), the authors of the multimedia APIrecognized a need for flexibility. As a result, MMAPI is highly modular;also, where a module is supported in an implementation there is a greatdegree of latitude as to which protocols or file formats are supported.There are essentially three media types which can be handled withinthe framework. These are:• audio• video• generated tones.All of these or any non-zero subset may be supported in a particularMMAPI implementation, although it is unlikely that generated toneswould be omitted given their mandatory status in MIDP 2.0.
There isfurther modularity: three tasks can be performed in relation to audioand video:• playing – stored video or audio content is recovered from a file at aspecified URI (or perhaps stored locally) and displayed onscreen orsent to a speaker• capturing – a video or audio stream is obtained directly from hardware(camera or microphone) associated with the device• recording – video or audio content which is being played or capturedis sent to a specified URI or else cached as a local OutputStreamand is thus made available for ‘‘re-playing’’.Because of the nature of tone generation, playing is the only task ofrelevance.
Again, implementations are not required to support all threetasks, although clearly it is not possible to support recording withoutsupporting either playing or capturing. Further, in the context of a mobilephone, there is little point in supporting capture without the ability toplay. So the practical options for audio or video are:• only playing is supported• playing and capturing are supported, but not recording• playing and recording are supported, but not capturing• all three are supported.As we shall see, Symbian OS phones typically provide the secondoption for video (recording not possible) and the fourth for audio (everything supported).
There is further optionality in terms of supported formats158MIDP 2.0 AND THE JTWIand the ability to manipulate data streams or playback. We will return tothis below.3.4.1.1 MMAPI ArchitectureAt the heart of MMAPI is the concept of a media player. Players areobtained from a factory or manager which also serves to associate themwith a particular media stream. While the player allows basic start/stopcapability for the playback, fine-grained manipulation is achieved throughvarious kinds of control, which are typically obtained from a player.Another task performed by controls is the recording of incoming mediafor later playback. Also of interest is the concept of a player listener.This allows you to track conveniently on multiple threads the progress ofplayers being initialized, started or stopped. Since these events involveaccessing (shared) hardware resources, they can take some time to complete, so you will typically not want your program to block while waiting.The following classes or interfaces embody the above basic concepts:• Player• Manager• Control• PlayerListener.These are the fundamental elements of the core package javax.microedition.media.
In fact, of these only Manager is a concrete class; theothers are all interfaces. The Control interface exists merely as a markerfor the set of (more concrete) subinterfaces which are defined in the relatedpackage javax.microedition.media.control. The functionalityprovided by the latter is so diverse that nothing is in common, and theControl interface, remarkably, defines no methods!The package javax.microedition.media.protocol is provided by MMAPI for users who wish to define new protocols forobtaining/downloading media content.
This package provides data sourcefunctionality, introducing a common interface for handling content delivered by whatever protocol. Most MMAPI users will not have to workdirectly with data sources. Rather, DataSource objects will be marshaled on their behalf as a by-product of creating a player. But MMAPIdoes allow you the flexibility to define your own protocols for downloading/obtaining the media content to be played.
This involves definingconcrete implementations of the abstract DataSource class. As this is aspecialist topic beyond the scope of this chapter, we shall not say anythingfurther. The MMAPI specification document contains further details.OPTIONAL J2ME APIS IN THE JTWI159ManagercreatePlayer(source: DataSource):Player<<Interface>>ControllableDataSourcecreatesgetControl()gets controlPlayerFigure 3.22ControlThe basic architecture of the Mobile Media API.3.4.1.2 Obtaining Media ContentThe elements of the Mobile Media API work together as shown inFigure 3.22 (the PlayerListener has been omitted and we shallreturn to it in Section 3.4.1.3).A Player is typically created using the following factory methodof the javax.microedition.media.Manager class:public static Player createPlayer(String locator)The method’s argument is a media locator, a String representing aURI that provides details about the media content being obtained.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
