• Java 2 SDK, o bien cualquier otro entorno de desarrollo que ofrezca un compilador en linea de comandos para JAVA. Se recomienda el uso del SDK de JAVA, ya que los ejemplos vistos en clase se centrarán sobre esta herramienta. Se puede descargar de la página de SUN, en la siguiente dirección: http://java.sun.com/javase/downloads/index.jsp. Nosotros trabajeremos en el aula de prácticas con la versión 5, actualización 6, aunque ya hay disponibles versiones más recientes (actualización 8, e incluso verión 6 en modo beta).


• Java 2 Micro Edition. Se trata del paquete completo de desarrollo necesario. Incluye la herramienta KToolbar, junto con el perfil MIDP. Mediante la herramienta KToolbar se puede compilar código sin necesidad de interactuar directamente con CLDC, al mismo tiempo que se dispone de un emulador de terminal telefónico. De esta forma se puede comprobar el funcionamiento de la aplicación sobre un teléfono móvil. Se puede descargar en la dirección http://java.sun.com/javame/downloads/index.jsp. La versión más reciente es la 2.5, aunque nosotros trabajaremos con la 2.2. Esta versión puede descargarse desde http://java.sun.com/products/sjwtoolkit/download-2_2.html.


• CLDC 1.1. Esta herramienta sólo se necesita si se trabaja a bajo nivel, por ejemplo, para incorporar código nativo (en lenguaje C) que se quiera incorporar a la aplicación. Se trata de la versión más reciente de CLDC. El software necesario se puede encontrar en la dirección: http://www.sun.com/software/communitysource/j2me/cldc/download.xml. Para instalar convenientemente CLDC hemos de seguir los siguientes pasos (para linux):
  
  
  1. Una vez descargado el archivo j2me_cldc_1_1-fcs-src-winunix.zip (se trata de los fuentes del CLDC, comunes para windows, linux y otras plataformas), procederemos a descomprimirlo. Supongamos que el directorio donde está ubicado el zip es $HOME/java. Si aquí se descomprime el archivo (mediante el comando unzip nombrearchivo ), se generará el directorio j2me_cldc, donde se extraerán los archivos integrados en el zip. Uno de los subdirectorios creados bajo j2me_cldc es build. Bajo el directorio build se pueden encontrar diversos directorios, relativos a las diferentes plataformas para las que está disponible CLDC. Mirad si se encuentra el directorio $HOME/java/j2me_cldc/bin/linux. En caso afirmativo, aquí termina el proceso de instalación. En caso contrario es preciso continuar.
  
  
  2. El siguiente paso a realizar consiste en situarnos en el directorio asociado a la plataforma para la que se va a hacer la instalación. En nuestro caso cambiaremos al directorio linux (dentro del directorio build). El contenido de este directorio es un archivo Makefile, que contiene las órdenes necesarias para instalar la versión adecuada de CLDC. Basta ejecutar, en dicho directorio, el comando make.
  
  
  3. Así se genera la máquina virtual, en el directorio $HOME/java/j2me_cldc/bin/linux. La máquina virtual se denomina kvm.
  
  
• Netbeans. Se trata de un entorno completo de desarrollo de aplicaciones JAVA, con módulos especiales para aplicaciones sobre dispositivos móviles.  Dicha herramienta se puede descargar de la dirección: htpp://www.netbeans.org. Nosotros usaremos la versión 5, aunque hay disponibles versiones beta más recientes.

Las aplicaciones JAVA que se ejecutan en dispositivos que implementan MIDP se denominan MIDlets. Un MIDlet consta de al menos una clase JAVA, que debe derivar de la clase base abstracta javax.microedition.midlet.MIDlet. El tiempo de ejecución de un MIDlet viene controlado por una serie de métodos definidos en dicha clase y que, forzosamente, todas las clases derivadas deben implementar.

Un grupo de MIDlets relacionados pueden agruparse en un MIDlet suite. Todos los MIDlets de un suite se agrupan e instalan en un dispositivo como si fuesen un único elemento, de forma que sólo pueden desinstalarse y eliminarse en conjunto. Los MIDlets agrupados en un suite comparten tanto recursos estáticos como dinámicos:

