Definición Ciclo de vida de un midlet Estado DETENIDO (paused) Estado ACTIVO (active) Estado DESTRUÍDO (destroyed) Métodos modificadores de estado Método startApp() Método pauseApp() Método destroyApp(boolean) Relación entre destroyApp() y notifyDestroyed() Método notifyPaused() Método resumeRequest() Entorno de ejecución

1. Midlets con J2ME Jorge Iván Meza Martínez < [email_address] > http://www.jorgeivanmeza.com/ http://educacion.misservicios.net/

3. Definición Un midlet es una aplicación desarrollada utilizando la plataforma J2ME y construída sobre la configuración CLDC utilizando el perfil MIDP . Los midlets son las aplicaciones que se desarrollan para los teléfonos móviles actuales, con soporte para CLDC 1.0 ó 1.1 y MIDP 1.0 ó 2.0. En el presente módulo se expondrá el ciclo de vida de estas aplicaciones y su entorno de ejecución.

4. Ciclo de vida de un midlet El midlet en su ciclo de vida atraviesa tres tipos de estados diferentes: pausado ( paused ), activo ( active ) y destruído ( destroyed ).

6. Estado DETENIDO ( paused ) En este estado se espera que el midlet mantenga los recursos mínimos posibles liberando los demás para que sean utilizados por el dispositivo con la nueva aplicación activa. La aplicación queda en espera de una notificación asíncrona que modifique su estado actual. Puede pasar a estado activo si se ejecuta el método startApp() / resumeRequest() o a estado destruído si se ejecuta el método destroyApp() / notifyDestroyed() .

8. Estado ACTIVO ( active ) En este estado el midlet se está ejecutando propiamente. Puede pasar a estado detenido si se ejecuta el método pauseApp() o a estado destruído si se ejecuta el método destroyApp() / notifyDestroyed() .

9. Estado DESTRUÍDO ( destroyed ) El midlet pasa a este estado si es ejecutado uno de estos métodos destroyApp() / notifyDestroyed(). Después de entrar a este estado no podrá volver a hacer ninguna otra transición. Su finalidad es la de concluír el ciclo de vida del midlet y terminar la aplicación.

11. Método startApp() Este método es abstracto, debe ser definido por el midlet para reservar todos los recursos y establecer los valores iniciales de los atributos que vaya a necesitar en su estado activo. Debe tenerse muy en cuenta que este método puede ser ejecutado en varias ocasiones : cuando se inicia por primera vez la aplicación y cada vez que el midlet pasa de estado paused a active . Esto es particularmente importante en el momento de decidir donde realizar la creación de ciertos objetos: si en este método o en el constructor del midlet .

12. Método startApp() Como regla general en el método startApp() se reservarán los recursos que son liberados en el método pauseApp() . También es necesario tener en cuenta para tomar esta decisión que el constructor del midlet tiene acceso al objeto Display (pantalla del dispositivo) solamente a partir del primer llamado al método startApp() . El proceso de reserva de recursos puede fallar por motivos transitorios (usualmente recuperables) o por motivos permanentes (acostumbran a ser insoslayables y obligan a la terminación de la aplicación).

13. Método startApp() Los problemas transitorios deberán lanzar una excepción de tipo MIDletStateChangeException para indicar su tipo y solicitarle al dispositivo que intente nuevamente la activación del midlet .

14. Método pauseApp() Este método es abstracto y deberá ser implementado por el midlet . Es llamado cuando se va a detener temporalmente la ejecución de la aplicación y su función es la de garantizar la conservación del estado del midlet y liberar la mayor cantidad de recursos que no vayan a ser requeridos durante este estado de “hibernación”. Durante el estado paused el midlet no se encuentra formalmente activo, sin embargo está posibilitado para recibir mensajes de eventos asíncronos como temporizadores o recepción de mensajes vía SMS .

15. Método destroyApp(boolean) Este método implementado por el midlet es invocado por el sistema operativo o por la propia aplicación cuando esta ha de finalizar su ejecución. Su misión es la de liberar todos los recursos que el midlet haya reservado durante su ejecución para finalizar su ciclo de vida. El método recibe un argumento de tipo booleano que indica si la peticion de destrucción es incondicional ( true ) haciendo que se liberen todos los recursos para terminar la aplicación o si por el contrario, es opcional ( false ) permitiendo que esta se obvie al lanzarse una excepción de clase MIDletStateChangeException la cual si es manejada adecuadamente por la aplicación permitirá que el midlet permanezca en estado active rehusándose a ser finalizado .

16. destroyApp() y notifyDestroyed() Cuando es el dispositivo el interesado de terminar la ejecución del midlet es este quien invoca sobre el segundo el método destroyApp(true) para solicitar su liberación de recursos y posterior destrucción. Cuando es el midlet mismo quien desea terminar su propia ejecución, este invocará el método notifyDestroyed() para informarle al sistema operativo sus intenciones. Este método no ejecuta automáticamente al método destroyApp() toda vez que presupone que el midlet ya se encuentra listo para terminar su ejecución.

17. destroyApp() y notifyDestroyed() Como esta es la única forma que tiene un midlet para gestionar su propia destrucción, es común que se realice un llamado a destroyApp(false) y se finalice con la invocación de notifyDestroyed() si no hubo contratiempos en el paso anterior.

18. destroyApp() y notifyDestroyed() Lo descrito anteriormente se ejemplifica con el siguiente código fuente. try { // Liberar recursos que haya reservado el midlet destroyApp(false); // Notificar al sistema operativo su destrucción notifyDestroyed(); } catch(MIDletStateChangeException e) { // El midlet no se quiere destruír }

19. notifyPaused() Este método le informa al sistema operativo que el midlet desea pasar a estado paused . Únicamente puede ser invocado cuando el midlet se encuentra en estado active . Tiene la misma funcionalidad de la invocación del método pauseApp() por parte del dispositivo.

20. resumeRequest() Este método le indica al dispositivo que un midlet actualmente en estado paused está interesado en activarse. El dispositivo puede reanudar al midlet invocando su método startApp() . Es funcionalmente antagónico al método notifyPaused() . La invocación de este método acostumbra a ser provocada por una tarea que se ejecuta en segundo plano, un temporizador o un evento de orígen externo.

21. Entorno de ejecución Es el entorno en el que se ejecutan las aplicaciones J2ME basadas en midlets o en suites de midlets que implementen el perfil MIDP. Una suite de midlets es un conjunto de midlets agrupados en un archivo JAR común. Por razones de seguridad la interacción entre midlets se encuentra restringida a los midlets que integren la misma suite (espacio de nombres). Las clases y recursos a los cuales tiene acceso un midlet deberán estar ubicados en la librería CLDC , la librería MIDP o en el archivo JAR de la distribución, de lo contrario serán inaccesibles.

22. Entorno de ejecución El software del dispositivo que provee el entorno necesario para que las distribuciones de midlets puedan ser administradas: instaladas, actualizadas, eliminadas, ejecutadas y detenidas, es el Application Management Software (AMS) también conocido como Java Application Manager (JAM). El AMS también es responsable de realizar la segunda etapa de verificación de las clases del midlet , la cual comprueba que se cumplan con todos los requerimientos de seguridad y sucede durante la instalación de la aplicación en el dispositivo. Recuérdese que una primera etapa de verificación ( preverify ) es realizada durante la etapa de desarrollo.

23. Fin de la presentación. Creative Commons (CC)