Departamento de Lenguajes y Sistemas Informáticos

Cursos de Doctorado. Universidad de Sevilla

DESARROLLO DE APLICACIONES JAVA PARA

MÓVILES: J2ME Y HERRAMIENTAS DE
DESARROLLO

Francisco Martínez Álvarez

Sevilla, 7 de junio de 2006

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 1

 ÍNDICE

1. INTRODUCCIÓN 3
1.1 Evolución histórica de la telefonía móvil 3
1.2 Objetivos 3

2. J2ME 4
2.1 Análisis comparativo
2.2 Nuevos conceptos 5
2.2.1 Configuración 5
2.2.2 Perfiles 6
2.3 MIDLet 7

3. HERRAMIENTAS DE DESARROLLO 9
3.1 Desarrollo de aplicaciones en Sun One Studio Mobile Edition 6 9
3.2 Desarrollo de aplicaciones en J2ME Wireless Toolkit 2.2 10
3.2.1 Componentes 10
3.2.2 Características 10
3.2.3 Uso 10

4. EJEMPLO 12

5. ANEXO: CÓDIGO 13

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 2

1. INTRODUCCIÓN
1.1 Evolución histórica de la telefonía móvil
Uno de los primeros avances de la telefonía móvil en el sector de las
comunicaciones se dio con la aparición de la tecnología WAP. WAP proviene de
Wireless Application Protocol (protocolo de aplicación inalámbrica). Es un protocolo
con el que se ha tratado de dotar a los dispositivos móviles de un pequeño y limitado
navegador web. WAP exige la presencia de una puerta de enlace encargado de actuar
cómo intermediario entre Internet y el terminal. Esta puerta de enlace o gateway es la
que se encarga de convertir las peticiones WAP a peticiones web habituales y viceversa.
Las páginas que se transfieren en una petición usando WAP no están escritas en HTML,
si no que están escritas en WML, un subconjunto de éste. WAP ha sido un gran avance,
pero no ha resultado ser la herramienta que se prometía. La navegación es muy
engorrosa ya que la introducción de URLs largas por teclado es muy pesada, además de
que cualquier error en su introducción requiere que se vuelva a reescribir la dirección.
Además su coste es bastante elevado ya que el pago de uso de esta tecnología se realiza
en función del tiempo de conexión a una velocidad, que no es, digamos, muy buena.

Los avances de la telefonía móvil nos llevaron a las tecnologías conocidas como
generaciones 2 y 2.5 que hacen uso de las tecnologías GSM y GPRS respectivamente.
GSM es una conexión telefónica que soporta una circulación de datos, mientras que
GPRS es estrictamente una red de datos que mantiene una conexión abierta en la que el
usuario paga por la cantidad de información intercambiada y no por el tiempo que
permanezca conectado. Un servicio suplementario de GSM son los SMS (Short
Message System). Con ayuda de J2ME, sin embargo, podemos realizar aplicaciones de
chat o mensajería instantánea.

En la actualidad, y tras varios años de incertidumbre que produjeron la quiebra

de numerosas de compañías de telecomunicaciones, se está implantando
progresivamente UMTS o la tercera generación de móviles. Esta nueva tecnología ha
supuesto un salto cualitativo en la calidad de las comunicaciones hasta ahora
desconocido, proporcionando anchos de banda de 2 Mbits. Las aplicaciones J2ME ven
en UMTS un vehículo de expansión extraordinario.

Otras tecnologías que favorecen la comunicación son Bluetooth y las redes

inalámbricas que dan conectividad a ordenadores, PDAs y teléfonos móviles. De hecho,
una gran variedad de estos dispositivos disponen de soporte bluetooth. Esto nos facilita
la creación de redes con un elevado ancho de banda en distancias pequeñas (hasta 100
metros).

1.2 Objetivos
Este trabajo pretende ser una guía para aquellas personas que estén interesadas
en iniciarse en el mundo del J2ME o, lo que es lo mismo, en el mundo de las
aplicaciones Java para móviles.

