• No se han encontrado resultados

DESARROLLO DE APLICACIONES JAVA PARA

N/A
N/A
Protected

Academic year: 2022

Share "DESARROLLO DE APLICACIONES JAVA PARA"

Copied!
13
0
0

Texto completo

(1)

Departamento de Lenguajes y Sistemas Informáticos Cursos de Doctorado. Universidad de Sevilla

D ESARROLLO DE APLICACIONES JAVA PARA MÓVILES : J2ME Y HERRAMIENTAS DE

DESARROLLO

Francisco Martínez Álvarez

Sevilla, 7 de junio de 2006

(2)

Í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

(3)

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.

(4)

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

(5)

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.

(6)

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.

(7)

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.

(8)

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.

(9)

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,

(10)

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:

(11)

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.

(12)

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.

(13)

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);

} }

}

Referencias

Documento similar

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de

b) El Tribunal Constitucional se encuadra dentro de una organiza- ción jurídico constitucional que asume la supremacía de los dere- chos fundamentales y que reconoce la separación

Gastos derivados de la recaudación de los derechos económicos de la entidad local o de sus organis- mos autónomos cuando aquélla se efectúe por otras enti- dades locales o

1. LAS GARANTÍAS CONSTITUCIONALES.—2. C) La reforma constitucional de 1994. D) Las tres etapas del amparo argentino. F) Las vías previas al amparo. H) La acción es judicial en

Volviendo a la jurisprudencia del Tribunal de Justicia, conviene recor- dar que, con el tiempo, este órgano se vio en la necesidad de determinar si los actos de los Estados

Un terreno ligero es cuando los soldados han penetrado en territorio enemigo, pero todavía no tienen las espaldas cubiertas: por eso, sus mentes no están

Una vez hecho esto, se realiza una espera, leyendo el registro de salida del coprocesador para el control de qué está haciendo el procesador en este momento, a la espera que nos

Fuente de emisión secundaria que afecta a la estación: Combustión en sector residencial y comercial Distancia a la primera vía de tráfico: 3 metros (15 m de ancho)..