introducción a j2me - unid · académicas y empresas de software, electrónica, telefonía móvil,...

Introducción a J2ME

Felipe Vidueira Estévez

Departamento de Ciencias de la Computación de la Universidad de Alcalá

1. INTRODUCCIÓN. ..................................................................................... 4

2. COMPONENTES DE J2ME...................................................................... 7

2.1. Máquina virtual ..............................................................................................................................8

2.2. Configuración .................................................................................................................................8

2.3. Perfil ................................................................................................................................................8

3. ESTANDARIZACIÓN DE COMPONENTES J2ME................................. 10

3.1. Ciclo de vida de una JSR .............................................................................................................10

3.2. Compatibilidad entre componentes ............................................................................................11

4. ARQUITECTURA J2ME ......................................................................... 12

4.1. Máquinas virtuales .......................................................................................................................13 4.1.1. C Virtual Machine ..................................................................................................13 4.1.2. K Virtual Machine..................................................................................................14

4.2. Configuraciones ............................................................................................................................15 4.2.1. Connected Device Configuration...................................................................15 4.2.2. Connected Limited Device Configuration................................................15

4.3. Perfiles ...........................................................................................................................................17 4.3.1. Foundation Profile ..................................................................................................17 4.3.2. Personal Profile ........................................................................................................17 4.3.3. Mobile Information Device Profile ..............................................................18

5 INSTALACIÓN........................................................................................... 20

5.1 WINDOWS ...................................................................................................................................20

6 UN PRIMER EJEMPLO ............................................................................. 24

7 PAQUETES Y CLASES PRINCIPALES.................................................... 30

7.1 JAVAX.MICROEDITON.MIDLET...........................................................................................30

7.2 JAVAX.MICROEDTION.LCDUI..............................................................................................31

Charla J2ME Departamento de Ciencias de la Computación

2

7.3 ALMACENAMIENTO DE DATOS...........................................................................................37

7.4 COMUNICACIONES DE RED MEDIANTE J2ME MIDP ....................................................39

8 BIBLIOGRAFÍA ......................................................................................... 42

9 DIRECCIONES DE INTERÉS .................................................................... 42


3

1. Introducción.

La empresa Sun Microsystems lanzó a mediados de los años 90 el lenguaje de programación Java, orientado en un principio a la creación de componentes interactivos embebidos en páginas HTML, y que presentaba las siguientes características: • Inspirado inicialmente en C++, pero con adiciones de alto nivel, como soporte nativo de

strings y garbage collection.

• Código independiente de plataforma, precompilado a bytecode intermedio y ejecutado en el

cliente por una JVM (Java Virtual Machine).

• Modelo de seguridad tipo sandbox proporcionada por la JVM.

• Abstracción del sistema operativo subyacente mediante un juego completo de APIs de

programación.

Con el curso de los años, Java ha progresado enormemente en dos dimensiones:

• Nuevos ámbitos de ejecución: Programas aislados, servicios HTTP (servlets, JSP),

servidores de aplicaciones (EJB).

• Mayores y más diversas funcionalidades: APIs para acceso a bases de datos (JDBC),

telefonía (JTAPI), multimedia (JMF), mensajería (JMS), transacciones (JTS).

De resultas de esta explosión tecnológica, en la actualidad es poco realista concebir Java como

un simple lenguaje de programación; en su lugar, resulta más conveniente considerarlo como

un conjunto de tecnologías diseminadas en todos los ámbitos de computación con dos

elementos comunes:

• El código fuente en lenguaje Java es compilado a código intermedio interpretado por una

JVM.

• Todas las tecnologías comparten un conjunto más o menos amplio de APIs básicas del

lenguaje, agrupadas principalmente en los paquete java.lang y java.io.

En el mundo de los dispositivos electrónicos, como teléfonos móviles, PDAs o dispositivos

embebidos, la situación es aún más caótica, debido a que las plataformas en consideración son

fuertemente disimilares en cuanto a capacidad y requisitos. Han surgido en el pasado

numerosas iniciativas, con frecuencia incompatibles entre sí, para introducir Java en el

desarrollo de aplicaciones para estos dispositivos.


4

En los últimos tiempos, Sun ha reconocido esta diversidad de ámbitos tecnológicos en los que

Java se desenvuelve, y los ha agrupado en tres grandes entornos de aplicación, o ediciones,

por seguir la terminología de la empresa:


5

• J2EE (Java 2 Platform, Enterprise Edition), orientada al desarrollo de servicios web y

aplicaciones distribuidas mediante EJBs (Enterprise Java Beans) y tecnologías

relacionadas, con APIs para la gestión de transacciones, persistencia de objetos, servicios

de nombres, XML, autentificación, etc.

• J2SE (Java 2 Platform, Standard Edition), que abarca las APIs orientadas a la

programación de aplicaciones de usuario final: interfaz gráfica de usuario, multimedia,

networking. Esta edición es la que en cierta forma recoge la iniciativa original del lenguaje

Java.

• J2ME (Java 2 Platform, Micro Edition), 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.

Figura 1: Relaciones entre ediciones de Java.

Sólo de forma muy simplista puede considerarse que J2ME y J2EE son versiones reducida y

ampliada, respectivamente, de J2SE: en realidad, cada una de las ediciones enfoca ámbitos de

aplicación radicalmente distintos e independientes entre sí. Después de todos, las necesidades

computacionales y APIs de programación requeridas por, por ejemplo, un juego gráfico

ejecutándose sobre una PDA no tienen mucho que ver con los de un servidor distribuido de

aplicaciones basado en EJB.

En lo que sigue estudiaremos con más detalle los componentes que integran la plataforma

J2ME, la taxonomía propuesta por Sun de entornos de ejecución basados en las capacidades

gráficas y computacionales de los dispositivos y la funcionalidad para la que están diseñados,

la integración en J2ME de otras tecnologías Java relacionadas y la relevancia de la iniciativa

J2ME para el desarrollo de aplicaciones y servicios embebidos en dispositivos móviles 2,5 y

3G.


6

2. Componentes de J2ME Al contrario que en otras tecnologías orientadas a PCs y ordenadores convencionales, en