• En tiempo de ejecución, si los dispositivos soportan ejecución concurrente, todos los MIDlets se ejecutarán en la misma máquina virtual. Por tanto, todos los MIDlets comparten las mismas instancias de todas las clases, así como los recursos cargados en la máquina virtual. Entre otras cosas, esto supone que se pueden compartir datos entre MIDlets y que las primitivas de sincronización no sólo deben usarse para proteger frente al acceso concurrente dentro de cada MIDlet, sino también el producido por otros MIDlets asociados al mismo suite.
  
  
• El almacenamiento persistente es gestionado de forma globar para todos los MIDlets del suite. Por tanto, los MIDlets pueden acceder tanto a sus propios datos persistente como a los de otras clases del MIDlet.
  
  

Como ejemplo de la forma en que los MIDlets de un suite comparten recursos, supongamos un suite que contiene una clase denominada Contador, destinada a mantener la cuenta del número de instancias de MIDlets del suite que se ejecutan en cada momento.

public class Contador {

    // Contador del numero de instancias

    private static int instancias;

    public static synchronized void incrementar(){
       instancias++;
    }

    public static synchronized void decrementar(){
       instancias--;
    }

    public static int obtener(){
      return instancias;
    } 
}

Una única instancia de esta clase se cargará en la máquina virtual, sin importar cuántos MIDlets de los que integren el suite están en ejecución en la máquina virtual. Esto significa que el mismo dato miembro estático instancias será usado por todos los MIDlets, por lo que los métodos incrementar y decrementar afectarán al mismo contador. En este caso es necesaria la sincronización para asegurar que las operaciones de incremento y decremento sean realmente atómicas.

Es importante indicar que los MIDlets deben empaquetarse antes de poderse instalar en los dispositivos de destino. Todo lo necesario de un suite debe empaquetarse en un archivo JAR. La información del paquete debe incluirse en un archivo de manifiesto. Esta información también estará especificada en otro archivo denominado descriptor de aplicaciones JAVA (JAD: java application descriptor), que se mantiene separado del archivo JAR.

Los archivos de manifiesto y JAD son archivos de texto con la siguiente estructura:

  nombre_atributo: valor_atributo

El nombre del atributo y su valor están separados por dos puntos, siendo el espacio adicional opcional. Todos los atributos que son relevantes para la instalación de MIDlets comienzan por el prefijo "MIDlet-". Una lista completa de atributos, junto con una breve descripción de sus valores asociados, aparece en la tabla siguiente. Los valores en las columnas JAD y JAR indican que el atributo es obligatorio (M), opcional (O) o ignorado (I).

Se aprecia que alguna información aparece duplicada en el archivo de manifiesto del JAR y en el archivo JAD. Veremos por qué esto es necesario. La función del archivo de manifiesto es indicar al dispositivo el nombre y versión del suite almacenado en el JAR, así como indicar cuáles de los archivos empaquetados se corresponden con cada uno de los MIDlets. Para usar esta información el dispositivo debe descargar el JAR y extraer el archivo de manifiesto. Una vez hecho esto, se pueden mostrar los valores de los atributos MIDlet-Name, MIDlet-Version, MIDlet-Vendor. También de los atributos opcionales MIDlet-Description y MIDlet-Icon. Estos atributos permiten al usuario decidir sobre la descarga. No obstante, el archivo JAR podría ser muy grande, por lo que llevaría mucho tiempo recuperarlo en situaciones de conexiones lentas, por ejemplo. Para evitar este problema, algunos de los atributos del manifiesto, con información extra, se duplica en el archivo JAD. Esto permite descargar inicialmente el archivo JAD en lugar del JAR. De esta forma, se puede mostrar al usuario la información del suite antes de haber descargado el archivo de sus clases. El archivo JAD contendrá información contenida en el manifiesto y alguna particular. Típicamente, los atributos que aparecen en él son:

    MIDlet-Name
    MIDlet-Vendor
    MIDlet-Version
    MIDlet-Description
    MIDlet-Icon
    MIDlet-Info-URL
    MIDlet-Data-Size
    MIDlet-Jar-Size
    MIDlet-Jar-URL