No se ha pretendido en ningún momento dar una descripción detallada del

lenguaje J2ME, sino presentar algunas de sus peculiaridades más características que lo
hacen diferente del J2SE. Del mismo modo, este trabajo es una recopilación de diversos
trabajos ya realizados por otros autores y que pueden conseguirse gratuitamente en la
web.

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 3

2. J2ME
2.1 Análisis comparativo
J2ME es el acrónimo de Java 2 Micro Edition. J2ME es la versión de Java
orientada a los dispositivos móviles. Debido a que los dispositivos móviles tienen una
potencia de cálculo baja e interfaces de usuario pobres, es necesaria una versión
específica de Java destinada a estos dispositivos, ya que el resto de versiones de Java,
J2SE o J2EE, no encajan dentro de este esquema. J2ME es por tanto, una versión
reducida de J2SE.

Sun, dispuesto a proporcionar las herramientas necesarias para cubrir las

necesidades de todos los usuarios, creó distintas versiones de Java de acuerdo a las
necesidades de cada uno. Según esto nos encontramos con que el paquete Java 2 lo
podemos dividir en 3 ediciones distintas. J2SE (Java Standard Edition) orientada al
desarrollo de aplicaciones independientes de la plataforma, J2EE (Java Enterprise
Edition) orientada al entorno empresarial y J2ME (Java Micro Edition) orientada a
dispositivos con capacidades restringidas. Veamos cuáles son las características de cada
una de las versiones:
1. Java 2 Platform, Standard Edition (J2SE). Esta edición de Java es la que en
cierta forma recoge la iniciativa original del lenguaje Java. Tiene las siguientes
características:
• Inspirado inicialmente en C++, pero con componentes de alto nivel,
como soporte nativo de strings y recolector de basura.
• Código independiente de la plataforma, precompilado a bytecodes
intermedio y ejecutado en el cliente por una JVM (Java Virtual
Machine).
• Modelo de seguridad tipo sandbox proporcionado por la JVM.
• Abstracción del sistema operativo subyacente mediante un juego
completo de APIs de programación.
Esta versión de Java contiene el conjunto básico de herramientas usadas para
desarrollar Java Applets, así cómo las APIs orientadas a la programación de
aplicaciones de usuario final: interfaz gráfica de usuario, multimedia, redes de
comunicación…

2. Java 2 Platform, Enterprise Edition (J2EE). Esta versión está orientada al

entorno empresarial. El software empresarial tiene unas características propias
marcadas: está pensado no para ser ejecutado en un equipo, sino para ejecutarse
sobre una red de ordenadores de manera distribuida y remota mediante EJBs
(Enterprise Java Beans). De hecho, el sistema se monta sobre varias unidades o
aplicaciones. En muchos casos, además, el software empresarial requiere que se
sea capaz de integrar datos provenientes de entornos heterogéneos. Esta edición
está orientada especialmente al desarrollo de servicios web, servicios de
nombres, persistencia de objetos, XML, autenticación, APIs para la gestión de
transacciones, etc. El cometido de esta especificación es ampliar la J2SE para
dar soporte a los requisitos de las aplicaciones de empresa.

3. Java 2 Platform, Micro Edition (J2ME). Esta versión de Java está enfocada
a la aplicación de la tecnología Java en dispositivos electrónicos con capacidades
computacionales y gráficas muy reducidas, tales como teléfonos móviles, PDAs
o electrodomésticos inteligentes. Esta edición tiene unos componentes básicos
que la diferencian de las otras versiones, como el uso de una máquina virtual

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 4

 denominada KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos
Kilobytes de memoria para funcionar) en vez del uso de la JVM clásica,
inclusión de un pequeño y rápido recolector de basura.

Figura. Relación entre las APIs de la plataforma Java

2.2. Nuevos conceptos