J2ME el espectro de dispositivos considerados varía enormemente en cuanto a capacidad

computacional, memoria y capacidades gráficas. Ante la imposibilidad de establecer una

arquitectura común que se adecue a esta variedad de entornos hardware, J2ME define una

serie de componentes (building blocks) a partir de los cuales se construye una implantación

concreta para un dispositivo determinado. Estos componentes se agrupan en los siguientes

tipos:

• Máquina virtual

• Configuración

• Perfil

• Paquetes opcionales.

Un entorno de ejecución determinado de J2ME se compone entonces de una selección de

máquina virtual, configuración y perfil, y posiblemente otros paquetes opcionales. En la figura

se muestran las relaciones entre los distintos componentes de un entorno de ejecución de

J2ME.

Figura 2: Relaciones entre componentes J2ME.

sistema operativo subyacente

máquina virtual

configuración

perfilpaquetes

opcionales

aplicaciones

J2ME


7

2.1. Máquina virtual

Una máquina virtual de Java (JVM, Java Virtual Machine) es un programa encargado de

traducir código intermedio (bytecode) de los programas Java precompilados a código máquina

ejecutable por la plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente

y observar las reglas de seguridad y corrección de código definidas para el lenguaje Java. De

esta forma, la JVM proporciona al programa Java independencia de la plataforma con respecto

al hardware y al sistema operativo subyacente.

Las implementaciones tradicionales de JVMs son en general muy pesadas en cuanto a

memoria ocupada (footprint) y requerimientos computacionales. J2ME define varias JVMs de

referencia adecuadas al ámbito de los dispositivos electrónicos, que en algunos casos se

apartan de la especificación estándar relajando algunas exigencias con el fin de obtener

implementaciones más ligeras.

2.2. Configuración

Una configuración es un conjunto de APIs básicas de Java que definen un entorno

generalizado de ejecución. Una configuración no está orientada a ningún campo específico de

aplicación, sino que más bien trata de agrupar los dispositivos en cuanto a sus capacidades

computacionales y entorno genérico de operación (por ejemplo, si tienen conectividad o no). En

particular, las librerías de interfaz gráfica nunca pertenecen a la definición de una configuración

J2ME.

Usualmente, una configuración especifica una JVM de referencia sobre la que debe correr; en

algunos casos, además, esta JVM se aparta del estándar, relajando algunas características.

Esta JVM de referencia no es una exigencia de la configuración, sino que más bien establece

la funcionalidad mínima que debe pedirse a las implementaciones de la JVM utilizadas. Por

supuesto, una implementación inteligente de una configuración J2ME dada se ceñirá en la

medida de lo posible a las especificaciones mínimas requeridas.

2.3. Perfil


8

Un perfil es un conjunto de APIs orientadas a un ámbito de aplicación determinado, para una

configuración J2ME dada. Los perfiles identifican un grupo de dispositivos por la funcionalidad

que proveen (por ejemplo, teléfonos móviles, electrodomésticos) y el tipo de aplicaciones que

típicamente correrán sobre ellos.

La librería de interfaz gráfica es generalmente una componente muy importante de la definición

de un perfil. Las interfaces gráficas difieren mucho entre distintos perfiles (displays textuales en

teléfonos móviles, interfaces basadas en pen para PDAs, etc.), y en algunos perfiles ni siquiera

existen (sistemas embebidos, por ejemplo).

Un perfil siempre se define a partir de una configuración dada. Así, cabe pensar en un perfil

como un conjunto de APIs que dotan a una configuración J2ME de funcionalidad específica

para una familia de dispositivos concreta y para un tipo de aplicaciones determinado.


9

3. Estandarización de componentes J2ME

La intencionada indefinición en cuanto a especificación y selección de componentes de la

arquitectura J2ME podría dar lugar a la proliferación de numerosos entornos de ejecución

incompatibles y pseudo propietarios de no mediar alguna clase de esfuerzo coordinado de

estandarización en el seno de la industria de los dispositivos electrónicos.

Con el fin de involucrar a la industria software y hardware en la evolución y el soporte de la

tecnología Java, Sun ha creado el programa Java Community Process (JCP), un foro de

estandarización con aproximadamente 300 participantes entre particulares, instituciones

académicas y empresas de software, electrónica, telefonía móvil, comunicaciones, etc.

Notablemente, ni Microsoft ni Intel pertenecen al programa JCP. El trabajo del programa JCP

se articula en torno a la producción y aprobación de documentos de estándar conocidos como

JSRs (Java Specification Requests), similares en forma e intención a las RFCs de la IETF.

Uno de los campos de actividad del programa JCP es la especificación de componentes de

J2ME, con el objetivo de llegar a un consenso amplio en torno a un número razonablemente

pequeño de entornos de ejecución de J2ME agrupados por mercados de aplicación bien

definidos, como el de las PDAs o el de la telefonía móvil. De los esfuerzos del programa JCP

han surgido ya componentes estandarizados de J2ME, con diferentes grados de aceptación e

implantación en la industria.

3.1. Ciclo de vida de una JSR

En la Figura 3 se definen los sucesivos estadios por los que una Java Specification Request

(JSR) atraviesa hasta que se convierte en un estándar aprobado (Final Release). Estos

estadios van desde la aprobación del comienzo de la JSR y la formación de un grupo de

trabajo hasta la publicación del Final Draft y la aprobación final del mismo.

En la figura se muestra el ciclo de vida de una JSR junto con las estimaciones temporales de

algunos procesos críticos en la evolución del proyecto. Esta información puede ser útil a la hora

de evaluar el tiempo que resta para que un estándar en progreso sea completado por el JCP.


10

Figura 3: Ciclo de vida de una JSR.

Com

mun

ity R

evie

w

Publ

ic R

evie

w

Fina

l Dra

ft Pr

opos

al

Fina

l Rel

ease

Bal

lot

Fina

l Rel

ease

Mai

nten

ance

Rev

iew

14 daysEC vote

Expert GroupFormed

30-90 days

Last 7 daysfor EC vote

30-90 days 14 daysEC vote

30 days

Last 7 days for ECItem Exception vote

EC: Executive Committee

JSR

Rev