El objetivo de estos atributos, como se indicó con anterioridad, es ofrecer información sobre los MIDlets incluidos en el suite. Supongamos que desarrollamos un suite denominado Notas que permiten al usuario acceso directo a sus notas desde un dispositivo móvil. El suite contiene dos MIDlets: uno para ver las notas y otro para enviar información sobre posibles errores en ellas. Para desarrollar la clase se han usado métodos de utilidad, pertenecientes a la clase Utilidades. En definitiva, las clases involucradas serían las siguientes (teniendo en cuenta que forman parte del paquete desarrollo.moviles):

• desarrollo.moviles.VerNotas
• desarrollo.moviles.ErrorNotas
• desarrollo.moviles.Utilidades

El manifiesto para este suite podría ser el siguiente:

    MIDlet-Name: Notas
    MIDlet-Vendor: Programas Pepe
    MIDlet-Version: 1.0.1
    MIDlet-Description: Conjunto de midlets para ver notas
    MIDlet-Icon: /desarrollo/moviles/iconos/notas.png
    MIDlet-Info-URL: http://www.programaspepe.com/notas/info.html
    MIDlet-Data-Size: 512
    MicroEdition-Profile: MIDP-1.0
    MicroEdition-Configuration: CLDC
    MIDlet-1: Visualizador,/desarrollo/moviles/iconos/ver.png,desarrollo.moviles.VerNotas
    MIDlet-2: Errores,/desarrollo/moviles/iconos/error.png,desarrollo.moviles.ErrorNotas

En el archivo JAR correspondiente, el archivo de manifiesto aparecería como META.INF/MANIFEST.mf. El archivo JAR también contendría los siguientes archivos:

• /desarrollo/moviles/VerNotas.class
• /desarrollo/moviles/ErrorNotas.class
• /desarrollo/moviles/Utilidades.class
• /desarrollo/moviles/iconos/notas.png
• /desarrollo/moviles/iconos/ver.png
• /desarrollo/moviles/icones/error.png

Conviene hacer algunos comentarios en relación al valor de los atributos y al contenido del archivo JAR:

• El archivo JAR contiene las clases correspodientes a ambos MIDlets. Aunque la clase de utilidades se incluye no hay ninguna referencia a ella en el manifiesto.
• El atributo MIDlet-Icon contiene la ruta absoluta del archivo que contiene el icono del suite.
• Asociado a cada MIDlet hay un atributo que describe su nombre y le asocia un identificador. El valor del atributo incluye nombre, icono y clase asociada.

El archivo JAD asociado a este MIDlet contendrá la siguiente información:

    MIDlet-Name: Notas
    MIDlet-Vendor: Programas Pepe
    MIDlet-Version: 1.0.1
    MIDlet-Description: Conjunto de midlets para ver notas
    MIDlet-Info-URL: http://www.programaspepe.com/notas/info.html
    MIDlet-Data-Size: 512
    MicroEdition-Jar-Size: 10132 
    MIDlet-Jar-URL: http://www.programaspepe.com/notas/Notas.jar

Este archivo contiene la información que la pantalla del dispositivo mostrará al usuario, junto con la dirección URL del archivo JAR. En este caso, los atributos comunes tienen el mismo valor tanto en el archivo de manifiesto como en el archivo JAD. Para que el suite sea portable, es preciso que el archivo JAR esté codificado usando la codificación iso-8859-1, ya que se precisa que todas las implementaciones de MIDP soporten esta codificación.

En tiempo de ejecución los MIDlets pueden acceder a los archivos del JAR asociado al suite y obtener información sobre los valores de los atributos.