2.2.1 Configuración
La configuración es un mínimo grupo de APIs (Application Program Interface),
útiles para desarrollar las aplicaciones destinadas a un amplio rango de dispositivos. La
configuración estándar para los dispositivos inalámbricos es conocida como CLDC
(Connected Limited Device Configuration). El CLDC proporciona un nivel mínimo de
funcionalidades para desarrollar aplicaciones para un determinado conjunto de
dispositivos inalámbricos. Se puede decir que CLDC es el conjunto de clases esenciales
para construir aplicaciones. Hoy por hoy, sólo tenemos una configuración, pero es de
esperar que en el futuro aparezcan distintas configuraciones orientadas a determinados
grupos de dispositivos. Los requisitos mínimos de hardware que contempla CLDC son:
• 160KB de memoria disponible para Java.
• Procesador de 16 ó 32 bits con al menos 25 Mhz de velocidad.
• Ofrecer bajo consumo, debido a que éstos dispositivos trabajan con suministro
de energía limitado, normalmente baterías.
• Tener conexión a algún tipo de red, normalmente sin cable, con conexión
intermitente y ancho de banda limitado (unos 9600 bps).

Los dispositivos que claramente encajan dentro de este grupo, son los teléfonos
móviles, los PDA (Personal Digital Assintant) o los Pocket PC”. En cuanto a los
requisitos de memoria, según CLDC, los 160KB se utilizan de la siguiente forma:
• 128KB de memoria no volátil para la máquina virtual Java y para las librerías d
el API de CLDC
• 32KB de memoria volátil, para sistema de ejecución (Java Runtime System).

En cuanto a las limitaciones impuestas por CLDC, tenemos por ejemplo las
operaciones en coma flotante. CLDC no proporciona soporte para matemática en coma
flotante. Otra limitación es la eliminación del método Object.finalize. Este método es
invocado cuando un objeto es eliminado de la memoria, para optimizar los recursos.
También se limita el manejo de las excepciones. Es complicado definir una serie de
clases de error estándar, que se ajuste a todos los dispositivos contemplados dentro de
CLDC. La solución es soportar un grupo limitado de clases de error y permitir que el
API específico de cada dispositivo defina su propio conjunto de errores y excepciones.

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 5

La seguridad dentro de CLDC es sencilla, sigue el famoso modelo sandbox. Las líneas
básicas del modelo de seguridad sandbox en CLDC son:
• Los ficheros de clases, deben ser verificados como aplicaciones válidas.
• Sólo las APIs predefinidas dentro de CLDC están disponibles.
• No se permite cargadores de clases definidos por el usuario.
• Sólo las capacidades nativas proporcionadas por CLDC son accesibles.

2.2.2 Perfiles
El perfil es el que define las APIs que controlan el ciclo de vida de la aplicación
e interfaz de usuario. Más concretamente, un perfil es un conjunto de APIs orientado a
un ámbito de aplicación determinado. Los perfiles identifican un grupo de dispositivos
por la funcionalidad que proporcionan (electrodomésticos, teléfonos móviles…) y el
tipo de aplicaciones que se ejecutarán en ellos. Las librerías de la interfaz gráfica son un
componente muy importante en la definición de un perfil. Aquí nos podemos encontrar
grandes diferencias entre interfaces, desde el menú textual de los teléfonos móviles
hasta los táctiles de los PDAs.

El perfil establece unas APIs que definen las características de un dispositivo,

mientras que la configuración hace lo propio con una familia de ellos. Esto hace que a la
hora de construir una aplicación se cuente tanto con las APIs del perfil como de la
configuración. Tenemos que tener en cuenta que un perfil siempre se construye sobre
una configuración determinada. De este modo, podemos pensar en un perfil como un
conjunto de APIs que dotan a una configuración de funcionalidad específica.