iew

3.2. Compatibilidad entre componentes

Ante la multiplicidad de entornos de ejecución que presenta J2ME, el antiguo lema “Write

Once, Run Anywhere” asociado al lenguaje Java no parece muy aplicable en el mundo de los

dispositivos electrónicos. Esto difícilmente puede verse como una debilidad de la plataforma

J2ME, teniendo en cuenta la enorme variedad de dispositivos y ámbitos de aplicación que esta

tecnología abarca.

En general, los desarrolladores de aplicaciones para J2ME pueden esperar y deberían

promover la compatibilidad entre plataformas dentro del ámbito de un mismo perfil. De esta

forma, las aplicaciones para teléfonos móviles 2,5G, por ejemplo, deberían poder correr en

todos aquellos dispositivos que soporten el perfil MIDP.

Otras compatibilidades cruzadas, como entre perfiles más limitados y menos limitados, en

general no están garantizadas, y lo máximo que puede esperarse en este campo es que al

menos grandes porciones de código puedan utilizarse en proyectos basados en distintos

entornos J2ME.


11

4. Arquitectura J2ME

Como se ha explicado anteriormente, el programa de estandarización JCP ha definido diversos

entornos de ejecución de J2ME identificados por una selección particular de máquina virtual,

configuración y perfil J2ME. Es de suponer que esta arquitectura evolucionará en dos sentidos:

Refinamiento de los entornos de ejecución definidos (nuevas versiones de los componentes),

definición de nuevos entornos de ejecución.

Figura 3: Arquitectura de J2ME.

CVM KVM

CDC CLDC Configuraciones

Máquinasvirtuales

FP PDAP MIDP PerfilesPP

En la figura se muestra el estado actual de la arquitectura J2ME. Solamente se han incluido en

el diagrama los componentes de J2ME que están estandarizados o muy próximos a ser

estandarizados y que tienen especial relevancia para el mercado de los dispositivos para

comunicaciones móviles.

Así como en el campo de los perfiles la arquitectura de J2ME es aún dispersa y está sujeta a

cambios, parece que se ha alcanzado un consenso bastante estable en cuanto a las dos

configuraciones disponibles:

• Connected Device Configuration (CDC), para dispositivos dotados de conectividad y con

(relativamente) alta capacidad computacional,

• Connected Limited Device Configuration (CLDC), para dispositivos con capacidades

(proceso y memoria) limitadas dotados de conectividad.

En la Figura 4 se relacionan unos cuantos tipos de dispositivos con la configuración más

apropiada para los mismos.


12

Figura 4: Relación de configuraciones con tipos de dispositivos

4.1. Máquinas virtuales

4.1.1. C Virtual Machine La C Virtual Machine (CVM) es una implementación de referencia escrita en lenguaje C de la

máquina virtual de Java (JVM) estándar, orientada a dispositivos electrónicos con

procesadores de 32 bits de gama alta y en torno a 2 MB o más de memoria RAM. Según Sun,

la CVM está diseñada de forma que su portado a distintos sistemas operativos y/o

procesadores sea relativamente fácil, lo cual debe ayudar a extender las configuraciones J2ME

basadas en una JVM estándar (no reducida). La ocupación en memoria (footprint) de la CVM

está en torno a los 256 KB.

En la actualidad, CVM tan sólo se encuentra disponible para el sistema operativo Linux sobre

procesadores Intel x86, pero Sun apoya el portado de la CVM a otras plataformas.


13

La liberación de la CVM obedece a una política de open source de Sun Microsystems

encaminada a promover la ubicuidad de Java, favoreciendo de esta forma la migración de la

tecnología Java a muchas más plataformas de las que en principio una sola empresa podría

abarcar.

La CVM ha sido tomada como JVM de referencia en la definición de la CDC

4.1.2. K Virtual Machine

La K Virtual Machine ó KVM (la K viene de kilobyte, haciendo referencia a la baja ocupación en

memoria) se desarrolló en parte en el programa de investigación Spotless de Sun

Microsystems dedicado a la implementación de un sistema Java para el Organizer de Palm. Se

trata de una implementación de referencia para una JVM reducida especialmente orientada a

dispositivos con bajas capacidades computacionales y memoria limitada. En concreto, la KVM

presenta las siguientes limitaciones (entre otras) con respecto a la especificación estándar de

la JVM:

• No hay soporte para tipos de coma flotante (float y double).

• No hay soporte para métodos nativos (Java Native Interface, JNI).

• No se soporta la reflexión de clases.

• No se soporte la finalización de objetos (método Object.finalize()).

• Tratamiento limitado de excepciones.

Además, el sistema de seguridad de la JVM ha sido simplificado y modificado para

ajustarse a limitaciones computacionales y de memoria más estrictas.

La KVM está escrita en lenguaje C y, según Sun, en mayo de 2000 había sido portada al

menos a 25 plataformas distintas, entre las que se encuentran:

• Palm OS,

• Win32,

• Solaris.

A fecha actual, los autores no conocen ninguna versión para Windows CE de la KVM, aunque

los dispositivos típicos sobre los que corre Windows CE tienen potencia suficiente para ejecutar

una JVM estándar.

La ocupación en memoria (footprint) de la KVM oscila entre los 40 y los 80 KB.

La KVM ha sido tomada como JVM de referencia en la definición de la CLDC

Las primeras versiones de la KVM se incluyeron así mismo en las distribuciones de KJava.


14

4.2. Configuraciones

4.2.1. Connected Device Configuration

La configuración J2ME conocida como Connected Device Configuration (CDC) está siendo

elaborada dentro de la JSR 36 del JCP; la versión 0.2 alcanzó el estatus de Final Draft el 21 de

febrero de 2001.

La CDC está orientada a dispositivos electrónicos con las siguientes capacidades:

• Procesador de 32 bits.

• 512 KB mínimo de memoria ROM.

• 256 KB mínimo de memoria RAM.

• Conectividad a algún tipo de red.

• Soporte total de la JVM v.2

Como ya se ha explicado, la CDC no se hace ninguna asunción acerca de las capacidades

gráficas de los dispositivos. Dispositivos típicos a los que la CDC se orienta son:

