Mobile Media API (MMAPI, JSR-135): un conjunto de clases para J2ME que le permite reproducir sonido y video; parte de MIDP 2.0.
MIDP 2.0 requiere que el teléfono reproduzca tonos y sonidos WAV . La reproducción de otros formatos ( MIDI , MP3 , AMR , 3GP , MPEG - 4, MMF , iMelody ) es opcional. Sin embargo, MIDI se reproduce de facto en todos los teléfonos.
Las clases de MMAPI están en el javax.microedition.media.
La clase Manager se utiliza para crear jugadores. Todos los jugadores tienen una interfaz de jugador . MMAPI también incluye otras clases e interfaces que se utilizan para controlar el volumen, responder a eventos, etc.
El jugador tiene cinco estados:
Manager.createPlayer()El reproductor recién creado por la función está en el estado UNREALIZED.
La función realize()descarga todos los recursos necesarios para la reproducción, a excepción de los "valiosos y escasos" (en particular, lee un archivo o se comunica con el servidor ). El jugador es transferido de un estado UNREALIZEDa otro REALIZED. La llamada a la función realize()puede tardar algún tiempo.
La función prefetch()carga "recursos valiosos y escasos"; el jugador se mueve del estado UNREALIZEDo REALIZEDal estado PREFETCHED. La llamada a la función prefetch()también puede tardar algún tiempo. En la mayoría de las implementaciones de MMAPI, PREFETCHEDsolo un jugador puede estar en un estado.
La función start()inicia la reproducción al cambiar el reproductor de los estados UNREALIZEDo REALIZEDal PREFETCHEDestado STARTED. Si el jugador estaba en el estado PREFETCHED, se start()garantiza que la función se llamará al instante. Si el reproductor se rebobina hasta el final, la función start()inicia la reproducción desde el principio.
La función close()se llama cuando el reproductor ya no es necesario. El jugador entra en el estado CLOSED, y en este estado puede ser destruido por el recolector de basura .
Para detener el reproductor, la función se llama stop(). Al mismo tiempo, pasa de un estado STARTEDa otro PREFETCHED(y no retrocede a ningún lado).
La función está llamada a liberar recursos escasos deallocate(). Al mismo tiempo, pasa del estado STARTEDo PREFETCHEDal estado REALIZED.
La función deallocate()tiene otro papel importante. Si la transición del reproductor al estado REALIZEDno se ha completado (es decir, el archivo no se ha descargado hasta el final), la carga del archivo se interrumpe y el reproductor permanece en el formato UNREALIZED.
No UNREALIZEDhay camino en el estado.
La interfaz vacía Controlsirve como base para construir varias interfaces de control de reproducción. Varios descendientes Controlestán definidos en el paquete javax.microedition.media.control: ToneControl, VolumeControl, MIDIControletc.
MMAPI es parte de MIDP 2.0. Es decir, cualquier teléfono que admita MIDP 2.0 debe admitir MMAPI. Aquí hay una lista (no exhaustiva) de teléfonos MIDP 1.0 que admiten MMAPI.
MMAPI está diseñado para reproducir sonido, video, etc. en aplicaciones multimedia . Por ejemplo, en el teléfono Motorola E398 , el reproductor de audio incorporado está escrito en Java usando MMAPI. Sin embargo, MMAPI no es adecuado para implementar efectos de sonido en juegos móviles , ya que cada teléfono tiene sus propias sutilezas. Algunos le permiten mantener todos los sonidos simultáneamente en el estado y reproducirlos en cualquier momento; en otros es necesario recurrir a varios trucos. También hay sutilezas menos obvias. Sucede que debe pasar algún tiempo entre detener y reproducir el reproductor, ¡en algunos modelos que no son obsoletos, este tiempo es de 1-2 s! PREFETCHED
Algunas "sutilezas" son en realidad violaciones directas de la norma.
De manera predeterminada, si el reproductor está en el estado UNREALIZED, el comando start()primero lo cambiará a REALIZED, luego a PREFETCHED, luego a STARTED. Algunos teléfonos no permiten tales "saltos"; es necesario establecer explícitamente realize(), prefetch(), start().
Algunos teléfonos cargan archivos más tarde, lo que también va en contra del estándar. Supongamos que el jugador ha sido creado y movido al estado PREFETCHED. De acuerdo con el estándar, el comando start()debe llamarse instantáneamente. Pero algunas implementaciones de MMAPI se cargan solo bajo comando start()(y solo las repetidas start()se llaman instantáneamente).
De acuerdo con el estándar, si la reproducción finaliza, luego de un segundo comando, el start()reproductor debe comenzar a reproducir nuevamente. En algunos teléfonos, dicho reproductor no reproduce nada hasta que se rebobina explícitamente con el setMediaTime(0).
Se supone que el MIDP 3.0 aún no lanzado resolverá esta inconsistencia al endurecer los requisitos para la implementación de MMAPI.
| Java | |
|---|---|
| Plataformas | |
| Tecnologías solares | |
| Tecnologías clave de terceros | |
| Historia |
|
| Propiedades del lenguaje | |
| Lenguajes de secuencias de comandos |
|
| Conferencias Java |
|