Simplemente, como comentario inicial, aunque se comentará más tarde, los MIDlets deben derivar de la clase abstracta javax.microedition.midlet.MIDlet, que contiene métodos destinados a controlar el tiempo de ejecución de los MIDlets. Todos los MIDlets deben tener un constructor público predeterminado (es decir, que no requiera argumentos). La estructura básica de un MIDlet se muestra a continuación:

    public class EjemploMidlet extends MIDlet{
       // Constructor: opcional. Bastaría con el constructor por
       // defecto

       public EjemploMidlet(){
       }

       // Método que iniciará la ejecución del MIDlet

       public void startApp() throws MIDletStateChangeException{
       }

       // Método que interrumpe la ejecución del MIDlet

       public void pauseApp(){
       }

       // Método para finalización del MIDlet

       public void destroyApp(boolean unconditional) 
                throws MIDletStateChangeException{
       }
    }

En todo momento, los posibles estados en que podría estar un MIDlet son:

• pausa
• activo
• destruido

Inicialmente, cuando se produce la carga de un MIDlet, éste estará en estado pausa. Cuando se produce la llamada al método startApp() se produce el paso al estado activo. En cualquier instante, la plataforma MIDP podría poner a un MIDlet en estado de pausa. Por ejemplo, en los teléfonos móviles esto ocurrirá cuando se detecta una llamada entrante. Esto se realiza mediante una llamada al método pauseApp(). La vuelta al estado activo precisa de una nueva llamada a startApp(). Cuando se precisa la finalización de un MIDlet se usará una llamada a destroyApp(...). Al producirse esta llamada se liberan los recursos que el MIDlet pudiera estar usando, siempre que el argumento de este método sea true. Pero pudiera haber algunas situaciones en que este tipo de finalización no es conveniente; por ejemplo, por haber datos que aún no se han almacenado. En este caso, la llamada al método debería hacerse usando como argumento false. Esto produce el lanzamiento de la excepción MIDletStateChangeException. El código debería estar preparado para capturar la excepción y actuar en consecuencia.

Para ilustrar el ciclo de vida un MIDlet y la forma en que se controla, a la vez que mostrar el funcionamiento de las herramientas de generación de MIDlets, vamos a considerar un ejemplo sencillo de MIDlet, caracterizado por:

• El MIDlet se llamará EjemploMIDlet1. El constructor imprime el valor de la propiedad color (ya veremos para qué se hace esto) y muestra un mensaje indicando que el midlet está construido y el valor de la propiedad.


• El método startApp() se encarga de mostrar un mensaje que permita trazar el ciclo de vida del MIDlet. A continuación se hace lo siguiente:
  • Si es la primera vez que se llama al método startApp(), entonces se crea un objeto auxiliar de la clase Tarea, que permite, en una hebra aparte, ejecutar una simple cuenta. Después de crear este objeto se invoca al método start() del mismo, de forma que empieze a desarrollarse la tarea indicada en el método run() de la misma. Finalmente se cambiará el valor de la variable booleana, de forma que la próxima vez que se llame al método startApp() se sepa que se trata de una llamada producida al salir de una pausa.
  
  
  • Si no es la primera vez que se llama al método startApp(), entonces se prosigue con la ejecución de la tarea realizada por la hebra, desde el punto en que se quedara parada previamente como consecuencia de la pausa. Cuando la tarea se finaliza, se fuerza la destrucción del MIDlet, mediante la llamada a destroyApp(true). El argumento true pasado a destroyApp indica que se busca liberar todos los recursos que el MIDlet pudiera estar usando.
  
  
• El método pauseApp() se invoca al producirse una llamada telefónica, por ejemplo. Para forzar este evento hay una opción concreta del menú MIDlet de KToolbar. Al recibirse la llamada a este método, se muestra un mensaje para seguir la traza de funcionamiento. Se imprime el estado de trabajo de la tarea auxiliar (de la cuenta) y se fuerza a que la hebra deje de trabajar. Este es el objetivo de la llamada tarea.interrumpir().