• Descodificadores de TV,

• teléfonos con navegación de Internet (communicators),

• sistemas de navegación para coches.

Como se ha dicho, la CDC corre sobre una JVM estándar; no obstante, las implementaciones

de referencia, desarrolladas para los sistemas Linux y VxWorks, utilizan la CVM.

La CDC está basada en J2SE v1.3, e incluye varios paquetes Java de la edición estándar. Las

peculiaridades de la CDC están principalmente contenidas en el paquete javax.microedition.io,

que incluye soporte genérico para comunicaciones HTTP y comunicaciones basadas en

datagramas.

Un aspecto importante de la CDC es que engloba totalmente las APIs de la CLDC.

4.2.2. Connected Limited Device Configuration

La configuración J2ME conocida como Connected Limited Device Configuration (CLDC) está

siendo elaborada dentro de la JSR 30 del JCP; la versión 1.0 alcanzó el estatus de Final

Release el 30 de mayo de 2000.


15

La CLDC está orientada a dispositivos dotados de conectividad con reducidas capacidades

computacionales y memoria limitada, de acuerdo a los siguientes parámetros:

• Procesador de bajas prestaciones, posiblemente de 16 bits.

• De 128 a 512 KB de memoria total, incluyendo ROM/Flash y RAM.

• Potencia limitada, frecuentemente alimentados por baterías.

• Conectividad reducida (9600 bps o menos), como en el caso de GSM.

Entre los dispositivos a los que la CLDC se orienta tenemos:

• PDAs de bajas prestaciones (tipo Palm),

• teléfonos móviles GSM y 2,5G (GPRS).

• buscas (pagers),

• terminales de transacciones electrónicas.

Con objeto de adaptarse a las restrictivas capacidades de este tipo de dispositivos, la CLDC no

opera sobre una JVM estándar, sino que define un subconjunto de ésta conocido como KVM.

En cuanto a las APIs incluidas, parte de ellas provienen de la edición estándar de Java (J2SE),

y además se incluyen unas APIs genéricas de conectividad en el paquete javax.microedition.io.

Todas las APIs de la CLDC están también contenidas en la CDC.

CLDC para Palm

Posiblemente, la implementación más popular actualmente de CLDC/KVM es la del Palm

Connected Organizer, que actualmente ya está siendo usada para desarrollo de pequeñas

aplicaciones en este dispositivo.

Una característica interesante de la distribución que hace Sun de CLDC/KVM para Palm es que

incorpora una pequeña librería no estándar denominada Palm API para gestión de la interfaz

gráfica de la Palm. De esta forma es posible desarrollar aplicaciones gráficas para Palm

directamente sobre CLDC/KVM sin instalar ningún perfil J2ME (los cuales, según los filosofía

de la arquitectura, son los encargados de especificar las interfaces gráficas). La Palm API está

contenida en el paquete com.sun.kjava, proveniente de la tecnología pre-J2ME KJava. Sun

efectúa esta distribución no estándar de CLDC/KVM con el objeto de proporcionar soporte y

continuidad a los desarrolladores de KJava.


16

4.3. Perfiles

4.3.1. Foundation Profile

El perfil J2ME conocido como Foundation Profile (FP) está siendo elaborado dentro de la JSR

46 del JCP; la versión 0.2 alcanzó el estatus de Final Draft el 21 de febrero de 2001.

El FP define una serie de APIs sobre la CDC para dispositivos sin interfaz gráfica dentro del

rango de aplicabilidad de la CDC, esto es, algún tipo de conectividad y potencia y memoria

suficiente (1024 KB ROM, 512 KB RAM).

El mismo nombre del FP sugiere que este perfil incorpora muy poca funcionalidad específica, y

en la mayor parte de los casos se espera que esté complementado por paquetes opcionales, o

que sea extendido a otro perfil. Se añaden al API de la CDC tres nuevos paquetes y 130 clases

adicionales, con funcionalidades variadas.

4.3.2. Personal Profile

El Personal Profile (PP) de J2ME está siendo elaborado dentro de la JSR 62 del JCP;

actualmente, está en el estado JSR Approved, esto es, en fase de definición. El PP se definirá

a partir de FP/CDC y añade una interfaz gráfica completa, con capacidades web y soporte de

applets Java.

En la actualidad no hay mucha información disponible sobre el PP. La principal motivación para

crear este perfil es la de ofrecer una vía de migración a J2ME de la tecnología PersonalJava

PDA Profile

El perfil para PDAs (PDAP) de J2ME está siendo elaborado dentro del marco de la JSR 75 del

JCP, y en la actualidad está en el estado JSR Approved, esto es, en fase de definición. PDAP

se basa en la CLDC y pretende abarcar PDAs de gama baja, tipo Palm, con una pantalla y

algún tipo de puntero (ratón o pen) y una resolución de al menos 20.000 pixels (esto es, de al

menos 200×100 pixels para un factor de forma típico 2:1).

Actualmente, no es posible dar mucha más información sobre este perfil en vías de definición.

La principal motivación para crear este perfil es la de ofrecer una vía de migración a J2ME de la

tecnología KJava.


17

4.3.3. Mobile Information Device Profile

El Mobile Information Device Profile de J2ME (MIDP) ha sido desarrollado dentro de la JSR 37

del JCP, que aprobó la Final Release de la versión 1.0 el 19 de septiembre de 2000.

El MIDP se basa en CLDC/KVM y se orienta a dispositivos con las siguientes características:

• Reducida potencia computacional y memoria.

• Conectividad limitada (como la provista por las redes celulares actuales, en torno a 9600

bps).

• Capacidades gráficas muy reducidas (mínimo un display de 96×54 pixels monocromo).

• Entrada de datos alfanuméricos reducida (p.ej., como la provista por los teléfonos móviles).

Los tipos de dispositivos que se adaptan entonces al MIDP son: Teléfonos móviles del rango

de los actuales teléfonos WAP, buscas bidireccionales (two-way pagers) y PDAs de gama baja

con conectividad celular.

El MIDP proporciona APIs que soportan la siguiente funcionalidad:

• Una forma limitada de almacenamiento de datos.

• Conectividad celular basada en HTTP 1.1.