Existen unos perfiles que construiremos sobre la configuración CDC y otros que
construiremos sobre la CLDC. Para la configuración CDC tenemos los siguientes
perfiles:
• Foundation Profile.
• Personal Profile.
• RMI Profile.

Y para la configuración CLDC tenemos los siguientes:

• PDA Profile.
• Mobile Information Device Profile (MIDP).

Figura. Modelo de perfiles J2ME.

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 6

2.1.3 MIDLet
Las aplicaciones J2ME desarrolladas bajo la especificación MIDP, se
denominan MIDLets. Las clases de un MIDLet, son almacenadas en bytecodes java,
dentro de un fichero .class. Estas clases, deben ser verificadas antes de su puesta en
marcha para garantizar que no realizan ninguna operación no permitida. Este
preverificación, se debe hacer debido a las limitaciones de la máquina virtual usada en
estos dispositivos (KVM). Para mantener esta máquina virtual lo más sencilla y pequeña
posible, se elimina esta verificación, y se realiza antes de la entrada en producción. La
preverificación se realiza después de la compilación, y el resultado es una nueva clase,
lista para ser puesta en producción. Los MIDLets, son empaquetados en ficheros .jar. Se
requiere alguna información extra, para la puesta en marcha de las aplicaciones. Esta
información se almacena en el fichero de manifiesto, que va incluido en el fichero .jar y
en un fichero descriptor, con extensión .jad. Un fichero .jar típico, por tanto, se
compondrá de:
• Clases del MIDLet
• Clases de soporte
• Recursos (imágenes, sonidos...)
• Manifiesto (fichero “.mf”)
• Descriptor (fichero “.jad”)

Un fichero .jar puede contener varios MIDLets. Esta colección de MIDLets, se

suele llamar MIDLet Suite. Esta unión de varios MIDLets en una distribución, permite
compartir recursos tales como imágenes o sonidos y, por tanto, optimizar los recursos
del dispositivo.

Un MIDlet durante su ejecución pasa por 3 estados diferentes:

• Activo: el MIDlet está actualmente en ejecución.
• Pausa: El MIDlet no está actualmente en ejecución. En este estado el MIDlet no
debe usar ningún recurso compartido. Para volver a pasar a ejecución tiene que
cambiar su estado a Activo.
• Destruido: El MIDlet no está en ejecución ni puede transitar a otro estado.
Además se liberan todos los recursos ocupados por el MIDlet.

Figura. Estados de un MIDlet.

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 7

 Como vemos en el diagrama, un MIDlet puede cambiar de estado mediante una
llamada a los métodos MIDlet.startApp(), MIDlet.pauseApp() o MIDlet.destroyApp().
El gestor de aplicaciones (AMS) cambia el estado de los MIDlets haciendo una llamada
a cualquiera de los métodos anteriores. Un MIDlet también puede cambiar de estado por
sí mismo.

Ahora vamos a ver por los estados que pasa un MIDlet durante una ejecución típica y
cuáles son las acciones que realiza tanto el AMS como el MIDlet. En primer lugar, se
realiza la llamada al constructor del MIDlet pasando éste al estado de Pausa durante un
corto período de tiempo. El AMS por su parte crea una nueva instancia del MIDlet.
Cuándo el dispositivo está preparado para ejecutar el MIDlet, el AMS invoca al método
MIDlet.startApp() para entrar en el estado de Activo. El MIDlet entonces, ocupa todos
los recursos que necesita para su ejecución. Durante este estado, el MIDlet puede pasar
al estado de Pausa por una acción del usuario, o bien, por el AMS que reduciría en todo
lo posible el uso de los recursos del dispositivo por parte del MIDlet. Tanto en el estado
Activo como en el de Pausa, el MIDlet puede pasar al estado Destruido realizando una
llamada al método MIDlet.destroyApp(). Esto puede ocurrir porque el MIDlet haya
finalizado su ejecución o porque una aplicación prioritaria necesite ser ejecutada en
memoria en lugar del MIDlet. Una vez destruido el MIDlet, éste libera todos los
recursos ocupados.

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 8