Como no se sabe aún lo suficiente como para construir interfaces de usuario (aunque pronto se sabrá), todos los mensajes se enviarán a la salida estándar. Se incluye a continuación el código correspondiente, y seguidamente se verá cómo generar el suite, tanto de forma manual como automática.

import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;

public class EjemploMIDlet1 extends MIDlet{
  Tarea tarea;
  boolean primeraVez;
		
  // Constructor por defecto de la clase
  public EjemploMIDlet1(){
    String color=getAppProperty("color");
    System.out.println("\n\n\nConstruido MIDlet con color: "+color);
    primeraVez=true;
  }

  // Metodo para iniciar el funcionamiento del MIDlet
  public void startApp() throws MIDletStateChangeException{
    System.out.println("Metodo startApp");

    if (primeraVez == true){
      System.out.println("Ejecucion la primera vez.......");
			System.out.println("Se inicia cuenta larga para permitir pausar");
      tarea=new Tarea();
      tarea.start();
      primeraVez=false;
    }
    else{
      // Se reanuda la ejecucion tras salir de la pausa
      System.out.println("Llamada tras pausa..... Valor de i: "+tarea.getI());
      tarea.continuar();

      // Se destruye el midlet cuando la tarea termine
      if (tarea.getFinalizado() == true){
         destroyApp(true);
      }
    }
  }

  // Metodo para detener el funcionamiento del MIDlet
  public void pauseApp(){
    System.out.println("Metodo pauseApp");
    System.out.println("Valor de i en el momento de la pausa: "+tarea.getI());
    tarea.interrumpir();
  }

  // Metodo para destruir el MIDlet
  public void destroyApp(boolean condition){
    System.out.println("Metodo destroyApp. Condicion: "+condition);
    
    if (condition == true){
       // Se indica la finalizacion del midlet
       notifyDestroyed();
    }
  }
}

class Tarea extends Thread{
  int i;
  boolean interrumpido;
  boolean finalizado;

  Tarea(){
    i=0;
    interrumpido=false;
    finalizado=false;
  }

  public void run(){
    for(; i < 9000000; ){
      if (interrumpido == false){
        i++;
      }
      else{
        try{
          sleep(100);
        }
        catch(InterruptedException e){
          System.out.println("Problema al dormir hebra....");
        }
      }
      //System.out.println("Valor de i: "+i);
    }

    // Se finaliza la tarea
    finalizado=true;
  }

  // Metodo para obtener el valor de i
  int getI(){
    return i;
  }

  // Metodo para interrumpir
  void interrumpir(){
    interrumpido=true;
  }

  // Metodo para continuar
  void continuar(){
    interrumpido=false;
  }

  // Metodo para acceder al valor de finalizado
  boolean getFinalizado(){
    return finalizado;
  }
}

El código completo de este MIDlet puede descargarse directamente desde aquí: EjemploMIDlet1.java Se trata de un MIDlet muy sencillo, que permitirá practicar con los procedimientos de generación de MIDlets, así como los posibles estados en que puede encontrarse un MIDlet en ejecución: pausa, activo y destruido.

Seguiremos el proceso completo de trabajo sobre el MIDlet incluido anteriormente. El primer paso consistirá en ejecutar la herramienta KToolbar. Esta aplicación se encuentra en la instalación de Wireless Toolkit. Para ejecutarla haremos lo siguiente (si no funciona, avisad al profesor.......).

ktoolbar

La ventana principal de KToolbar tiene la siguiente aparencia:

Crearemos un proyecto de suite, en el que incluiremos el MIDlet generado con anterioridad. Para ello se pulsa en el botón New Project. Al pulsar sobre él aparecerá la siguiente ventana:

Como se ve, hemos rellenado la información de ambos campos de texto. Como nombre del proyecto podemos elegir cualquiera, sin necesidad de coincidir con el nombre de la clase principal del MIDlet. En el segundo campo de texto hemos de especificar el nombre de la clase principal del suite que queremos ejecutar en el emulador. En este caso es EjemploMIDlet1. En cuanto se pulsa el botón Create Project aparecerá una nueva ventana donde aparecen informaciones relativas al MIDlet.