• Timers.

• Presentación de imágenes de baja resolución.

• Entrada de datos de usuario.

• Un modelo rudimentario de ciclo de vida de las aplicaciones (llamadas midlets, por

simpatía con “applet”).

Estas APIs están contenidas en los paquetes específicos javax.microedition.rms (persistencia),

javax.microedition.midlet (ciclo de vida), y javax.microedition.lcdui (interfaz de usuario).

Sun proporciona una implementación de referencia basada en un emulador de MIDP para

Windows y un entorno completo de desarrollo para este mismo sistema operativo.


18

Figura: Ejemplos de aplicaciones MIDP (midlets) provistos por Sun: Selector, Sokoban,

La tecnología MIDP parece solaparse en cuanto al ámbito de aplicación con otra iniciativa de

Sun conocida como JavaPhone. La postura oficial de Sun al respecto es que JavaPhone está

orientada a dispositivos de mayores prestaciones que los que soportarán MIDP. En cualquier

caso, la comparación de requisitos para ambas tecnologías es complicada, puesto que

JavaPhone no está incluida en la arquitectura J2ME.

Se está desarrollando una nueva versión de MIDP, la llamada MIDP NG, y se prevee que

estará lista para principios del 2003.


19

5 INSTALACIÓN

5.1 WINDOWS Antes de comenzar a implementar un MIDLET se precisa tener instalado un software

determinado que constituirá el entorno desarrollo J2ME. Los componentes están disponibles en

http://www.java.sun.com y son los que se presentan a continuación:

• Java 2 SDK

• Entorno de desarrollo visual (opcional)

• J2ME Wireless Kit

Java 2 SDK, es el Kit de desarrollo estándar de Java que se emplea para diseñar aplicaciones

estándares. Este elemento debe ser el primero en instalarse ya que los siguientes se apoyan

en él. Se requiere la versión 1.3 o superior que encuentra disponible en el enlace

http://java.sun.com/j2se/1.3/download-windows.html.

J2MEWT se puede ejecutar individualmente o como un componente integrado en uno de los

siguientes entornos gráficos de desarrollo:

• _ KToolBar : Es el entorno visual de desarrollo que permite la creación de MIDLETS con

J2ME. Se considera el más simple de todos los aquí mencionados ya que ni siquiera

cuenta con un editor. Para incluir los fuentes editados con otro programa se debe haber

creado un proyecto desde KToolBar,

La herramienta crea la siguiente estructura de directorios dentro del proyecto.

En el directorio src se deben incluir los fuentes para que KToolBar los pueda compilar, pre-

verificar y posteriormente emular.


20

• Forte : Java: Se debe instalar antes que las J2MEWT, éste se puede descargar de la

página http://www.cun.com/forte/ffj/buy.html. Durante la instalación hay que seleccionar

la versión de JDK que se ha instalado.

• Los requisitos hardware de Forte Java son un Pentium II a 300 MHz, 128 MB y 30 MB

de espacio en disco. Este entorno provee un entorno de desarrollo para J2SE Y J2EE.

El entorno incluye un editor de texto de GUI, un buscador de clases y un buscador de

Web. El buscador de clases proporciona una vista gráfica de las clases que contiene el

MIDLET que se está desarrollando.

Utilizando este browser se puede navegar fácilmente por los métodos y atributos de las clases,

así como analizar la clase compilada almacenada en el .JAR .


21

• Code Warrior for Java: es un entorno visual que da soporte a J2ME , similar a Forte

Java, que cuenta con un editor de textos y un browser de clases. Este software se

puede adquirir en http://www.codewarrior.com/.

• Jbuilder Handheld Express: presenta las mismas opciones que Forte Java y Code

Warrior, soporta el entorno de desarrollo J2ME pero sólo para Palms, aunque se

espera que en breve se presente la versión que da soporte a móviles y agendas

personales. La página en la que se puede adquirir el software y obtener más

información es http://www.inprise.com/jbuilder/hhe/ .

J2ME Wireless Kit disponible para dos plataformas: Sun Solaris y Microsoft Windows, se puede

descargar en http://java.sun.com/ products/j2mewtoolkit/ download.html . A continuación se va

a comentar la instalación en Windows.

La versión Windows de la herramienta requiere un mínimo de 64MB y un espacio en disco de

15MB.


22

Se deben haber llevado a cabo los pasos anteriores, ya que si en la instalación se detecta que

no existe una versión de JDK no se permite continuar con la instalación. El entorno de


23

desarrollo es opcional. Si se desea trabajar con un entorno de desarrollo no se debe

seleccionar la opción de “Integrated”, sino la de “Stand Alone”.

Una vez completada la instalación se debe asegurar que todo está correctamente instalado.

Desde el promt de DOS vaya al directorio J2MEWTK_DIR\apps\ example\bin\, luego verá que

existe un fichero run.bat, ejecútelo y si la instalación tuvo éxito verá la pantalla de inicio de la

aplicación ejemplo que incluye el paquete.

Ahora ya está todo listo para comenzar.

6 UN PRIMER EJEMPLO Una vez superada la fase de instalación llegamos a la fase de creación de un primer programa.

Para ello basta disponer de un editor de texto cualquiera en el que se irá escribiendo el código

fuente que compilaremos bien desde el interfaz gráfico que el Wireless Toolkit ofrece o desde

la propia línea de comandos.

A continuación se detallan los pasos para hacer funcionar nuestro “primer programa”.

1.- Escribir el código fuente del programa, en este caso va a ser el HolaMundo.java.


24


25

Esta clase hereda de la clase MIDLET. En el constructor se capturan las características del

display, se crea una instancia de la clase Form , StringItem y del Comando que me permite

salir. Luego se añade la cadena y el comando de salida al formulario y se incluye el capturador

de eventos del comando, éste tiene una acción asociada que se ejecutará al pulsar sobre esta

opción.

2.- Compilar desde la línea de comandos:

C:\c:\jdk1.3\bin\javac -g:none

-bootclasspath %SUNJ2MEHOME%\lib\midpapi.zip

-classpath %SUNJ2MEHOME%\lib\kvem.jar

HolaMundo.java