3. HERRAMIENTAS DE DESARROLLO
En el mercado existen varias herramientas que nos pueden ayudar a la hora de
crear nuestros MIDlets. En este tutorial vamos a hacer uso de un par de ellas que
explicaremos a continuación:
1. La primera de ellas es un entorno de desarrollo de Java con un emulador
integrado, el Sun One Studio Mobile Edition. Este entorno es exactamente igual
al Sun One Studio, pero incluye un emulador con el que podemos ver la
ejecución de nuestros MIDlets, además de incluir las APIs propias de la
configuración CLDC y el perfil MIDP (Mobile Edition).

2. La segunda herramienta es el J2ME Wireless Toolkit 2.0 que es simplemente

un emulador al que le proporcionamos las clases java ya creadas y podemos ver
el MIDlet en ejecución.

3.1 Desarrollo de aplicaciones en el Sun One Studio Mobile Edition

Una vez instalado el Sun One Studio Mobile Edition, nos aparecerá un entorno
basado en ventanas donde podremos desarrollar y compilar nuestro MIDlet.

Figura. Aspecto del Sun One Studio Mobile Edition.

En esta herramienta es posible realizar todas las fases del desarrollo de

aplicaciones MIDP:
• Disponemos de un editor de texto totalmente integrado donde crear el código
fuente.
• Una vez creado el código del MIDlet es posible su compilación ya que el
entorno dispone de todas las librerías necesarias para ello.
• El proceso de preverificación se realiza automáticamente después de la
compilación.
• El entorno también nos da la posibilidad de empaquetar el MIDlet por separado
o dentro de una MIDlet suite.
• Por último, las fases de ejecución y depuración también la podemos realizar
con esta herramienta ya que nos permitirá ejecutar el MIDlet sobre un emulador,

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 9

 ya que trae integrada la herramienta J2ME Wireless Toolkit 1.0.4. Es posible
sustituirla por la 2.2 con objeto de utilizar ciertas extensiones que esta última
incorpora. Como vemos, esta herramienta engloba todas las fases de desarrollo
en un mismo entorno.

3.2 Desarrollo de aplicaciones con el J2ME Wireless Toolkit 2.2

Se trata de una plataforma ideada por Sun Microsystems cuya última versión salió al
mercado a finales de octubre de 2004. Es un conjunto de herramientas que hace posible
crear aplicaciones para teléfonos móviles y otros dispositivos inalámbricos. Aunque está
basado en MIDP 2.0 (Mobile Information Device Profile), la J2 Wireless Toolkit
también trae una amplia colección de paquetes opcionales que lo convierten en una
herramienta de desarrollo bastante potente.

3.2.1 Componentes.
• Ktoolbar: que automatiza la mayor parte de las tareas involucradas en la
creación de aplicaciones MIDP. Es el centro de la aplicación y se puede usar
para construir aplicaciones, lanzar el emulador y empezar las utilidades.
• Emulator: se trata de una simulación de un teléfono móvil. Sobre él se evalúan
las aplicaciones MIDP.
• Una colección de utilidades que proporciona otros servicios igualmente útiles,
como pueden ser utilidades de criptografía o una consola de mensajes.

3.2.2 Características.
La J2ME Wireless Toolkit permite la creación de aplicaciones MIDP con las
siguientes características principales.
• Building and packaging: el usuario sólo debe escribir el código y la
herramienta de ocupa del resto, ya que ella compila, preverifica los ficheros de
clases y empaqueta un MIDlet suite.
• Running and monitoring: se puede ejecutar el MIDlet directamente en el
emulador o instalarlo usando un proceso que se parece a la instalación de una
aplicación en un dispositivo real.
• MIDlet suite signing: contiene herramientas para firmar criptográficamente los
MIDlet, hecho que resulta de gran utilidad.