Al mismo tiempo, en la ventana principal de KToolbar han aparecido varios mensajes:

Estos mensajes indican que se ha creado la estructura de directorios necesaria para el proyecto, y que las clases que queramos formen parte del MIDleet habrá que ubicarlas en el directorio src; recursos adicionales (como iconos) irán en el directorio res y las librerías (si las hubiera) en el directorio lib. Como se ve, el directorio del proyecto se crea en el directorio de instalación de la herramienta, bajo el subdirectorio apps. En nuestro caso, la ruta completa será $HOME/java/WTK2.2/apps/ejemplo1. Nuestro primer MIDlet usará un icono muy sencillo (descargadlo aquí: iconoPeq.png).

Por tanto, lo primero que haremos será copiar el archivo con la clase asociada al MIDlet en el directorio $HOME/java/WTK2.2/apps/ejemplo1/src/. El icono se ubicará en el directorio $HOME/java/WTK2.2/apps/ejemplo1/res/. Dentro de este directorio crearemos a su vez el directorio icons. Y en él será donde se guarde el archivo png del icono. Para indicar que el icono del MIDlet es este, debe modificarse la información sobre el icono. Para ello se pulsa el botón Settings de KToolbar. Aparecerá la venta siguiente:

Aprovechamos ahora para indicar que deseamos que el MIDlet sea conforme a MIDP1.0. Para ello se selecciona esta opción de las disponibles al pulsar sobre Target Platform. Para indicar el icono asociado, se selecciona la pestaña MIDlets. Una vez hecho esto aparecerá

Para poder cambiar el icono (el valor presente en la figura anterior se introduce por defecto), basta con seleccionar la línea con los datos (la fila que aparece rellena), con lo que se marcará con un color diferente para indicarnos que está seleccionada:

Ahora basta con pulsar sobre el botón Edit, lo que dará lugar a la aparición de la ventana de edición:

Sobre esta ventana, en el recuadro Icon escribiremos /icons/iconoPeq.png, tal y como se aprecia a continuación:

Al finalizar se pulsa sobre el botón Aceptar de la ventana de edición. Con esto queda registrado el cambio de la propiedad correspondiente al icono del MIDlet:

Y pulsando sobre el botón OK desaparece la ventana de propiedades. Esto es todo lo necesario para poder generar y ejecutar el MIDlet. En primer lugar, procedemos a generar las clases a partir del código fuente. Para ello se pulsa el botón Build. Si todo ha ido bien, aparecerá un mensaje indicado que la generación se realizó de forma correcta. En caso de haber errores, se mostrarán en la ventana principal de KToolbar.

En cuanto se ha generado el MIDlet, podemos ejecutar mediante el botón Run. Al pulsarlo, aparecerá el emulador con el MIDlet listo para ejecución.

Para lanzar la ejecución del MIDlet se pulsa sobre la tecla bajo el mensaje Launch. En cuanto se produce esto el MIDlet se crea y el dispositivo invoca al método startApp(). Esto explica los mensajes que se aprecian en la consola de KToolbar:

Se muestra el mensaje de traza puesto en el constructor, indicando que la propiedad color no está definida. Arreglar esto se deja para más adelante. También se aprecia la traza ubicada a la entrada del método startApp(), que ha sido invocado por el sistema de gestión de ejecución de MIDlets del dispositivo móvil. Los dos mensajes que aparecen a continuación son trazas que muestran que el MIDlet se ejecuta por primera vez.

Para pausar el MIDlet, tras unos segundos de funcionamiento, basta con actuar sobre el menú MIDlet del emulador telefónico y seleccionar la opción Pause. Al hacerlo el emulador queda de la forma siguiente:

A su vez, en la consola de KToolbar veremos los siguientes mensajes:

Las nuevas líneas de traza indican que se ha invocado al método pauseApp(). Como comentamos previamente, esto ocurrirá al producirse una llamada de teléfono sobre el móvil, por ejemplo. Se observa el valor de la cuenta en el momento en que se produjo la pausa. Para continuar ejecutando el MIDlet (lo que ocurriría al finalizar la llamada), forzamos la salida del modo de pausa. Para ello volvemos a actuar sobre el menú MIDlet, seleccionado la opción Resume. Esto hace que aparezcan nuevas líneas de traza indicando que se ha producido una nueva llamada al método startApp(), pero sin tratarse de la primera llamada al mismo.

Por su parte, del emulador desaparece la indicación de llamada entrante:

Si se observa el código del método startApp(), se aprecia que la destrucción del MIDlet sólo se producirá en el caso en que ya haya finalizado la tarea de cuenta. Para asegurarnos que esto ocurre, tras la salida del modo de pausa esperaremos unos segundos, se genera una nueva pausa (pulsando, como se indicón previamente, sobre la opción Pause del menú MIDlet) para, a continuación forzar, mediante Resume (en el menú MIDlet), una nueva llamada a startApp() una vez finalizada la cuenta. Cuando esto ocurra, tendremos:

Sólo cuando el MIDlet haya sido destruido de forma completa podrá volver a lanzarse de forma correcta.

EJERCICIO 1: probad qué ocurre cuando se intenta lanzar de nuevo la ejecución del MIDlet antes de que haya finalizado completamente la tarea de cuenta. Justificad el comportamiento observado.

Cuando se usa destroyApp(false) permite que el método compruebe si se cumplen las condiciones necesarias para finalizar o no. En caso de no cumplirse, puede generar una excepción del tipo MIDletStateChangeException, lo que genera a su vez una nueva llamada startApp().

EJERCICIO 2: se propone que modifiquéis el código del MIDlet anterior de la forma siguiente:

• Montad un nuevo proyecto, ejemplo2, para trabajar sobre esta variante. La clase del MIDlet se denominará EjemploMIDlet2. Podéis partir de la clase EjemploMIDlet1 y modificarla.


• En el método startApp(), en caso de no ser la primera llamada, después de la sentencia tarea.continuar(), se realiza la llamada a destroyApp(false). Esta llamada habrá que encerrarla en un bloque try-catch, ya que el método destroyApp() podría decidir generar la excepción si considera que el MIDlet no debe finalizar.


• Modificad el método destroyApp(), de forma que en caso de recibir como argumento false, compruebe si la tarea ha finalizado o no. Si no ha finalizado, lanza una excepción del tipo MIDletStateChangeException, para dar tiempo a que la tarea de conteo finalice. Si la tarea ha finalizado, se llama al método notifyDestroyed(), con lo que el MIDlet indica que desea finalizar.

En nuestro caso, el MIDlet usa un valor de atributo (color). Si se observa el código, se comprobará que al imprimir su valor se muestra null. Si se intenta manejar esta propiedad, sin haberla especificado de forma explícita, puede ocurrir un error como el mostrado a continuación:

Pero, ¿cómo se define este atributo?. Para ello usaremos el botón Settings. Cuando aparezca la ventana de propiedades del MIDlet, seleccionaremos la opción User Defined, que permitirá definir atributos propios. Sobre esta ventana, pulsaremos el botón Add.

Al pulsar sobre Add aparecerá la ventana que hemos de usar para definir el valor de la propiedad deseada:

Se escribe el nombre de la propiedad (color) y se pulsa sobre Aceptar. Con esto la ventana de propiedades queda de la siguiente forma:

Se pincha sobre el campo de texto en blanco y se introduce el valor deseado:

Pulsamos OK y ya podemos volver a ejecutar el MIDlet. Ahora la traza inicial indica:

EJERCICIO 3: probad con los MIDlets de demo que vienen con la herramienta. Activad la monitorización, activando las preferencias (Edit + Preferences + Monitor) deseadas. Con esto podéis haceros una idea de la capacidad de la plataforma de desarrollo. Haced un pequeño guión con indicaciones sobre vuestra opinión al respecto: demos más interesantes, limitaciones, puntos fuertes, etc.