Al utilizar el compilador de J2SE para compilar el ejemplo es necesario indicar de alguna

manera que las librerías CLDC y MIDP se encuentran en un lugar diferente. Esto se hace

mediante la opción –bootclasspath.

La opción –g:none se ha empleado para desactivar la posibilidad de incluir información en la

depuración, haciendo de este modo los ficheros .class más pequeños.

3.- Preverificar Cuando se trabaja con J2SE la máquina virtual Java (JVM) lleva a cabo un proceso de

verificación en tiempo de ejecución. Esto ocupa ciertos recursos que en dispositivos

inalámbricos son relativamente escasos. Debido a las restricciones de estos dispositivos se ha

creado en J2ME un proceso denominado preverification consistente en llevar a cabo parte de la

verificación de la KVM off-line, el resto será llevado a cabo como una verificación normal.

El comando utilizado es el siguiente:

C:\>%SUNJ2MEHOME%\bin\preverify.exe -classpath %SUNJ2MEHOME%\lib\midpapi.zip

-d c:\Ejemplos c:\Ejemplos

4.- Crear el fichero .jar

El siguiente paso consiste en empaquetar el Midlet en un MidletSuite, que es un simple fichero

.jar. Esto es un requerimiento por parte de muchos dispositivos MIDP. Para realizar este

proceso JDK1.3 dispone de la utilidad jar para archivar y comprimir ficheros .class en un

paquete.

C:\>c:\JDK1.3\bin\jar cmf MANIFIESTO.MF HolaMundo.jar HolaMundo.class

5.- Ejecutar el Midlet

Una vez dispuesto el Midlet dentro de un paquete llega la fase de ejecución. Para simplificar la

línea de comandos establecemos en primer lugar las variables de entorno necesarias.

C:\>set CODEPATH=c:\Ejemplos

C:\>set CLASSPATH=%SUNJ2MEHOME%\lib\kvem.jar;%SUNJ2MEHOME%\lib\kenv.zip;

%SUNJ2MEHOME%\lib\lime.jar;%CODEPATH%


26

A continuación se lanza el emulador para ejecutar el programa:

C:\c:\jdk1.3\bin\java.exe -Dkvem.home=%SUNJ2MEHOME%

-classpath %CLASSPATH% com.sun.kvem.midp.Main DefaultGrayPhone

-descriptor HolaMundo.jad


27


28

El resultado obtenido es el siguiente:

Finalmente se muestra un esquema de las fases anteriores


29

7 PAQUETES Y CLASES PRINCIPALES A lo largo de este apartado se comentan los paquetes lcdui y midlet así como sus clases más

importantes, siendo el resto explicados en apartados independientes.

Los principales paquetes de J2ME son los siguientes:

• javax.microediton.lcdui

• javax.microediton.midlet

• javax.microediton.rms

• javax.microediton.io

Se incluye una breve descripción de ciertos métodos en los casos que se considere relevante,

ya que no hay que perder de vista que el objetivo de este documento es iniciar, no ilustrar de

forma detallada, con lo que si en algún momento desea información más concreta remítase a la

ayuda online del perfil MIDP.

7.1 JAVAX.MICROEDITON.MIDLET

Un MIDlet es una aplicación de MIDP. La aplicación debe heredar de esta clase para que le

permita gestionar el control del software.

Un MIDLET tiene 3 estados que son activo, pasivo y destruido, éstos se corresponden con los

siguientes métodos:

• startApp( )- La aplicación inicialmente se encuentra en el estado “pausa”.A este método se

le puede llamar varias veces si entre medias se llama al método pauseApp()

• destroyApp( )- Mediante este método, la aplicación libera recursos.

• pauseApp( ) - Este método permite intercambiar el MIDLET que se está ejecutando,

pasándolo de activo a pasivo.


30

El administrador del entorno de ejecución de las aplicaciones es el que llama directamente a

estos métodos, ya que un MIDLET no cuenta con el método “main”.

El método de esta clase permite al gestor software de la aplicación crear, iniciar, pasar al

estado de pausa y destruir el MIDlet. Un MIDlet es el conjunto de clases diseñadas para ser

ejecutadas y controladas por la aplicación vía la interfaz. Se pueden tener varios MIDlets a la

vez, y seleccionar cual está activo en un tiempo concreto llamando al metodo startApp( ) y

ponerlo en pausa con la llamada a otro método, el pauseApp().

7.2 JAVAX.MICROEDTION.LCDUI

En el paquete javax.microedtion.lcdui se encuentran las clases que nos permiten desarrollar

una interfaz de usuario.

La clase pública Display representa el gestor de las entradas y salidas del dispositivo del

sistema. Por cada MIDlet se crea una instancia de Display y la aplicación hace referencia a

esta instancia con la llamada al método getDisplay(). La aplicación llama a este método desde

startApp(). La clase Displayable es una superclase de todas las pantallas que se pueden

poner en el Display.


31

La clase Displayable tiene dos descendientes directos , Screen y Canvas.

La principal abstracción de la interfaz de usuario de MIDP es la pantalla, instancia de la clase

Screen. Una pantalla es un objeto que encapsula las especificaciones gráficas del dispositivo.

Este objeto captura todos los eventos que tienen lugar cuando el usuario está navegando por

su pantalla.

La aplicación puede cambiar de pantalla invocando al método Display.setCurrent (Displayable).

Esta clase presenta la posibilidad de incluir un título para la pantalla y un Ticker, para ello

cuenta con los métodos getTitle(), setTitle(String), getTicker(), setTicker(Ticker).

Para incluir elementos (deben ser del tipo Item) dentro de una pantalla hace falta un

contenedor, que viene representado por la clase Form.

Los métodos principales de esta clase, que son los que permiten trabajar con Items, realizan

funciones tales como la inserción, borrado y obtención de un Item.

Se presentan a continuación:

• int append(Item elemento)

• void insert(int index,Item elemento)

• get(Item)

• set(int index, Item elemento)

• delete(int index)

Otro elemento que se puede incluir en un objeto Screen es un mensaje informativo para el

usuario, teniendo la posibilidad de definir la duración del mismo en pantalla, esto se consigue