3.2.3 Uso.
Al arrancar la Ktoolbar nos encontramos con una ventana con un aspecto tal que:

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 10

 Se trata de un entorno muy simple que ni siquiera aporta un editor de texto. Por
tanto, el código deberemos escribirlo en cualquier editor de texto pasárselo a la
Ktoolbar de una manera bastante particular como veremos a continuación.

Si hacemos click en el botton de New project, nos aparecerá una ventana en el

que tendremos que definir el nombre del proyecto que queremos crear así como el
nombre de su MIDlet.

Al hacer esto, nos saldrá una pantalla en la que podremos escoger multitud de
propiedades y característias propias de la aplicación que queremos desarrollar. La
pantalla que muestra por defecto es:

Figura. Menú de opciones de las aplicaciones.

Y, finalmente, nos dice los directorios que ha creado automáticamente donde

deberán guardarse los ficheros. Este aspecto es especialmente crítico, ya que los
ficheros deberemos colocarnos nosotros manualmente en dichos directorios.

Figura. Organización de los directorios.

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 11

4. EJEMPLO

En esta sección vamos a describir una pequeña aplicación desarrollada para

poner de manifiesto los conocimientos adquiridos. En concreto, hemos realizado una
aplicación que nos permite navegar por diferentes formularios y que nos ofrece la
posibilidad de desplegar un menú.

Mostramos los pasos que se siguieron así como los resultados visuales que se
obtienen de la ejecución del mismo.

Como vemos, al lanzar (launch) la aplicación podemos seleccionar en un menú

dos opciones: alerta modal y alerta no modal. La primera de ellas, permanecerá en
pantalla hasta que el usuario pulse un botón. Sin embargo, la segunda desaparecerá
automáticamente una vez que transcurren cinco segundos.

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 12

5. ANEXO: CÓDIGO.
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class EjemploAlerta extends MIDlet implements CommandListener
{
Alert alerta1,alerta2;
Command salir, aler1, aler2;
Displayable temp;
Display pantalla;
Form pantallainicial;

public EjemploAlerta()
{
// Obtengo la referencia a la pantalla del MIDlet
pantalla = Display.getDisplay(this);

// Creo los objetos que forman las pantallas del MIDlet

salir = new Command("Salir",Command.EXIT,1);
aler1 = new Command("Alerta Modal",Command.SCREEN,1);
aler2 = new Command("Alerta No Modal",Command.SCREEN,1);

// Creo la pantalla de alerta 1

alerta1 = new Alert("Alerta Modal","Esta alerta desaparecerá"+"cuando pulses el botón de
aceptar", null, AlertType.INFO);

// Creo la pantalla de alerta 2

alerta2 = new Alert("Alerta No Modal","Esta alerta desaparecera"+" cuando pasen 5
segundos",null,AlertType.INFO);
alerta1.setTimeout(Alert.FOREVER);
alerta2.setTimeout(5000);

// Creo la pantalla principal del MIDlet

pantallainicial = new Form("Programa principal");

// Inserto objetos en la pantalla

pantallainicial.addCommand(salir);
pantallainicial.addCommand(aler1);
pantallainicial.addCommand(aler2);
pantallainicial.setCommandListener(this);
}

public void startApp()

{
pantalla.setCurrent(pantallainicial);
}

public void pauseApp() {}

public void destroyApp(boolean unconditional) {}

public void commandAction(Command c, Displayable d)

{
if (c == salir)
{
destroyApp(false);
notifyDestroyed();
}
else if (c == aler1)
{
pantalla.setCurrent(alerta1,pantallainicial); //Método sobrecargado de
} // la clase Display. Primero muestra un objeto del
else
{ //tipo Alert y a continuación un Displayable.
pantalla.setCurrent(alerta2,pantallainicial);
}
}
}

DESARROLLO DE APLICACIONES JAVA PARA MÓVILES / 13