instanciando la clase Alert.


32

Alert(String titulo,String texto, Image imagen, AlertType a)

El primer parámetro que se incluye en el constructor de esta clase es el título que se asocia al

mensaje a visualizar. En el parámetro texto se incluye el contenido a mostrar por pantalla, el

mensaje propiamente dicho. El parámetro imagen es la imagen que se va a incluir en el

mensaje, aunque se puede obviar poniéndolo a nulo. Por último el parámetro AlertType indica

el tipo al que corresponde este mensaje, éstos pueden ser:

• Alarm

• Confirmation

• Error

• Info

• Warning

El método más destacable de esta clase es el que permite determinar el tiempo que

permanecerá en pantalla el mensaje que es setTimeout(int time). A continuación se muestra como crear un objeto Alert, su asignación de tiempo y la

visualización en pantalla.

List(String titulo,int tipolista,String[] Elementos, Image[] imágenes) Los elementos que se van a incluir en la lista así como las imágenes que se relacionan con los

mismos se pasan al método como un array.

A continuación se presenta una clase que crea una lista y la inicializa con los valores "Opcion

A","Opcion B","Opcion C".


33


34

La clase TextBox implementa un componente de texto que rellena toda la pantalla. El

constructor nos permite incluir el título, un texto inicial, el tamaño máximo de caracteres que se

pueden incluir en ese TextBox, así como las restricciones del tipo de datos que se pueden

incluir.

Las restricciones son las siguientes:

• ANY - no impone restricciones en el tipo de texto a incluir

• EMAILATOR - sólo se permite incluir direcciones de e-mail

• NUMERIC – los datos han de ser de tipo numérico

• PASSWORD – este tipo enmascara los caracteres que se introducen

• PHONENUMBER – permite incluir exclusivamente números de teléfono

• URL – permite la inserción de URLs

En el API de MIDP también están incluidos los componentes que derivan de la clase Item y

ChoiceGroup.


35

La clase StringItem representa un elemento que contiene una cadena de texto, y cuenta con

dos de métodos para coger y devolver el valor de la cadena.

Para representar imágenes se cuenta con la clase ImageItem.

A continuación se presenta un ejemplo en el que se trabaja con la clase StringItem e

ImageItem. Primero se crean y se inicializan la pantalla, el formulario, los comandos y se crea

un elemento StringItem a cuyo constructor se le pasa la cadena que contiene, en este caso

“Bienvenido”. A continuación se crea una imagen indicando dónde se encuentra y

posteriormente se le pasa al constructor de ImageItem, junto con la ubicación que se quiere

que ocupe en la pantalla. Ya para finalizar se añade el objeto frase y dibujito, ambas instancias

de las clases StringItem e ImageItem, al formulario mediante la invocación al método

append(Item).

TextField presenta una ventana de texto que se incluye en un formulario. A diferencia de la

clase TextBox, se puede añadir a un formulario junto con otros elementos y no ocupa toda la

pantalla.

Este ejemplo se va a comentar a la vez que se muestra el código. Dentro de la clase que se ha

creado se define un elemento de tipo Form y otro de tipo TextField y se inicializan en el

constructor.

En el caso del TextField, se indica el titulo que queremos que aparezca en el TextField, el valor

inicial que en este caso es nulo, la restricciones de los tipos de datos que se admiten en este

elemento, son las mismas que las de TextBox y en este caso se indica que sólo se admiten

datos de tipo numérico.

Ahora ya solo queda añadírselo al formulario y para ello lo hacemos como se muestra a Continuación

DateField es un componente editable que presenta información de tipo fecha y hora en un

formulario. En el constructor se añade la etiqueta que se le asigna y el modo que viene definido

por unas constantes que son:

• DATE – Tipos de datos de fecha

• TIME – para horas

• DATE_TIME – para horas y fechas

La Clase Gauge implementa un gráfico de barras para visualizar valores representados en

rangos de porcentajes.

La clase ChoiceGroup es como la de JDK, representa una lista de elementos que el usuario

puede seleccionar y que cada uno de ellos tiene una acción asociada.


36

Una vez comentada la clase Screen ,se dará una breve descripción de la clase Canvas y

Graphics ya que no presentan ninguna diferencia sobre las de JDK.

La clases Canvas se emplea para las aplicaciones en las que se necesita capturar eventos y

realizar llamadas gráficas para dibujar en el display. Esta clase es intercambiable con la clase

Screen, por ejemplo en un formulario se puede incluir un elemento List y que la opción

seleccionada realice un dibujo, utilizando para ello la clase Canvas.

Para dibujar cualquier elemento es imprescindible invocar al método paint(Graphics dibujo) de

la clase Canvas. El objeto Graphics define una región que se considera inválida, con la llamada

al método paint() se consigue que se pinten todos los pixels de esa región.

La clase Graphics provee la capacidad de renderizar figuras geométricas 2D, permite dibujar

textos , imágenes, líneas, rectángulos y arcos, para ello cuenta con los métodos:

• drawString()

• drawImage (Image img, int x, int y, int anchor)

• drawLine(int x1, int y1, int x2, int y2)

• drawRect(int x, int y, int width, int height)

• drawRoundRect(int x, int y, int width, int height, int arcWidth, int arcHeight)

• drawArc(int x, int y, int width, int height, int startAngle, int arcAngle)

Los rectángulos y los arcos se pueden rellenar con la llamada al método fillRect(int x, int y, int

width, int height) y fillArc(int x, int y, int width, int height, int startAngle, int arcAngle).

7.3 ALMACENAMIENTO DE DATOS El almacenamiento y recuperación de datos de forma persistente es una característica propia

de prácticamente todos los lenguajes de programación.

J2ME MIDP define una simple base de datos de registros denominada record management

system (RMS) con el objetivo de poder almacenar información una vez que el MIDlet finalice.

La unidad de almacenamiento básica dentro de RMS es el record que es almacenado en una

base de datos especial denominada record store. Un record (registro) como su nombre indica

es un simple array de bytes, mientras que un record store es un fichero binario que contiene

una colección de registros.

El API empleado para la creación y manejo de estos registros es descrito en el paquete

javax.microedition.rms; este paquete define dos clases, tres interfaces2 y cinco excepciones.

RecordStore, RecordEnumeration


37

RecordComparator, RecordFilter, RecordListener

InvalidRecordIDException, RecordStoreException, RecordStoreFullException,

RecordStoreNotFoundException, RecordStoreNotOpenException.

A continuación se describen las clases disponibles en el API así como sus funciones de manejo

básicas.

RecordStore

Algunas de las normas básicas a la hora de crear un RecordStore son las siguientes:

• Los nombres no deben superar los 32 caracteres, cabe mencionar que se distingue entre

mayúsculas y minúsculas.

• Dentro de un MIDlet suite no deben existir dos record store con el mismo nombre

• Los RecordStores creados dentro de un MIDlet suite no son accesibles a otros.

Las funciones básicas de manejo de record store se muestran a continuación:

. openRecordStore: abre un record store existente, en caso contrario crea uno nuevo.

Ej. RecordStore fichero = null;

fichero = RecordStore.openRecordStore("fichero_prueba",true);

. closeRecordStore: cierra un record store

Ej. fichero.closeRecordStore();

• deleteRecordStore: borra un record store

• getName: obtiene el nombre de un record store

• getNumRecords: obtiene el número de registros dentro de un record store

Existen una serie de métodos adicionales para la obtención de la información de cabecera

sobre el record store, las más empleadas son: getLastModified, getNextRecordID,

getNumRecords, getVersion. Es posible asimismo obtener otros tipos de información sobre el

record store, esta información no está disponible en la cabecera, pero se puede acceder a ella

mediante implementación, para ello se dispone de los métodos: getSizeAvailable, getSize,

listRecordStores. Este último método merece mención especial ya que ofrece la posibilidad de

obtener un array con los nombres de todos los record stores que pertenecen a un MIDlet suite.

Con respecto al manejo de registros se dispone de los siguientes métodos:


38

• addRecord: añade un nuevo registro, éste debe encontrarse como un array de bytes,

el valor devuelto por esta función es un entero denominado record ID

• getRecord: se obtienen los datos almacenados en un determinado registro

• setRecord: este método se emplea para establecer los datos de un registro.

• deleteRecord: eliminar un registro de un record store

Cada vez que se crea un nuevo registro en un fichero se le asigna un identificador único dentro

del mismo, record ID, éste será utilizado para localizarle dentro del fichero de manera única,

una vez eliminado un registro, este permanece a NULL, su identificador con.

Por último comentar que una opción interesante a la hora de navegar entre los registros, es la

clase RecordEnumeration que ofrece las siguientes funciones: hasNextElement,

hasPreviousElement, nextRecord, nextRecordId, numRecords, previousRecord,

previousRecordId, rebuild y reset.

7.4 COMUNICACIONES DE RED MEDIANTE J2ME MIDP La capacidad de movilidad y conectividad de los dispositivos móviles quedaría mermada si no

se dispusiese de un mecanismo para poder acceder a datos remotos y redes corporativas, en

resumen, Internet.

El funcionamiento de red en J2ME tiene que ser muy flexible para soportar una gran variedad

de dispositivos, para ello se introduce un nuevo concepto, "marco de conexión general"

consistente en abstraer el funcionamiento de red y los ficheros de entrada/salida.

Todas las clases e interfaces se encuentran en el paquete javax.microedition.io. J2ME

soporta las siguientes formas de comunicación:

• HTTP

• Sockets

• Datagramas

• Puerto serie

• Fichero


39


40

Todas estas formas de comunicación son creadas mediante el método Connector.open(), al

que se le especificará el tipo de comunicación.

static Connection open(String connectString, int mode, boolean timeouts)

En los ejemplos anteriores se está creando en primer lugar una comunicación http, a

continuación mediante datagramas para finalmente llevar a cabo una comunicación serie. En

estos ejemplos no se ha especificado ninguno de los dos parámetros posibles: modo y timeout.

El parámetro mode permite seleccionar el tipo de acceso, existen tres posiblidades: READ,

READ_WRITE y WRITE. El valor tomado por defecto en caso de que no se seleccione ningún

modo es de lectura/escritura. Hay que tener en cuenta que si el modo de acceso no es

soportado por el protocolo, se lanza una IllegalArgumentException. En caso de que el

parámetro timeouts esté a true genera una excepción de tipo InterruptedIOException, indicando

que se ha superado el tiempo de espera en la apertura de la comunicación.

Cabe destacar que de todas las implementaciones MIDP existentes, MotoSDK es la única que

soporta los tres protocolos de red (http, udp, tcp/ip), aunque el J2ME Gíreles Toolkit de Sun

sólo soporta comunicación http, existe una característica no documentada que permite ejecutar

un socket o programa que utilice udp estableciendo para ello la variable de entorno

ENABLE_CLDC_PROTOCOLS = INTUITIVE_TOOLKIT.


41

8 Bibliografía • [SAMS 2001] Yu Feng y Dr. Jun Zhu. “Wireless Java Programming with J2ME”, Junio 2001.

• [SAMS] Michael Morrison. “Wirele ss Java with J2ME in 21 Days”, Junio 2001.

• Application for Mobile Information Device. [White Paper]

• J2ME Technology for creating Mobile Devices. [White Paper]

• CLDC Specification. Version 1.0a

• J2ME Wireless Toolkit User’s Guide. Version 1.0

• Mobile Information Device Profile (JSR-37). Draft 0.9

9 Direcciones de Interés http://www.java.sun.com

http://java.sun.com/j2se/1.3/download-windows.html

http://www.cun.com/forte/ffj/buy.html

http://www.codewarrior.com/

http://www.inprise.com/jbuilder/hhe/

http://java.sun.com/ products/j2mewtoolkit/ download.html


42

http://www.java.sun.com/

http://java.sun.com/j2se/1.3/download-windows.html

http://www.cun.com/forte/ffj/buy.html

http://www.codewarrior.com/

http://www.inprise.com/jbuilder/hhe/

http://java.sun.com/ products/j2mewtoolkit/ download.html

introducción a j2me - unid · académicas y empresas de software, electrónica, telefonía móvil,...

Documents