Java S9

S9
Java per a dispositius mbils.

Sabadell, del 5 al 6 de juliol de 2007
Vicen Soler i Juan Manuel Fernndez, professors de lEscola Universitria dInformtica de Sabadell.
Estius Universitaris 06/07
Java Mvil J2ME
Java en dispositivos mviles

Vicen Soler Juan Manuel Fernndez
Java Mvil J2ME
Programa (I)
Java 2, Micro Edition. (1'5h)

Configuraciones: CDC, CLCD CDC CLCD Profiles: Foundation Profile, Personal Profiles, MID Profile. JVMs y Paquetes Opcionales
Objetivos: Conocer las diferentes implementaciones de Java para dispositivos mviles. Introduccin a la arquitectura J2ME, Presentacin de la arquitectura bsica de Java i como esta se adapta en funcin del dispositivo sobre el que se coloca, se presentan los estndares que hay detrs de esta arquitectura y se catalogan para uso futuro del alumno. Dispositivos. (1'5h)
PDA, PocketPCs, Mobile Devices, PIM
Objetivos: Catalogar los dispositivos mviles, se pretende que el alumno sea crtico a la hora de desarrollar una aplicacin en J2ME para que esta cubra la mayor parte de dispositivos.
Pg: 2
Java Mvil J2ME
Programa (II)
Entornos de desarrollo (2h)

Diferentes entornos IDE. Instalacin del Software para desarrollo. Instalacin y configuracin del Emulador de PALM
Objetivos: Evaluar diferentes entornos de desarrollo, se referencia un conjunto amplio de ellos, y se aporta una visin critica sobre ventajas e inconvenientes de estos, finalmente se instala un entorno tanto de desarrollo como de test de aplicaciones. Constricciones para desarrollar aplicaciones es dispositivos mviles (1h)
CPU Pantalla Memoria
Objetivos: Analizar las caractersticas del entorno donde se ejecuta la aplicacin con el objetivo de evidenciar las sustanciales diferencias de desarrollo que se deben considerar para los dispositivos mviles. Concienciar al alumno de las concesiones necesarias en las aplicaciones J2ME.
Pg: 3
Java Mvil J2ME
Programa (III)
Estructura bsica de un Midlet (3h)

Gestor de aplicaciones Ciclo de vida Estructura de un Midlet
Objetivos: Mostar la estructura bsica de las aplicaciones para dispositivos mviles, crear una aplicacin bsica y analizarla, ver los problemas de desarrollo, compilacin y deployment de este tipo de aplicaciones. La interfaz de Usuario (6h)
En MIDP En PersonalJava
Objetivos: Presentar los controles disponibles en J2ME y PersonalJava, familiarizando al alumno con las estructuras necesarias para construir aplicaciones usables.
Pg: 4
Java Mvil J2ME
Programa (IV)
Almacenamiento de Informacin (3h)

En MIDP Implementacin en Palm OS Otros contenedores de informacin En PersonalJava
Objetivos: Presentar las diferentes APIs para la gestin de la informacin en los dispositivos mviles en general y en algunos en particular, y como estas deben ser tratadas desde las aplicaciones para un correcto ciclo de vida. Se aborda tambin el almacenamiento externo de esta informacin. Comunicaciones (3h)
Framework de comunicaciones en CLCD Comunicaciones en PocketPC
Objetivos: Introduccin a la intercomunicacin de dispositivos mviles, las restricciones que por sus caractersticas se encuentran es este tipo de dispositivos. WebServices Futuro Objetivos: Integracin de las aplicaciones y los dispositivos en la empresa, y los mecanismos que se encuentran disponibles para poder realizarla. Objetivos: Anlisis del futuro de las aplicaciones Java en los dispositivos mviles, mesa redonda con los alumnos para ver su opinin con respecto a este tipo de dispositivos, y anlisis de tendencias del mercado.
Pg: 5
Java Mvil J2ME
mbito de Java
Java 2 Micro Edition (J2ME)

Pg: 6
Java Mvil J2ME
Java 2, Micro Edition

Configuraciones:
J2ME se define en trminos de configuraciones y de perfiles. Una configuracin es un core para la funcionalidad bsica, mientras que un perfil se define sobre una configuracin existente. As, un perfil proporciona una funcionalidad extendida que explota las capacidades del dispositivo sobre el que se van a ejecutar las aplicaciones. Tambin podemos encontrar los paquetes opcionales, los cuales se definen sobre los perfiles y configuraciones.
Pg: 7
Java Mvil J2ME
Configuraciones de J2ME
Una configuracin es una combinacin de una mquina virtual Java y de una coleccin de los interfaces de programacin de aplicaciones (APIs) para una determinada clase del dispositivo. Una configuracin proporciona la base para uno o ms perfiles en un dispositivo. Un perfil es un sistema de APIs que dota de ms funcionalidad y se adapta especficamente a las especificaciones de un determinado dispositivo. Una configuracin define un sistema bsico de APIs que se debe estar implementado en todos los dispositivos que soporten la configuracin (dispositivos de baja potencia, con poca cantidad de memoria, etc.). El perfil que se sustenta sobre la configuracin, debe implementar los APIs de la configuracin, y los especficos del perfil (profile), como pueden ser los especficos de un PDA, un telfono mvil, etc. Es importante observar que la configuracin especifica las capacidades de la mquina virtual asociada, pero no impone una maquina virtual particular. Los vendedores de perfiles y configuraciones tienen libertad de proporcionar su propia mquina virtual, siempre que se adapte a la especificacin (Ex. J9VM IBM, KVM SUN).
Pg: 8
Java Mvil J2ME
J2ME, CDC & CLDC

Hay dos configuraciones definidas actualmente en J2ME: la configuracin de dispositivo con conexin limitada (CLDC) y la configuracin de dispositivo con conexin (CDC). La CDC se piensa para PDAs y dispositivos de gama alta y con conexiones permanentes o semi permanentes. El CLDC se piensa para PDAs y dispositivos con las conexiones de red intermitentes y con memoria y CPU limitada.
A continuacin se presenta un esquema de los perfiles definidos para la CDC y CLDC.

El personal profile se sita sobre el personal basis y el foundation profile los cuales extiende la configuracin CDC. El perfil Mobile Information Device (MID) extiende la configuracin CLDC, junto con paquetes opcionales como pueden ser el Personal Information Management (PIM) y el FileConnection.
Pg: 9
Java Mvil J2ME
CLDC vs CDC (I)

Connected Limited Device Configuration (CLDC)
El CLDC 1,0 fue definido por JSR30 (Java Specification Request) y lanzado en mayo de 2000. Apunta los dispositivos con unas caractersticas bsicas. Un dispositivo de CLDC:
es accionado por las bateras, Pocos recursos de proceso, Conectividad ad-hoc y de poca velocidad, 128 KB de memoria disponible para la JVM y las bibliotecas de CLDC, y tiene por lo menos 32 KB disponible para el runtime y la asignacin dinmica de objetos.
Estas caractersticas definen una variedad amplia de dispositivos, incluyendo pagers, telfonos mviles, y PDAs. El CLDC define una base comn para estos dispositivos en las reas siguientes:
Paquetes de Java base Capacidades de lenguaje Capacidades de la JVM Conectividad e I/O Seguridad Internacionalizacin
No cubre otras reas que puedan ser especificas del dispositivo, por ejemplo el interfaz de usuario, el ciclo de vida de aplicacin, gestin de eventos. Estas reas son cubiertas por los perfiles. La mquina virtual de Java que proporciona el core de un CLDC cumple las especificaciones de JVMS y JLS con algunas excepciones. Es decir los perfiles o aplicaciones que corran sobre CLDC no dispondrn de las siguientes caractersticas:
Pg: 10
Java Mvil J2ME
CLDC vs CDC (II)

Restricciones referentes a JLS (Java Language Specification)
Sin soporte de coma flotante (ninguna operacin de coma flotante, literales de coma flotante, tipos, o valores). Sin soporte a la finalizacin. Soporte bsico de excepciones, el nmero de las clases de error es limitado. Ningn soporte a coma flotante.. Ningn Interfaz Nativo de Java (JNI). No se soportan los class-loaders de usuario. Inexistencia de la API Reflection. Sin Thread groups ni daemon Threads. Sin soporte a la finalizacin. Sin Weak References. Mtodo diferente de verificacin de classfile Formato de classfile y cargador (loader) diferente.
Restricciones referentes a JVMS (Java Virtual Machine Specification)
El CLDC hereda la mayora de sus clases de J2SE, y define algunas clases especificas de CLDC. Las clases heredadas de J2SE utilizan los nombres comunes de la clase y del paquete. Las clases especificas usan el prefijo javax.microedition.
Pg: 11
Java Mvil J2ME
CLDC vs CDC (III)

La versin siguiente de CLDC fue definida por JSR139 (Java Specification Request), que fue aprobado en Marzo de 2003. Los cambios en CLDC 1,1 son los siguientes:
Se agrega la coma flotante. float y double a java.lang , y algunos mtodos en otras clases permiten valores en coma flotante. Las clases afectadas incluyen java.lang.Math, java.io.DataOutputStream, java.io.DataInputStream, y java.util.Random. Soporte bsico para referencias Weak de J2SE's. Se agrega el paquete java.lang.ref. Las clases Calendar, Date y TimeZone en java.util son ms consistentes con las versiones de J2SE. Se ha agregado la clase Error en java.lang.NoClassDefFoundError. Algunos mtodos aadidos a clases existentes, por ejemplo el mtodo intern() a la clase java.lang.String, y el mtodo toString() a la clase java.util.Date. La especificacin completa de CLDC 1,1 est disponible de http://www.jcp.org/jsr/detail/139.jsp .
Connected Device Configuration (CDC)

La CDC es un sper conjunto de CLDC. La CDC incluye todas las APIs definidas por el CLDC, incluyendo los paquetes java.* y javax.microedition.*. La CDC se disea para los dispositivos de ms memoria (2 MB o ms, disponible para la plataforma de Java) y una conexin mejor de red (desde 9600 bps en adelante). La CDC hereda de PersonalJava, por tanto las aplicaciones de PersonalJava que no utilicen AWT (Abstract Window Toolkit) deberan ser portables a CDC (las capacidades de AWT se definen en los perfiles del CDC).
Pg: 12
Java Mvil J2ME
CLDC vs CDC (IV)

Connected Device Configuration (CDC)
Una implementacin de CDC debe soportar totalmente JLS y JVMS. Los paquetes de la CDC se disean para ser un sistema completo de APIs para apoyar la JVM. Se toman de J2SE 1,3, eliminando los APIs deprecados. El sistema de paquetes resultante es el siguiente:
java.io, incluyendo BufferedReader, BufferedWriter, ObjectInputStream, y ObjectOutputStream java.lang java.lang.ref java.lang.reflect java.math Clases de java.net de J2SE, incluyendo URL, URLConnection, InetAddress, y SocketPermission java.security encriptacin para la serializacin de objetos. Sin soportar firma segura de cdigo, certificados, almacenamiento de claves, JDK 1.1 Identity, e IdentityScope. java.security.cert java.text, con soporte mnimo para i18n (internationalization) java.util, clases de J2SE, incluyendo Array, BitSet, Calendar, LinkedList, Stack, Vector java.util.jar java.util.zip javax.microedition.io
Cualquier implementacin de CDC deben soportar la entrada-salida del archivo (I/O) (por lo menos en modo read-only) y datagramas.
Pg: 13
Java Mvil J2ME
Profiles CLDC
Actualmente slo existe un perfil (profile) para la configuracin CLDC. Este profile (MIDP) Mobile Information Device Profile, fue lanzado por SUN en Octubre de 2001 para los dispositivos PALM. El mbito del perfil esta pensado para dispositivos mucho ms limitados en recursos, como pueden telfonos mviles, y pagers. La ventaja de la eleccin de este perfil, es que aporta la mnima expresin para todos los dispositivos, de este modo una aplicacin que corra sobre este perfil, podr ejecutarse en todos los dispositivos que lo implementen.
Pg: 14
Java Mvil J2ME
CLCD: MIDP (I)

La especificacin de MIDP define los requisitos adicionales para el dispositivo destino, ms all de los requisitos necesarios para CLDC. Definido en JSR37, MIDP impone la necesidad de 128 KB adicionales de memoria permanente para los componentes de MIDP, 8 KB para los datos persistentes creados y usados por las aplicaciones, y 32 KB para el Java heap. La especificacin MIDP 1.0 sobre CLDC 1.0, proporcionan funcionalidad en los apartados siguientes:
Gestin de ciclos de vida de la aplicacin. Interfaz de usuario Almacenamiento persistente Redes Timers APIs A nivel sistema Instalacin y almacenaje de la aplicacin Seguridad ms all de lo especificado en CLDC.
MIDP no cubre las reas siguientes:

MIDP proporciona nuevas clases en java.lang, java.util, y javax.microedition.io, y define los nuevos paquetes para el interfaz de usuario, el almacenamiento persistente, y las extensiones para la gestin del ciclo de vida de la aplicacin. Estos paquetes se denominan javax.microedition.lcdui, javax.microedition.rms, y javax.microedition.midlet, respectivamente.
Pg: 15
Java Mvil J2ME
CLDC: MIDP (II)

Una aplicacin MIDP se llama MIDlet. Un MIDlet es parte de un grupo de MIDlets llamado una suite de MIDlet. Las suites de MIDlet pueden compartir recursos, tales como datos persistentes en una base de datos del Record Management System (RMS) en el dispositivo. Una aplicacin de MIDP debe extender la clase MIDlet e implementar tres de sus mtodos definidos como abstractos: startApp, pauseApp, y destroyApp. Estos mtodos son llamados por el sistema cuando se requiere que el MIDlet cambie de estado. Un MIDlet tiene los estados siguientes:
Pausado. Cuando el sistema requiere que el MIDlet entre en estado pausado, llama el mtodo pauseApp para permitir liberar los recursos compartidos. Activo. Se llama el mtodo startApp despus de que se cree una instancia del MIDlet, y cada vez que se abandona el estado pausado. Destruido. Cuando se invoca destroyApp el MIDlet que debe almacenar su estado y liberar cualquier recurso que tuviera asignado.
El desarrollador puede tambin hacer que el MIDlet entre en estos estados, usando los mtodos notifyPaused, notifyDestroyed, y resumeRequest. MIDP 2.0 se construye sobre MIDP 1.0, es compatible hacia atrs, esto garantiza que las aplicaciones desarrolladas para MIDP 1.0 tambin funcionen en MIDP 2.0. Definido en JSR118, la especificacin final fue lanzada en noviembre de 2002. Asume funcionalidad de CLDC 1.0, aunque tambin trabajar con CLDC 1,1. MIDP 2.0 agrega algunos nuevos paquetes:
javax.microedition.lcdui.game. Este paquete incluye las clases para crear una infraestructura para juego. Incluye clases GameCanvas y Sprites. javax.microedition.media y javax.microedition.media.control. MIDP 2.0 incluye un subconjunto de Movile Media API (JSR135) y generacin de tonos y reproduccin de sonido. javax.microedition.pki. Certificados para las conexiones de red seguras.
Se puede obtener una copia de la especificacin de MIDP 2.0, en http://www.jcp.org/jsr/detail/118.jsp .
Pg: 16
Java Mvil J2ME
CLDC: Paquetes Opcionales

De igual modo que el profile MIDP, para explotar las caractersticas de estos dispositivos se dispone de paquetes que ofrecen una API Java para acceder a estos recursos. En el JSR075 se especifican los paquetes opcionales que se pueden construir sobre CLDC 1.0 o superiores. Estos son el PIM y FileConnection. Aunque fueron definidos por el mismo JSR pueden implementarse de forma independiente. Paquete Opcional de PIM (Personal Information Management)
El paquete opcional PIM aade el paquete javax.microedition.pim a CLDC. El propsito de este paquete es proveer al desarrollador el acceso y gestin de la libreta de direcciones, la lista de tareas y el calendario del PDA. El paquete opcional de FileConnection agrega a CLDC 1.0 o superior el paquete javax.microedition.io.file. Este paquete aade otro tipo de conexin al framework genrico de conexiones (GCF), y proporciona el acceso al sistema de ficheros del PDA. El sistema de ficheros puede estar en el propio dispositivo, en tarjetas de memoria tales como CompactFlash (CF), Secure Digital (SD), Multimedia Card (MMC), SmartMedia (SM), o en otros sistemas de almacenamiento.
Paquete Opcional FileConnection
Pg: 17
Java Mvil J2ME
CDC Profiles (I)

Los dispositivos PoketPC acostumbran a incluir distribuciones de PersonalJava, formalmente Personal Java es parte de J2SE, se apuntaran las diferencias entre las implementaciones de PersonalJava y J2ME. Foundation Profile El foundation profile fue desarrollado por el JCP como JSR46 http://www.jcp.org/jsr/detail/46.jsp. Puede ser descargado de http://java.sun.com/j2me/index.jsp. Una implementacin del foundation profile debe soportar los protocolos especificados por la CDC, y adems debe apoyar los sockets y HTTP. Personal Basis Profile Este profile proporciona la capacidad para una presentacin bsica de interfaz de usuario, pero no tiene soporte para GUIs de alta funcionalidad. El Personal Basis Profile proporciona nicamente soporte para componentes ligeros de AWT. Las principales diferencias entre este profile y las funcionalidades de PersonalJava son:
PersonalJava implementa el JDK 1.1.8, mientras que el Personal Basis Profile implementa JDK 1,3. Era opcional incluir Remote Method Invocation (RMI) en PersonalJava. En el Personal Basis Profile, el RMI es soportado por un paquete opcional. Un volumen importante de APIs deprecadas no se incluye en el Personal Basis Profile.
El Personal Basis Profile fue desarrollado por el JCP como JSR129 http://www.jcp.org/jsr/detail/129.jsp.
Pg: 18
Java Mvil J2ME
CDC Profiles (II)

Personal Profile El personal profile es el camino para la migracin hacia J2ME de las aplicaciones de PersonalJava, y fue desarrollado por el JCP como JSR62. Ester Profile aade al Personal Basis Profile soporte para Web y entorno para la ejecucin de aplicaciones heredadas de PersonalJava. El Personal Profile es el perfil de la CDC ideado para PDAs. Las aplicaciones escritas para las APIs del Personal Profile son compatibles hacia arriba con JDK 1.3 de J2SE. El perfil personal se piensa para aplicaciones que requieren soporte completo de JDK 1.1 AWT (es decir, componentes GUI complejos). Especifica tres modelos de aplicaciones:
Applet. Applet estndares del JDK 1.1. Xlets. Un Xlet es un interfaz de la gestin del ciclo de vida, similar al MIDlet. Un Xlet define tres mtodos. El sistema hace que el Xlet cambie su estado. Los estados definidos son Destroyed, Paused, y Active. Aplicaciones. Aplicaciones estndar de Java, definido como clase con un mtodo public static void main(String[]). java.applet java.awt java.awt.color java.awt.datatransfer java.awt.event java.awt.image java.beans java.math java.rmi java.rmi.registry javax.microedition.xlet javax.microedition.xlet.ixc
El Personal Profile agrega al Foundation Profile estos paquetes:

Pg: 19
Java Mvil J2ME
CDC Profiles (III)

Diferencias entre el perfil personal y JDK 1.3 Los paquetes y las clases del Personal Profile son tpicamente subconjuntos de los paquetes y de las clases del JDK 1.3. Hay un conjunto pequeo de APIs en el Personal Profile que tiene restricciones en su uso. Son:
java.awt.AlphaComposite. Aproximacin de la regla de SRC_OVER. java.awt.Component. La implementacin puede ignorar las llamadas para fijar el cursor visible. java.awt.Dialog. La implementacin puede limitar el tamao, puede impedir redimensionar, puede limitar la localizacin en la pantalla, y puede no soportar un ttulo visible. java.awt.Frame. Las mismas restricciones que a Dialog pueden aplicarse a Frame. java.awt.Graphics2D. Solamente instancias de AlphaComposite se pueden utilizar con setComposite() . java.awt.TextField. Alguna implementacin puede no permitir fijar el carcter de echo.
En cada caso, una propiedad del sistema deber ser puesta a true si la implementacin del Personal Profile tiene alguna de las restricciones anteriores. Estas propiedades del sistema tienen las siguientes claves:
java.awt.AlphaComposite.SRC_OVER.isRestricted java.awt.Component.setCursor.isRestricted java.awt.Dialog.setSize.isRestricted java.awt.Dialog.setResizable.isRestricted java.awt.Dialog.setLocation.isRestricted java.awt.Dialog.setTitle.isRestricted java.awt.Frame.setSize.isRestricted java.awt.Frame.setResizable.isRestricted java.awt.Frame.setLocation.isRestricted java.awt.Frame.setState.isRestricted java.awt.Frame.setTitle.isRestricted java.awt.TextField.setEchoChar.isRestricted
Pg: 20
Java Mvil J2ME
CDC Profiles (IIII)

Diferencias entre el Personal Profile y PersonalJava PersonalJava era el Java original para los dispositivos de gama alta y apliances, pero ser reemplazado por el Personal Profile. El Personal Profile es una nueva definicin, basada en J2ME. Cuando los diseadores del perfil personal comenzaron a definirlo, lo hicieron con JDK 1.3, quitado todos los APIs deprecados y que consideraron innecesarios para los dispositivos mviles modernos. PersonalJava se basa en las APIs de JDK 1.1. Diferencias entre PersonalJava y JDK 1.1.8 PersonalJava 1.2 hereda las APIs de JDK 1.1.8, modifica ligeramente a muchos de ellos, convirtiendo alguno en opcional, y agrega algunos especficos a PersonalJava. Tambin hereda algn APIs de Java 1.2 para apoyar seguridad en control de acceso y firmas de cdigo. La portabilidad del cdigo sin modificacin de JDK 1.1.8 a PersonalJava es por lo tanto posible pero depender de la aplicacin. La mayora de las ocasiones en que una aplicacin no funciona con PersonalJava son ocasionados por diferencias en las APIs de seguridad. Tal y como se ha comentado anteriormente PersonalJava utiliza las APIs de seguridad de Java 1.2 en vez de JDK 1.1.8. Sin embargo, existe un gran parecido entre JDK 1.1.8 y PersonalJava 1.2, de modo que el cdigo fuente ser bastante portable entre las dos plataformas.
javax.microedition.*
Pg: 21
Java Mvil J2ME
Dispositivos
Por que utilizando Java nos hemos de preocupar de la plataforma? Tal i como se ha discutido en la presentacin anterior J2ME no es totalmente portable, hemos de considerar aspectos como la JVM donde se ejecutara nuestra aplicacin (PersonalJava y MIDP), as como los paquetes opcionales de los que disponga el dispositivo destino. Por norma general se recomienda estructurar la aplicacin en el cdigo funcional comn que se pueda ejecutar independiente de la plataforma, y separarlo de la presentacin de usuario, la persistencia y conectividad, esto puede ser una tarea compleja. Dado que el punto anterior es de difcil cumplimiento, normalmente se escoge la plataforma destino antes de disear la aplicacin, dado que muchas aplicaciones para dispositivos mviles son orientadas a cliente servidor, esto afectara significativamente a diseo y realizacin de la aplicacin. A continuacin vamos a enumerar algunos de los dispositivos mviles ms comunes y sus caractersticas ms significativas. Al seleccionar una plataforma PDA para el desarrollo de Java, hay un gran nmero de factores a considerar. En la consideracin de estos factores, es importante recordar los dos subconjuntos principales de dispositivos, dependiendo del SO: Palm OS y PocketPCs. Estos tienen filosofas totalmente diferentes, a continuacin se enumeran algunas de ellas. Es importante considerar siempre que aunque Java funcionar en ambos dispositivos, la riqueza de la plataforma vara, segn las capacidades del dispositivo, y, por consiguiente, la configuracin. Esto es principalmente debido a las diferencias en filosofa de diseo de las configuraciones de J2ME segn el tipo de dispositivo.
Pg: 22
Java Mvil J2ME
Palm OS vs PocketPCs
Dispositivos Palm OS
Herencia de los PIM. Los dispositivos originales de PALM OS eran PIMs de gama alta con pantallas grandes y la capacidad de escribir en vez de mecanografiar. Funcionalidad simple. PALM se caracteriza por realizar tareas simples de forma elegante.
PocketPCs
Herencia del PC. El PocketPCs es bsicamente un PC en miniatura.
Rica funcionalidad. Un PocketPC es bsicamente un PC con Windows o con Linux (Sharp Zaurus) con funcionalidades limitadas, esto deja una look and feel de PC al dispositivo. Como ejemplo el men de inicio y el sistema de ficheros siguen siendo igual. Alta energa de proceso y una vida ms corta de las bateras. Los PocketPCs disponen actualmente de CPUs de 200 MHz a 400 MHz, y sobre 32Mb a 64Mb de RAM.
Energa de proceso baja y larga duracin de la batera. Los dispositivos PALM OS funcionan a con CPUs de 20 MHz o 33 MHz, y tpicamente 8 M de la memoria. Los nuevos dispositivos PALM OS basados en procesadores ARM y XScale aparecidos en el 2003 aumentan las capacidades de proceso y de memoria asemejndose a los PocketPC.
Pg: 23
Java Mvil J2ME
Comparativa de precios en USD

Diciembre 2002
PocketPC Casio E-200 HP iPaq 3970 Compaq iPaq 3870 Toshiba e740 Media
Men or $600 $715 $537 $550 $601
Mayo Palm OS r $650 $780 $680 $600 $678 Handspring Treo 270 Palm m515 Palm i705 Sony CLIE PEGNR70V Media
Men or $500 $300 $298 $510 $402
Mayor $700 $400 $450 $600 $538
En esta seleccin de dispositivos high-end PocketPC y Palm, podemos observar que los PocketPC son entre un 25% y un 50% ms caros que los dispositivos high-end Palm OS.
Pg: 24
Java Mvil J2ME
Factores a considerar en la decisin de la plataforma (I)

Coste
PocketPCs es generalmente ms costoso que los dispositivos Palm OS. Tal i como se puede observar en la tabla anterior. Si hablamos de desarrollos para usuarios corporativos, o para la propia organizacin, los estndares corporativos para PDAs afectan claramente a la elecin de la plataforma. Segn el grupo tecnolgico Winn (en fecha diciembre de 2002), Palm OS ha sido elegido por el 85% de las compaas que comprende Fortune 1000. Fuente: Diez razones de elegir un Handheld Palm, 2002, http://www.palmsource.com/includes/top_ten_reasons_to_choose_palm_powered.pdf . Desde la perspectiva de un desarrollador de Java, la riqueza funcional de la plataforma depende de si se tiene acceso a l desde Java. Todos los PDAs tienen funciones estndares de PIM (es decir, libros de direcciones, notas, listas de la tarea, y calendarios). El paquete opcional de PIM se disea para permitir el acceso fcil a las funciones de PIM de un PDA desde Java. PersonalJava no tiene especficamente una API PIM, sino que proporciona el acceso a la funcionalidad del sistema operativo y las aplicaciones con JNI. Sin embargo, el grado de accesibilidad con JNI depende de la disponibilidad de una biblioteca del API para tener acceso a la funcionalidad. El soporte Java es importante si se es desarrollador Java que desea escribir aplicaciones para PDAs. Aunque PersonalJava es ms rico en APIs de Java y ms cercano a J2SE que MIDP y los paquetes opcionales de CLDC, PersonalJava carece el APIs para tener acceso a las caractersticas especificas de un PDA.
Pg: 25
Estndar Corporativo
Riqueza de funcionalidad
Riqueza del soporte Java
Java Mvil J2ME
Factores a considerar en la decisin de la plataforma (II)

Soporte Wireless
Aunque ambos dispositivos son capaces de operar wireless, tanto con soporte WiFi y Bluetooth, la disponibilidad de estas caractersticas para aplicaciones Java es limitado. Tomar un cierto tiempo hasta que las APIs Java maduren y para que los vendedores agreguen estas APIs a sus mquinas virtuales de Java (VMs) en los PDAs. En los aos 90, el Palm OS era el sistema operativo dominante para PDA en el mercado. Desde entonces, Microsoft ha desafiado esa hegemona con cierto xito. En 2002, los PocketPCs eran una alternativa fuerte con crecimiento en cuota de mercado. La tendencia desde entonces es un crecimiento de PocketPC en detrimento de Palm OS. La mayora de los fabricantes de PDAs tendrn a corto plazo nuevos modelos basados en la CPU de Intel XScale. Esto provocara una clara disminucin de las diferencias Hardware entre dispositivos Palm OS y PocketPC, como ejemplo destacar que Palm OS v5 es funcionalmente idntico a las versiones anteriores, pero sin las limitaciones que tenan sus predecesores.
Market Share - Actual y tendencia
Donde estar el vendedor / fabricante del dispositivo en dos aos?
Pg: 26
Java Mvil J2ME
Comparativa PDAs
Clasificacin Java vs PDA
PersonalJava est disponible en los dispositivos de PocketPC, mientras que MIDP est disponible en los dispositivos Palm OS. A continuacin se enumeran las implementaciones J2ME actualmente disponibles. PersonalJava se incluye en la tabla aunque no es estrictamente una implementacin J2ME, por el contrario est disponible para casi cada dispositivo PocketPC.
Comparacin de dispositivos Palm OS

Los dispositivos Palm estan evolucionando rpidamente, tanto a nivel Hardware como SO. Tambin existen nuevos fabricantes que crean dispositivos que ejecutan Palm OS, a continuacin se muestra una tabla con una seleccin de los dispositivos producidos por Palm Inc. y con licencias de Palm OS.
Pg: 27

Operating System PocketPC 2002 PocketPC 2002 Lineo's Embedix Linux Windows CE 3.0 PocketPC 2002 Windows CE 3.0 PocketPC 2002 PocketPC 2002 PocketPC 2002 Palm OS Palm OS Palm OS 3.5.x Windows CE 2.11
Java Mvil J2ME
Clasificacin Java vs PDA

CPU StrongARM Intel XScale StrongARM StrongARM StrongARM StrongARM Intel XScale StrongARM StrongARM 68K 68K 68 K MIPS or SH3 Device HP iPaq 3800 series Toshiba GENIO e550G Sharp Zaurus SL-5500 HHP Dolphin 7400 NEC PocketGear Samsung NEXiO S150 Fujitsu Pocket LOOX Compaq iPaq as a reference platform Compaq iPaq as a reference platform Palm III, Palm V, Palm Vx as a reference platform Various Various; capable of running 3.5.x IBM Workpad Z50, Compaq Aero 2100, HP Jornada 430 SE, and Oth.
Pg: 28
Java PersonalJava 1.2 PersonalJava 1.2 PersonalJava 1.2 PersonalJava 1.2 PersonalJava 1.2 PersonalJava 1.2 PersonalJava 1.2 CDC/Foundation 1.0 CLDC/MIDP 1.0 CLDC/MIDP 1.0 CLDC/MIDP 1.0 CLDC/MIDP 1.0 PersonalJava 1.1.3
Product Insignia Jeode PDA Edition Insignia Jeode PDA Edition Insignia Jeode PDA Edition Insignia Jeode PDA Edition Insignia Jeode PDA Edition Insignia Jeode PDA Edition Insignia Jeode PDA Edition IBM WebSphere Micro Environment IBM WebSphere Micro Environment IBM WebSphere Micro Environment Esmertec Micro Edition CLDC MIDP for Palm OS 1.0 Sun PersonalJava Runtime Environment for Windows CE 2.11 Version 1.0
Java Mvil J2ME
Comparacin de dispositivos Palm OS

Device Palm IIIx Palm V Palm VII Palm VIIx Palm i705 Handspring Visor Handspring Visor Edge IBM WorkPad (Original) Qualcomm pdQ 1900 Sony CLIE PEG-S500c Supra eKey Symbol SPT1740 TRG TRGpro Total RAM 4 MB 2 MB 2 MB 8 MB 8 MB 2 MB 8 MB 4 MB 2 MB 8 MB 2 MB 2/4/8 MB 8 MB 128 KB 256 KB 96 KB 128 KB 256 KB 128 KB 128 KB 128 KB/256 KB Dynamic Heap[a] 128 KB 128 KB 128 KB 256 KB Palm OS[b] 3.1 3.1 3.2.0/3.2. 5 3.5 4.1 3.1 3.5.2 3.0 3.02 3.5 3.1 3.2 3.3/3.5.1 Dragonball EZ Dragonball VZ Dragonball EZ Dragonball EZ Dragonball EZ Dragonball EZ Dragonball Dragonball EZ 16 MHz 33 MHz 16 MHz 16 MHz 20 MHz 16 MHz 16 MHz 16 MHz CPU Type Dragonball EZ Dragonball EZ Dragonball/Dragonball EZ Dragonball EZ CPU Speed 16 MHz 16 MHz 16 MHz 20 MHz
Fuente: http://www.palmos.com/dev/tech/hardware/compare.html. [a]: Dependiendo de la versin de Palm OS instalada [b]: Esta versin es la de referencia, en algunos dispositivos puede haberse upgradeado.
Pg: 29
Java Mvil J2ME
Preparando el entorno de desarrollo

A continuacin se enumerara el software necesario para el desarrollo de las aplicaciones de ejemplo de este curso. Las herramientas utilizadas estn disponibles de forma libre o con mnimo coste, se han evitado los IDEs comerciales por las siguientes razones:
Aprender a programar en una nueva plataforma es ms eficiente contra ms elemental es el entorno de desarrollo, la utilizacin de un IDE a menudo oculta aspectos fundamentales de la programacin y el deployment de la aplicacin. Siempre se esta a tiempo de utilizar un IDE, cuando se entiendan los mecanismos de construccin de aplicaciones en la plataforma. Se dispone de mayor libertad de programacin, se pueden realizar cosas que a menudo no son posibles con un IDE. El objetivo de este curso es demostrar que cualquiera puede desarrollar aplicaciones Java para PDAs. Las herramientas costosas no son de momento necesarias.
Pg: 30
Java Mvil J2ME
Las herramientas que utilizaremos son:

Un editor de textos, como TextPad ( http://www.textpad.com/ ) o UltraEdit ( http://www.ultraedit.com/ ). El editor de textos debera poder destacar la sintaxis Java y XML de modo que el cdigo fuente sea fcil de leer. Java SDK ( http://java.sun.com/j2se/downloads.html ). Utilizaremos 1.1.8 (para compilar cdigo fuente de PersonalJava) y 1.4 (para el resto). Emulador de Palm ( http://www.palmos.com/dev/tools/emulator/ ). Sun's J2ME Wireless Toolkit ( http://java.sun.com/products/j2mewtoolkit/download.html ). MIDP de Sun para Palm ( http://java.sun.com/products/midp4palm/index.html ). Aunque es libre descargar para propsitos de desarrollo personal, se debe observar que MIDP para Palm no es libre para distribuir comercialmente.
Pg: 31
Java Mvil J2ME
Configurando el emulador de Palm OS (I)

El emulador de Palm OS (POSE) es una parte esencial en un toolkit de desarrollo PDA Java. Antes de descargar una aplicacin en el PDA es recomendable realizar un test en el entorno POSE. Esto implica un bucle de programacin - prueba - correccin mucho ms rpido. POSE est disponible para Windows, MacOS, y Unix. Tambin es necesaria una ROM de Palm OS para cargar en el emulador. Se incluyen dos ROMs una correspondiente a una PDA Ibm C3, y otra a una PDA Palm m505, si se dispone de un dispositivo Palm OS puede descargarse la ROM del dispositivo al PC con el software incluido. Cuando se ejecuta el emulador de Palm OS, aparece una pantalla similar a esta. Seleccionamos New para crear una nueva sesin del emulador tal y como se observa en el siguiente grafico.
Pg: 32
Java Mvil J2ME
Configurando el emulador de Palm OS (II)

En este momento ya dispondremos de un entorno de emulacin totalmente funcional.
Pg: 33
Java Mvil J2ME
J2ME Wireless Toolkit

J2ME Wireless Toolkit de Sun (J2MEWTK) es un conjunto de herramientas para desarrollar aplicaciones para la plataforma CLDC/MIDP. Funciona en Windows, Solaris, y Linux, y proporciona un entorno de emulacin para diversos dispositivos. Tambin es capaz de utilizar POSE para emular dispositivos Palm. El J2MEWTK permite cualquier editor de textos para corregir los archivos fuente. La JVM proporcionada por J2MEWTK es KVM, una mquina virtual compacta que comprende los dispositivos con menos de un mega de memoria. Dirigirse a http://java.sun.com/products/cldc/wp/KVMwp.pdf para ms informacin sobre KVM. Se debe instalar J2ME Wireless Toolkit en el directorio por defecto.
Pg: 34
Java Mvil J2ME
MIDP para Palm OS

Si se escoge un entorno genrico de desarrollo MIDP para Palm ser necesaria una utilidad para convertir la aplicacin MIDP (JAR/JAD) en un PRC (ejecutable para Palm), esto es realizado por la suite MIDP de Sun.
Destacar que J2MEWTK tambin incluye esta funcionalidad, pero no incluye MIDP para Palm. J2MEWTK produce el archivo JAD y lo convierte a PRC solamente cuando se utiliza conjuntamente con el emulador de Palm. Un JAD es un archivo de parmetros para definir valores predefinidos de un MIDlet, y valores definidos por el usuario. El conversor de MIDP para Palm permite que el desarrollador convierta cualquier conjunto JAD/JAR en un PRC.
Incluido en el MIDP para Palm:

Una utilidad para convertir un MIDP estndar JAD/JAR en un PRC para descargar en el dispositivo. Una implementacin de KVM y de las bibliotecas de CLDC/MIDP para Palm. Algunos aplicaciones java de ejemplo.
MIDP para Palm ocupa unos 590 KB de memoria y funciona en los dispositivos siguientes:
Palm OS 3.5.x. Disponer por lo menos de 4 MB de memoria total.
MIDP para Palm tambin incluye la capacidad de capturar los streams System.out y System.err. Para instalar el entorno MIDP para Palm tan slo es necesario sincronizar el archivo MIDP.prc en el dispositivo.
Pg: 35
Java Mvil J2ME
Ejecutar aplicaciones java en Palm (I)

Como norma general para la creacin de cualquier aplicacin para Palm deberemos seguir los siguientes pasos: Compilacin de la aplicacin:
El compilador utilizado ser versin 1.1, se ha de tener en cuenta que tanto MIDP como CLDC estn basado en el bytecode de Java 1.1. Los parmetros para una compilacin bsica: <directorio de jdk 1.1>\bin\javac.exe -d <directorio de salida del class> -classpath <path de midp>\midpapi.zip;<cualquier otro necesario> <fichero a compilar> Ex: c:\jdk1.1.8\bin\javac.exe -d .\tmp -classpath C:\WTK104\lib\midpapi.zip Clase.java
En este punto disponemos del cdigo fuente compilado, pero para poder ejecutar este cdigo en una KVM se debe realizar un proceso de preverificacin, este proceso se realiza de la siguiente forma:
Cuando se trabaja con J2SE la mquina virtual Java (JVM) lleva a cabo un proceso de verificacin en tiempo de ejecucin. Esto ocupa ciertos recursos que en dispositivos inalmbricos 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 verificacin de la KVM off-line, el resto ser llevado a cabo como una verificacin normal. <directorio de JME Wireless Toolkit>\bin\preverify.exe -d <directorio de salida del class> -classpath <path de midp>\midpapi.zip;<cualquier otro necesario> <path de las clases> Ex: c:\WTK104\bin\preverify.exe -d .\class -classpath c:\WTK104\lib\midpapi.zip;.\tmp .\tmp
Pg: 36
Java Mvil J2ME
Ejecutar aplicaciones java en Palm (II)

Como hemos indicado, para construir un "ejecutable" Palm (PRC) se ha de disponer de una dupla (JAR/JAD). para crear el JAR que nos sirva de base al PRC a partir de .class, necesitaremos un archivo especial (manifest) que describir la aplicacin midlet. Concretamente:
El nombre de la aplicacin, el icono a utilizar, y el nombre de la clase de la aplicacin. Vendedor e informacin de la versin. Versin de J2ME requerida. Ej: MIDlet-1: TestSimple, , com.f2i.jmd.SimplestMIDlet MIDlet-Name: TestSimple MIDlet-Vendor: Antoni Ros MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-1.0
Atributos requeridos para el archivo manifest:
Pg: 37
Java Mvil J2ME
Ejecutar aplicaciones java en Palm (III)

Atributos opcionales del archivo manifest:
Con el archivo manifest anterior, debemos ejecutar

<directorio de jdk 1.1>\bin\jar.exe cvfm <archivo de salida.jar> <archivo manifest a utilizar> <clases y recursos a incluir en el jar> Ex: c:\jdk1.1.8\bin\jar.exe cvfm .\jar\Simple.jar .\resources\SimplestMIDlet.mft .\class
En este punto ya disponemos de el fichero JAR, solo falta crear el JAD correspondiente, un archivo JAD describe el paquete JAR, entre otros campos puede incluir los siguientes:
MIDlet-Version: 1.0 MIDlet-Vendor: Antoni Ros MIDlet-Jar-URL: ../jar/Simple.jar MIDlet-Jar-Size: 2056 MIDlet-Name: TestSimple
Se debe tener en cuanta que generalmente entre diferentes minor versions de nuestros midlets el nico dato que variara en el archivo jad ser el tamao del archivo jar.
Pg: 38
Java Mvil J2ME
Ejecutar aplicaciones java en Palm (IV)

Atributos requeridos para el archivo jad:
Atributos opcionales para el archivo jad:
En este instante es posible crear el archivo PRC correspondiente.

<directorio de jdk 1.1>\jre\bin\java.exe" -classpath <directorio donde se ha instalado el midp4palm>\midp4palm1.0\Converter\Converter.jar" com.sun.midp.palm.database.MakeMIDPApp -jad <archivo jad a utilizar> type Data -o <archivoprc a construir> <archivo jar> Ex: "C:\Program Files\j2sdk_nb\j2sdk1.4.2\jre\bin\java.exe" -classpath "C:\Documents and Settings\toni\Mis documentos\Curso Java\Software a llevar\midp4palm-1_0\midp4palm1.0\Converter\Converter.jar" com.sun.midp.palm.database.MakeMIDPApp -jad .\resources\Simple.jad -type Data -o .\prc\Simple.prc .\jar\Simple.jar
Pg: 39
Java Mvil J2ME
Ejecutar aplicaciones java en Palm (V)

En el punto anterior se utiliza la aplicacin MakeMIDPApp que acompaa al paquete MIDP de Sun para Palm, esta aplicacin esta sita en Converter.jar. Las opciones para MakeMIDPApp es:
Uso: Java com.sun.midp.palm.database.MakeMIDPApp [ - opciones ] < archivo JAR > donde las opciones incluyen:
-v -verbose -icon <file> Verbose output (-v -v gives even more information) Same as v File containing icon for application. Must be in bmp, pbm, or bin (Palm Resource) format. -smallicon <file> Same as smallicon -name <name> Short name of application, seen in the launcher -longname <name> Long name for the application, seen in beaming, etc. -creator <crid> Creator ID for the application -type <type> File type for application (default is appl) -outfile <outfile> Name of file to create on local disk; this is the file that is downloaded to the Palm -o <outfile> Same as outfile -version <string> Change version -help Print this message -jad <file> Specify a file for JAD, MIDlet Suite Packaging
Palm recomienda que los desarrolladores para Palm utilicen un identificador nico "Creator ID". Este campo es un identificador de 4 caracteres y se puede obtener en http://dev.palmos.com/creatorid/
Si no se especifica ningn identificador de creador el software asigna uno arbitrario. En este punto ya se dispone de un archivo PRC que puede ser transferido al dispositivo y ejecutado.
Pg: 40
Java Mvil J2ME
Ejecutar aplicaciones java en PocketPC

Al no disponer de ningn emulador de PocketPC con un soporte Java adecuado para PC en el momento del curso no podremos llevar a la practica los pasos aqu detallados. El deploy de una aplicacin de PocketPC es ms simple que en Palm, principalmente por que todos estos dispositivos utilizan PersonalJava 1.2, que es equivalente a JDK 1.1.8. Para instalar una aplicacin en un PocketPC basta con crear el jar correspondiente, sincronizarlo con la carpeta seleccionada del dispositivo, y crear el acceso directo. Dado que la gran mayora de PocketPC actuales utilizan Jeode JVM como implementacin de PersonalJava, se enumeran los pasos para crear una aplicacin Java en un PocketPC Compilacin de la aplicacin: <directorio de jdk 1.1>\bin\javac.exe -d <directorio de salida del class> -classpath < directorio de jdk 1.1 >\lib\classes.zip;<cualquier otro necesario> <fichero a compilar> Creacin del jar contenedor, en este caso el fichero manifest no cumple ningn objetivo, por tanto prescindimos de el: <directorio de jdk 1.1>\bin\jar.exe cvf <archivo de salida.jar> <clases y recursos a incluir en el jar> Creacin de un fichero de texto que tambin se sincronizara con el PocketPC y har la funcin de acceso directo. 18#"\Windows\evm.exe" <command line options> <class name> Donde evm es el ejecutable Jeode JVM, las opciones son equivalentes a las de la ejecucin de una jvm en un PC.
Pg: 41
Java Mvil J2ME
Constricciones al desarrollar para dispositivos mviles

Aunque Palm IIIx tiene una capacidad computacional y casi 4 veces la memoria que el primer Mac de Apple y superior al primer PC, debemos considerar estos dispositivos como "limitados" en comparacin con la vastedad de recursos de una computadora de sobremesa actual. Por tanto no debemos aplicar las premisas estndares de diseo de software cuando diseemos aplicaciones para estos dispositivos. Aunque enumeraremos las limitaciones de Palm, las premisas que se expongan son tambin validas para los PocketPC, todo y que la capacidad de estos es superior a las tradicionales Palm. A medida de que las computadoras son ms potentes, el software realiza ms trabajo, los recursos hardware han experimentado un crecimiento sorprendente, y para las aplicaciones estos pueden ser virtualizados de forma que no existan constricciones. Esta potencia permite realizar software ms elegante, fcil de mantener y que permiten cambios de diseo en tiempo de desarrollo. Este soporte a cambios aislados significa que otras partes de la aplicacin no estn afectadas; esto, a su vez, significa que los componentes que apoyan la funcionalidad existente no necesitan modificarse. Esto permite a la aplicacin soportar los cambios de una forma ms fiable y ms ordenada, a pesar de la naturaleza imprevisible de los cambios futuros. En un dispositivo mvil, sin embargo, estos principios de diseo pueden no ser aplicables en un entorno limitado. En un dispositivo mvil, las prioridades del diseo cambian. Los recursos limitados se deben asignar de forma que se consiga la mxima funcionalidad. La velocidad de ejecucin, del uso de memoria, y tamao de la pantalla es ms importante que un diseo elegante propio de una perspectiva orientada a objetos y que permita que los cambios sean aislados.
Pg: 42
Java Mvil J2ME
Limitaciones en capacidad de proceso

Un PC de escritorio dispone de una fuente de alimentacin ilimitada, que le permite funcionar a mxima velocidad y disipar cantidades grandes de calor. Un dispositivo Palm, por otra parte, es un dispositivo portable con la electricidad provista por bateras de 1,5 V. Los diseadores de Palm eligieron una CPU de bajo consumo para funcionar de forma que se maximizar la vida de la batera. Aunque sta era la decisin adecuada para un dispositivo portable pequeo, significa que el software para Palm se debe desarrollar con una visin bien clara de la cantidad de proceso que necesitara. Otro factor importante es que las tareas realizadas en PDAs se deben hacer muy rpidamente. El usuario de PDA desea realizar tareas simples que terminen rpidamente; el usuario no desea esperar al dispositivo para acabar tareas muy largas de cmputo. Los aplicaciones de Palm son (y deben ser) muy usables (en tiempo de respuesta) como mnimo tanto como un PC de escritorio que realice una tarea media. Si partimos de la premisa que un PC de escritorio es por lo menos 10 veces ms potente que un PDA, podemos afirmar que para mantener el mismo nivel de usabilidad, las aplicaciones de una PDA necesita limitarse a las tareas que son 10 veces ms simples. Dado que estamos utilizando el mismo lenguaje que utilizamos con xito en aplicaciones de PC, se acostumbra a caer en el error de desarrollar aplicaciones de la misma forma. En nuestras aplicaciones de escritorio nos aprovechamos de la potencia barata y hemos empleado bibliotecas extensas y ricas de clases para producir aplicaciones simples y elegantes. Utilizamos parsers XML para los archivos de configuracin y para detokenizar mensajes pasados como documentos XML; esto proporciona una compresin superior de los mensajes, pero no somos conscientes de la cantidad de proceso necesaria para realizar estas funciones. En el desarrollo de aplicaciones para PDA hemos de recordar que la aproximacin de desarrollo para PC no se puede aplicar sin considerar las diferencias de plataforma, y particularmente la disponibilidad de recursos. Una meta del diseo para cualquier aplicacin en PDAs es sacar tanto trabajo como sea posible a otra computadora, que puede ser un PC de escritorio o un servidor.
Pg: 43
Java Mvil J2ME
Limitaciones en el tamao De Pantalla

Disear para la simplicidad y la facilidad de uso es un aspecto importante del diseo de una aplicacin, sin importar la tecnologa o el medio. Una pantalla con una gran cantidad de controles o de informacin exhibida implica que el usuario tardara ms en absorber esta informacin, destacar que el numero de botones en una pantalla implica ms tiempo de aprendizaje de la aplicacin. Para ms pautas de cmo disear aplicaciones para Palm y conformes con otras aplicaciones, se recomienda la lectura de "Palm OS Programmer's Companion" documento nmero 3004-003. Este documento es parte del kit del desarrollo de software para Palm OS., En MIDP de Palm, un Form no se limita a un tamao particular al aadir Items. Por ejemplo, se desean agregar 20 StringItems en un Form, nada impedir hacerlo, pero en pantalla solo se mostraran los 11 primeros, ser necesario realizar scroll para visualizar el resto. Aunque es posible agregar ms artculos de los que pueden ser vistos en un Form, no se recomienda. Se realiza una aplicacin mas intuitiva si se evita el scrolling. Para el ejemplo anterior una lista seria una buena aproximacin.
Pg: 44
Java Mvil J2ME
Limitaciones en la capacidad de memoria (I)

Para argumentar por que Palm es un dispositivo limitado en memoria veremos como se organiza la memoria en este dispositivo. Para entender la organizacin de la memoria en MIDP de Palm OS, debemos ver como esta organizada esta, para realizar este paso se debe ejecutar la aplicacin developer incluido en el suite, y seleccionar show en developer preferences Esto nos mostrara una pantalla similar a la presentada Las descripciones que se muestran corresponden a MIDP de Sun para Palm y no a la organizacin de memoria para aplicaciones no Java.
Pg: 45
Java Mvil J2ME
Limitaciones en la capacidad de memoria (II)

Tipo ROM RAM Descripcin El tamao de la imagen ROM en este dispositivo. El tamao combinado de RAM en este dispositivo. Palm OS divide la RAM en dos reas lgicas: dinmica y almacenaje. Ambas reas siguen idnticas despus de apagar el dispositivo, pero un reset libera el rea dinmica. El tamao combinado del heap de almacenaje y dinmico del dispositivo: El heap dinmico" se refiere a la RAM para alocatacin dinmica como stack, alocataciones dinamicas de la aplicacin y del sistema. En Palm OS 3.5 con MB 4 o ms, el espacio dinmico es de 256 KB. Este espacio se libera si no est utilizada actualmente para las asignaciones dinmicas. el heap almacenamiento" es el resto de la RAM. Puede haber mas de un heap de almacenamiento, estos se utilizan para almacenar datos permanentes, tales como bases de datos. En todas las versiones de Palm OS hasta la 4.0, el chunk mximo de RAM de almacenamiento que se puede obtener por las aplicaciones es un poco menor de 64 o 128 KB (Depende de la versin). Este tamao se incrementa en la versin 5.0 El tamao de la memoria disponible en el heap de almacenamiento. El tamao del chunk mayor de almacenamiento. La cantidad de memoria disponible en el heap de Java. Esta es el rea del heap dinmico que utiliza Java al asignar nuevos objetos y stack de aplicacin, el valor mximo es poco menor de 64 KB La cantidad de memoria asignada internamente por el KVM.
freeram
freeheap maxheapchunk javafreeheap
permanent
Pg: 46
Java Mvil J2ME
Limitaciones en la capacidad de memoria (III)

Para ver cuanta memoria est disponible para el desarrollador, podemos escribir una sencilla aplicacin. Hay dos mtodos en la clase runtime que son tiles para trabajar con la memoria disponible. Son totalMemory y freeMemory. El fragmento siguiente del cdigo demuestra cmo determinar la memoria disponible dentro de un MIDlet:
Runtime runtime = Runtime.getRuntime(); runtime.gc(); System.out.println("Total: " + runtime.totalMemory() + " Free: " + runtime.freeMemory());
Destacar que se utiliza el mtodo gc de runtime antes de llamar el mtodo freeMemory. El propsito de esta llamada es obligar a la JVM a limpiar los objetos no utilizados y no liberador por el garbage collector porque la cantidad de memoria no es suficientemente baja para dispararlo. La cantidad de memoria devuelta por freeMemory puede ser diferente de la cantidad de memoria reportada por javafreeheap. Esto es porque el javafreeheap corresponde con el heap dinmico interno de Java para stack y nuevos objetos, mientras que freeMemory retorna una aproximacin de la cantidad de memoria disponible para la futura asignacin de objetos. El MIDlet MemoryMIDlet, StaticMemoryMIDlet, y MultipleClassMIDlet cada uno realiza una alocatacin de memoria diferente. MemoryMIDlet asigna un nuevo array de 1000 bytes.
Runtime runtime = Runtime.getRuntime(); runtime.gc(); beforeFree = runtime.freeMemory(); largeArray = new byte[1000]; runtime.gc(); afterFree = runtime.freeMemory(); System.out.println("Total: " + runtime.totalMemory() + " Free (before): " + beforeFree + " Free (after): " + afterFree);
Pg: 47
Java Mvil J2ME
Limitaciones en la capacidad de memoria (IV)

StaticMemoryMIDlet hace lo mismo, pero tambin tiene un array esttico de 2000 bytes:
static byte[] largeStaticArray = new byte[2000];
Finalmente, MultipleClassMIDlet crea una instancia de LargeClass , una clase con un atributo que referencia a un array de 1000 bytes:
LargeClass largeClass = new LargeClass();
donde LargeClass se define como:
package com.javamovil.small; public class LargeClass { private byte[] byteArray = new byte[1000]; public String method1(String s1, String s2) { return s1+s2; } public String method2(String s1, String s2) { return s1+s2; } }
El nmero de bytes devueltos por freeMemory() se ha registrado antes y despus la asignacin dinmica.
Pg: 48
Java Mvil J2ME
Limitaciones en la capacidad de memoria (V)

MIDlet MemoryMIDlet StaticMemoryMIDlet MultipleClassMIDlet Bytes Consumidos en cargar el Midlet 4396 6412 4392 Bytes que se consumirn en el proceso del comando "Allocate" 1016 1016 1032 Alocatacin hecha Allocatar un array de 1000 bytes Allocatar un array de 1000 bytes Allocatar una nueva instancia de LargeClass
De la tabla, se observa que un objeto array esttico toma el espacio del mismo heap de Java que se utiliza para asignar objetos dinmicos. Es decir, los objetos estticamente y dinmicamente asignados utilizan el mismo espacio del heap. Segn lo observado previamente, el espacio de heap se restringe a 64 KB en Palm OS 3.X y 4.X.
Pg: 49
Java Mvil J2ME
El Gestor de Aplicaciones
Estructura bsica de un Midlet (I)
El gestor de aplicaciones o AMS (Application Management System) es el software encargado de gestionar los MIDlets. Este software reside en el dispositivo y es el que nos permite ejecutar, pausar o destruir nuestras aplicaciones J2ME. A partir de ahora nos referiremos a l con las siglas de sus iniciales en ingls AMS, El AMS realiza dos grandes funciones:
Por un lado gestiona el ciclo de vida de los MIDlets. Por otro, es el encargado de controlar los estados por los que pasa el MIDlet mientras est en la memoria del dispositivo, es decir, en ejecucin.
Ciclo de vida de un MIDlet

El ciclo de vida de un MIDlet pasa por 5 fases: descubrimiento, instalacin, ejecucin, actualizacin y borrado. Estas fases son aplicables principalmente a las aplicaciones para telfonos mviles, con servicios asociados y generalmente de pago para la instalacin de aplicaciones en el dispositivo. Descubrimiento: Etapa que permite descargar aplicaciones de diversas formas, servicios de pago, conexin directa, etc. Instalacin: Etapa que se encarga del deploy de la aplicacin dejndola dispuesta para su uso. Ejecucin: A continuacin analizaremos con ms detalle esta fase. Actualizacin: Ciclo de vida del MIDlet, detectando si es una nueva instalacin o la actualizacin de un MIDlet existente. Borrado: Deben de controlarse los errores y garantizar el correcto borrado del o de los MIDlets
Pg: 50
Java Mvil J2ME
Estructura bsica de un Midlet (II)

Estados de un MIDlet
Un MIDlet durante su ejecucin pasa por 3 estados diferentes, estos tres estados son:
Activo: El MIDlet est actualmente en ejecucin. Pausa: El MIDlet no est actualmente en ejecucin. En este estado el MIDlet no debe usar ningn recurso compartido. Para volver a pasar a ejecucin tiene que cambiar su estado a Activo. A este estado se llegara por ejemplo si mientas se esta ejecutando la aplicacin se recibe un mensaje, una llamada, una alarma, etc. Destruido: El MIDlet no est en ejecucin ni puede transitar a otro estado. Adems se liberan todos los recursos ocupados por el MIDlet.
Como vemos en el diagrama, un MIDlet puede cambiar de estado mediante una llamada a los mtodos MIDlet.startApp(), MIDlet.pauseApp() o MIDlet.destroyApp(). El gestor de aplicaciones cambia el estado de los MIDlets haciendo una llamada a cualquiera de los mtodos anteriores. Un MIDlet tambin puede cambiar de estado por s mismo.
Pg: 51
Java Mvil J2ME
Estructura bsica de un Midlet (III)

Ahora vamos a ver por los estados que pasa un MIDlet durante una ejecucin tpica y cules 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 perodo de tiempo. El AMS por su parte crea una nueva instancia del MIDlet. Cundo el dispositivo est preparado para ejecutar el MIDlet, el AMS invoca al mtodo MIDlet.startApp() para entrar en el estado de Activo. El MIDlet entonces, ocupa todos los recursos que necesita para su ejecucin. Durante este estado, el MIDlet puede pasar al estado de Pausa por una accin del usuario, o bien, por el AMS que reducira 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 mtodo MIDlet.destroyApp(). Esto puede ocurrir porque el MIDlet haya finalizado su ejecucin o porque una aplicacin prioritaria necesite ser ejecutada en memoria en lugar del MIDlet. Una vez destruido el MIDlet, ste libera todos los recursos ocupados.
Pg: 52
Java Mvil J2ME
Estructura de un MIDlet
import javax.microedition.midlet.* public class MiMidlet extends MIDlet { public MiMidlet() { /* ste es el constructor de clase. Aqu debemos inicializar nuestras variables. */ } public startApp(){ /* Aqu incluiremos el cdigo que queremos que el MIDlet ejecute cundo se active. */ } public pauseApp(){ /* Aqu incluiremos el cdigo que queremos que el MIDlet ejecute cundo entre en el estado de pausa (Opcional) */ } public destroyApp(){ /* Aqu incluiremos el cdigo que queremos que el MIDlet ejecute cundo sea destruido. Normalmente aqu se liberaran los recursos ocupados por el MIDlet como memoria, etc. (Opcional) */ } }
Pg: 53
Java Mvil J2ME
El paquete javax.microedition.midlet (I)

El paquete javax.microedition.midlet define las aplicaciones MIDP y su comportamiento con respecto al entorno de ejecucin. Como ya sabemos, una aplicacin creada usando MIDP es un MIDlet.
Clase MIDlet
public abstract class MIDlet Un MIDlet es una aplicacin realizada usando el perfil MIDP como ya sabemos. La aplicacin debe extender esta clase para que el AMS pueda gestionar sus estados y tener acceso a sus propiedades. El MIDlet puede por s mismo realizar cambios de estado invocando a los mtodos apropiados. Los mtodos de los que dispone esta clase son los siguientes: protected MIDlet() Constructor de clase sin argumentos. Si la llamada a este constructor falla, se lanzara la excepcin SecurityException.
Pg: 54
Java Mvil J2ME
El paquete javax.microedition.midlet (II) protected abstract void destroyApp(boolean incondicional) throws

MIDletstateChangeException Indica la terminacin del MIDlet y su paso al estado de Destruido. En el estado de Destruido el MIDlet debe liberar todos los recursos y salvar cualquier dato en el almacenamiento persistente que deba ser guardado. Este mtodo puede ser llamado desde los estados Pausa o Activo. Si el parmetro incondicional es false, el MIDlet puede lanzar la excepcin MIDletstateChangeException para indicar que no puede ser destruido en este momento. Si es true, el MIDlet asume su estado de destruido independientemente de como finalice el mtodo. public final String getAppProperty(String key) Este mtodo proporciona al MIDlet un mecanismo que le permite recuperar el valor de las propiedades desde el AMS. Las propiedades se consiguen por medio de los archivos manifest y JAD. El nombre de la propiedad a recuperar debe ir indicado en el parmetro key. El mtodo nos devuelve un String con el valor de la propiedad o null si no existe ningn valor asociado al parmetro key. Si key es null se lanzar la excepcin NullPointerException. public final void notifyDestroyed() Este mtodo es utilizado por un MIDlet para indicar al AMS que ha entrado en el estado de Destruido. En este caso, todos los recursos ocupados por el MIDlet deben ser liberados por ste de la misma forma que si se hubiera llamado al mtodo MIDlet.destroyApp(). El AMS considerar que todos los recursos que ocupaba el MIDlet estn libres para su uso. public final void notifyPaused() Se notifica al AMS que el MIDlet no quiere estar Activo y que ha entrado en el estado de Pausa. Este mtodo slo debe ser invocado cundo el MIDlet est en el estado Activo. Una vez invocado este mtodo, el MIDlet puede volver al estado Activo llamando al mtodo MIDlet.startApp(), o ser destruido llamando al mtodo MIDlet.destroyApp(). Si la aplicacin es pausada por s misma, es necesario llamar al mtodo MIDlet.resumeRequest() para volver al estado Activo.
Pg: 55
Java Mvil J2ME
El paquete javax.microedition.midlet (III)

protected abstract void pauseApp() Indica al MIDlet que entre en el estado de Pausa. Este mtodo slo debe ser llamado cundo el MIDlet est en estado Activo. Si ocurre una excepcin RuntimeException durante la llamada a MIDlet.pauseApp(), el MIDlet ser destruido inmediatamente. Se llamar a su mtodo MIDlet.destroyApp() para liberar los recursos ocupados. public final void resumeRequest() Este mtodo proporciona un mecanismo a los MIDlets mediante el cual pueden indicar al AMS su inters en pasar al estado de Activo. El AMS, en consecuencia, es el encargado de determinar qu aplicaciones han de pasar a este estado llamando al mtodo MIDlet.startApp(). protected abstract void startApp() throws MIDletstateChangeException Este mtodo indica al MIDlet que ha entrado en el estado Activo. Este mtodo slo puede ser invocado cundo el MIDlet est en el estado de Pausa. En el caso de que el MIDlet no pueda pasar al estado Activo en este momento pero si pueda hacerlo en un momento posterior, se lanzara la excepcin MIDletstateChangeException. A travs de los mtodos anteriores se establece una comunicacin entre el AMS y el MIDlet. Por un lado tenemos que los mtodos startApp(), pauseApp() y destroyApp() los utiliza el AMS para comunicarse con el MIDlet, mientras que los mtodos resumeRequest(), notifyPaused() y notifyDestroyed() los utiliza el MIDlet para comunicarse con el AMS.
Pg: 56
Java Mvil J2ME
El paquete javax.microedition.midlet (IV)
Clase MIDletChangeStateException public class MIDletstateChangeException extends Exception Esta excepcin es lanzada cuando ocurre un fallo en el cambio de estado de un MIDlet.
Pg: 57
Java Mvil J2ME
Mi primer MIDlet
import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class HolaMundo extends MIDlet { private Display display; private Form screen; public HolaMundo() { display=Display.getDisplay(this); screen = new Form("HolaJME"); StringItem strItem = new StringItem(" ","Hola mundo"); screen.append(strItem); } public void startApp() throws MIDletStateChangeException{ display.setCurrent(screen); } public void pauseApp(){ } public void destroyApp(boolean unconditional){ display=null; screen=null; notifyDestroyed(); } }
Pg: 58
La interfaz de usuario (I)

Object CommandListener AlertType Command
Java Mvil J2ME
Ticker Font Graphics Item
Display Canvas
Diplayable Screen
Image Alert Form
ItemStateListener
List TextBox
ChoiceGroup DateField java.lang.* Gauge ImageItem StringItem TextField
Choice
javax.microedition.lcdui.*
Pg: 59
javax.microedition.lcdui.* (Interface)
Java Mvil J2ME
La interfaz de usuario: Displayable

Displayable es la clase padre de Screen y Canvas, estas proporcionan las funciones bsicas del interfaz de usuario de una aplicacin. Displayable puede tener un nmero de comandos, que son objetos visuales usados para iniciar una cierta accin en la aplicacin. Un comando se puede implementar de varias formas; boton, item del men, ... . Un comando tiene una etiqueta, un tipo, y una prioridad. La etiqueta es un string usado para distinguir el comando en la interfaz de usuario. El tipo del comando proporciona la implementacin del MIDP para tratar este comando. Los tipos del comando son: BACK, CANCEL, EXIT, HELP, ITEM, OK, SCREEN, y STOP. Dando a un comando un tipo CANCEL, por ejemplo, el desarrollador deja al MIDP el tratamiento de la informacin que se pudiera haber introducido que ser, a priori cancelada. Observe que para los tipos del comando con excepcin de SCREEN, la implementacin de MIDP puede modificar la etiqueta por una mas apropiada para el dispositivo. A Command se le puede dar una prioridad, que proporciona otra caracterstica de MIDP referente al orden con que este comando se debe exhibir respecto a otros comandos en la misma pantalla. Un nmero ms bajo indica una prioridad ms alta. Por ejemplo, para crear un nuevo comando que representa una accin para salir de la aplicacin, escribiramos lo siguiente:
Pg: 60
Java Mvil J2ME
La interfaz de usuario: Command

Command exitCommand = new Command("Exit", Command.EXIT, 10);
Esto indica a la aplicacin que el botn de salida debe aparecer al final de los command's del men dado que le hemos asignado una prioridad baja. Una vez que una aplicacin haya creado sus objetos Command, un objeto que implementa la interfaz CommandListener debe ser asignado para tratar los eventos. Esto se hace con el mtodo setCommandListener, invocado en un objeto derivado de Displayable. El interfaz de CommandListener especifica un mtodo, el commandAction, al que se le pasa el comando que es activado, y el objeto Displayable a el cual pertenece. La diferencia entre un Screen y Canvas es que el primero se utiliza como base para construir un interfaz de usuario basado en formularios, mientras que el segundo se utiliza para dibujar imgenes, lneas, y crculos. El curso se va a centrar en interfaces de usuario generados a partir de Screen. Hay cuatro tipos de Screen: Alarm, Form, List, y TextBox. Cualquiera de ellos puede tener agregados objetos Command, tal i como pueden tener un ttulo.
Pg: 61
Java Mvil J2ME
La interfaz de usuario: Form (I)

Una Form es un tipo especial de Screen, en el que se pueden colocar Items. Un Item es un control simple del interfaz de usuario, En un Form se pueden colocar varios Items. Las subclases de Item son botones de mltiple o simple seleccin, controles de fecha y de hora, control de barra, control de imagen, control de sting, y control de entrada de texto. Para crear un Form vacio:
Form mainForm = new Form("BaseUIMIDlet");
Recordemos crear el comando exit, para poder abandonar el MIDlet:

Command exitCommand = new Command("Salir", Command.EXIT, 10);
Debido a que una aplicacin puede tener varios objetos Displayable (es decir, muchas instancias de Form's, Alert's, List's, TextBox'es, y Canvas'es), y debido a que nicamente se puede ocupar el display con un objeto Displayable, necesitamos una forma de especificar qu Displayable debe ser visible. Esto se hace con la clase Display. Con un objeto Display, podemos descubrir que Displayable es actualmente visible, y podemos fijar que Displayable se har visible. Cada MIDlet tiene un Display. Para obtener una referencia a el, utilizaremos el mtodo esttico getDisplay en la clase Display, pasndole una referencia al objeto MIDlet. As pues, para nuestro ejemplo, necesitaremos una referencia al objeto Display:
Display display = null;
Pg: 62
Java Mvil J2ME
La interfaz de usuario: Form (II)

En el constructor del MIDlet, agregamos el comando exit y fijamos el MIDlet para ser el listener de este comando:
mainForm.addCommand(exitCommand); mainForm.setCommandListener(this);
En el mtodo startApp, obtenemos una referencia al Display del MIDlet, y fijamos el Display actual a nuestro Form recin creado:
display = Display.getDisplay(this); display.setCurrent(mainForm);
Dado que hemos fijado el MIDlet para ser el listener del comando exit, necesitamos implementar el mtodo commandAction para tomar las acciones apropiadas cuando suceda el evento del comando exit. A modo de ejemplo:
public void commandAction(Command c, Displayable d) { if (c == exitCommand) { destroyApp(false); notifyDestroyed(); } }
Pg: 63
Java Mvil J2ME
La interfaz de usuario: Form (III)

En el cdigo siguiente se observa un ejemplo que agrupa lo visto anteriormente. Dado que vamos a intentar que todos los ejemplos tengan el mismo comportamiento bsico, la clase de BaseUIMIDlet tambin proporcionar la clase base para todos los ejemplos de la interfaz de usuario.
package com.f2i.jmd.ui; import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class BaseUIMIDlet extends MIDlet implements CommandListener { protected Form mainForm = new Form("BaseUIMIDlet"); protected Command exitCommand = new Command("Salir", Command.EXIT, 10); protected Display display = null; protected static final String[] MOVIES = {"Gladiator", "The Patriot", "A Few Good Men"}; protected Command okCommand = new Command("OK", Command.SCREEN, 1); protected Command backCommand = new Command("Atras", Command.SCREEN, 2);
Pg: 64
Java Mvil J2ME
La interfaz de usuario: Form (IV)

public BaseUIMIDlet() { mainForm.addCommand(exitCommand); mainForm.setCommandListener(this); } public void startApp() { display = Display.getDisplay(this); display.setCurrent(mainForm); } public void pauseApp() { } public void destroyApp(boolean unconditional) { } public void commandAction(Command c, Displayable d) { if (c == exitCommand) { destroyApp(false); notifyDestroyed(); } } }
Pg: 65
Java Mvil J2ME
En el ejemplo anterior el comando salir se ha implementado como:
La interfaz de usuario: Form (V)
protected Command exitCommand = new Command("Salir",Command.EXIT, 10);
Esto sita la accin en el men Go, si se hubiera definido como Command.SCREEN se hubiera situado en el men Actions y tendra asociado un botn el la pantalla:
protected Command exitCommand = new Command("Salir",Command.SCREEN, 10);
Algunas implementaciones de MIDP pueden, sobrescribir la etiqueta definida para un command por la de defecto del dispositivo, esto no es as en la implementacin de Palm. Destacar que el tipo de comando obligara a que este aparezca en un determinado submen de opciones, p.ex. Si se define como Command.HELP, provocara que se situara en el submen Options:
protected Command exitCommand = new Command("Salir",Command.HELP, 10);
Pg: 66
Java Mvil J2ME
La interfaz de usuario: Form (VI)

Como se menciono previamente, la implementacin de MIDP determina cmo se dibujan los objetos de comando, dependiendo de las capacidades del dispositivo. En un dispositivo Palm usando el MIDP de Sun, los objetos Command de tipo SCREEN se dibujan como botones en el fondo de la pantalla. Si hay muchos Command's, o sus etiquetas hicieran los botones demasiado grandes para situarlos a lo largo de la pantalla, los Command's restantes se colocan como entradas de men en el men de Actions. En el ejemplo siguiente, se crearan seis Command's, todos ellos del tipo SCREEN, con igual prioridad, y los agregamos al Form anterior. Observar que crearemos una subclase de BaseUIMIDlet, esto lo realizaremos para todos los ejemplos, de modo que obtengamos el mismo comportamiento fundamental (y ahorremos un poco de trabajo).
Pg: 67
Java Mvil J2ME
La interfaz de usuario: Form (VII)

package com.f2i.jmd.ui; import javax.microedition.lcdui.*; public class CommandMIDlet extends BaseUIMIDlet { public Command command1Command = new Command("1", 1); public Command command2Command = new Command("2", 1); public Command command3Command = new Command("3", 1); public Command command4Command = new Command("4", 1); public Command command5Command = new Command("5", 1); public Command command6Command = new Command("6", 1); public CommandMIDlet() { super(); mainForm.setTitle("CommandMIDlet"); mainForm.addCommand(command1Command); mainForm.addCommand(command2Command); mainForm.addCommand(command3Command); mainForm.addCommand(command4Command); mainForm.addCommand(command5Command); mainForm.addCommand(command6Command); } } Command.SCREEN, Command.SCREEN, Command.SCREEN, Command.SCREEN, Command.SCREEN, Command.SCREEN,
Pg: 68
Java Mvil J2ME
La interfaz de usuario: Alert (I)

Un Alert es una pantalla que presenta texto y opcionalmente una imagen. Tpicamente, un Alert se utiliza para presentar una informacin para el usuario o para indicar que una accin urgente se debe tomar. Un Alert puede tener un time-out, o esperar a que el usuario la reconozca. Para crear un Alert y para fijar su temporizacin (a cinco segundos, por ejemplo), el cdigo seria:
Alert alert = new Alert("Alerta"); alert.setTimeout(5000); alert.setString("Esta es una alerta que se mostrara por 5 segundos");
Para mostrar el Alert, e ir de nuevo al Form principal cuando pase el tiempo, podemos utilizar el mtodo setCurrent que toma un Alert y un Displayable como parmetros.
display.setCurrent(alert, mainForm);
Los nmeros exhibidos en el crculo en la esquina izquierda inferior de la alerta indican el nmero de segundos restantes hasta el cierre de la alerta. Hay dos formas que la alerta no ser reconocida automticamente. La primera es si el texto de la alarma es demasiado grande para ser mostrado en una pantalla. En este caso, sin importar el valor del temporizador de la alerta, esta permanecer en pantalla hasta que el usuario la cierre.
Pg: 69
Java Mvil J2ME
La interfaz de usuario: Alert (II)

Para forzar una alarma a ser reconocida, se debe usar el valor de temporizador FOREVER, como en el siguiente ejemplo: Alert alert = new Alert("AlertaSiempre"); alert.setTimeout(Alert.FOREVER); alert.setString("Texto de la alerta"); display.setCurrent(alert, mainForm); En esta alerta queda en manos de MIDP dibujar el botn "Done". Una alerta puede tambin tener un tipo, que indica la naturaleza de la alerta. Las opciones son CONFIRMATION, WARNING, INFO, ERROR, y ALARM. El tipo de la alerta afecta al icono exhibido en la misma. El AlertType tambin se puede utilizar para reproducir un sonido que acompae la alerta. Este esta limitado a las capacidades del dispositivo. AlertType.WARNING.playSound(display);
Pg: 70
Java Mvil J2ME
La interfaz de usuario: Alert (II)
Una alerta es una buena herramienta para mostrar una pequea cantidad de informacin, las usaremos en los ejemplos siguientes para mejorar los conocimientos de los Form's. Para crear interfaces de usuario ms sofisticadas, tenemos la posibilidad de aadir objetos derivados de Item en los formularios. Destacar que los derivados de Item slo pueden aparecer en formularios.
Pg: 71
Java Mvil J2ME
La interfaz de usuario: ChoiceGroup (I)

Un ChoiceGroup se utiliza para obtener una sola seleccin o selecciones mltiples de un grupo de opciones. La implementacin de MIDP determina como se dibuja el objeto. En dispositivos Palm, los grupos de una nica seleccin se dibujan como listas de una sola seleccin, mientras que los grupos de seleccin mltiple se dibujan como cajas de seleccin. Los grupos de nica seleccin se crean:
protected static final String[] MEDIA = {"DVD", "VHS"}; ChoiceGroup singleChoice = new ChoiceGroup("Media",ChoiceGroup.EXCLUSIVE, MEDIA, null);
Para este ejemplo, se ha escogido un constructor que permite que las etiquetas sean especificadas como un array de strings. Se escoge no acompaar las opciones de imgenes, indicando el ultimo parmetro del constructor como null. Observar que tambin existe el tipo IMPLICIT. La nica diferencia entre EXCLUSIVE e IMPLICIT es que es posible registrar un objeto de CommandListener para el tipo IMPLICIT, y se notifica cuando la seleccin cambie. No hay notificacin para el tipo EXCLUSIVE. Se puede aadir un ChoiceGroup a un Form:
Form choiceForm = new Form("Seleccin de pelculas"); choiceForm.append(singleChoice);
Pg: 72
Java Mvil J2ME
La interfaz de usuario: ChoiceGroup (II)

Para obtener la seleccin del usuario se debe aadir al command listener del formulario un cdigo como el siguiente:
int i = singleChoice.getSelectedIndex(); String mediaSelected = singleChoice.getString(i);
Para selecciones mltiples se debe utilizar MULTIPLE como tipo:

ChoiceGroup multipleChoice = new ChoiceGroup("Pelculas", ChoiceGroup.MULTIPLE, MOVIES, null);
Para obtener las selecciones, un array de flags boleanos es utilizado por el mtodo getSelectedFlags:
boolean[] selections = new boolean[multipleChoice.size()]; multipleChoice.getSelectedFlags(selections);
El flag boleano correspondiente a la seleccin es puesto true si el usuario selecciono la opcin, un cdigo que hara lo descrito seria:
String movieSelected = new String(); boolean[] selections = new boolean[multipleChoice.size()]; multipleChoice.getSelectedFlags(selections); for (int j=0; j<selections.length; j++) if (selections[j]) movieSelected += multipleChoice.getString(j) + " on " + mediaSelected + "\n";
Colocando todo lo anterior en el MIDlet ChoiceGroupMIDlet mostrar un formulario con un grupo de seleccin simple, cuando el usuario presione el botn OK, se mostrara una alerta con las selecciones del usuario de ambos grupos.
Pg: 73

package com.f2i.jmd.ui; import javax.microedition.lcdui.*; public class ChoiceGroupMIDlet extends BaseUIMIDlet { protected static final String[] MEDIA = {"DVD", "VHS"}; protected Command choiceCommand = new Command("Choice", Command.SCREEN, 1);
Java Mvil J2ME
La interfaz de usuario: ChoiceGroup (III)
public ChoiceGroupMIDlet() { super(); mainForm.setTitle("ChoiceGroupMIDlet"); mainForm.addCommand(choiceCommand); } public void commandAction(Command c, Displayable d) { if (c == choiceCommand) { Form choiceForm = new Form("Seleccin de pelculas"); ChoiceGroup singleChoice = new ChoiceGroup("Media", ChoiceGroup.EXCLUSIVE, MEDIA, null); ChoiceGroup multipleChoice = new ChoiceGroup("Pelculas", ChoiceGroup.MULTIPLE, MOVIES, null); choiceForm.append(singleChoice); choiceForm.append(multipleChoice);
Pg: 74
Java Mvil J2ME
La interfaz de usuario: ChoiceGroup (IV)

choiceForm.addCommand(okCommand); choiceForm.addCommand(backCommand); choiceForm.addCommand(exitCommand); choiceForm.setCommandListener(this); display.setCurrent(choiceForm); } else if (c == okCommand) { Form choiceForm = (Form)d; ChoiceGroup singleChoice = (ChoiceGroup)(choiceForm.get(0)); ChoiceGroup multipleChoice = (ChoiceGroup)(choiceForm.get(1)); // Obtener la seleccin int i = singleChoice.getSelectedIndex(); String mediaSelected = singleChoice.getString(i); // get the movie selection String movieSelected = new String(); boolean[] selections = new boolean[multipleChoice.size()]; multipleChoice.getSelectedFlags(selections); for (int j=0; j<selections.length; j++) if (selections[j]) movieSelected += multipleChoice.getString(j) + " on " + mediaSelected + "\n";
Pg: 75
Java Mvil J2ME
La interfaz de usuario: ChoiceGroup (V)

// Mostrar el resultado Alert alert = new Alert(Seleccin"); alert.setString(movieSelected); alert.setTimeout(5000); alert.setType(AlertType.INFO); display.setCurrent(alert, mainForm); } else if (c == backCommand) { display.setCurrent(mainForm); } else { super.commandAction(c, d); } } }
Pg: 76
Java Mvil J2ME
La interfaz de usuario: DateField (I)

La clase DateField provee una forma de mostrar y entrar fechas y horas, se muestra un cdigo de ejemplo:
DateField startDateField = new DateField("Fecha de vencimiento", DateField.DATE_TIME); startDateField.setDate(new Date()); mainForm.append(startDateField);
La fecha y hora que se muestra va fijada en un objeto Date, en el ejemplo anterior se utiliza el los datos actuales del dispositivo, para fijar unos datos se puede utilizar lo siguiente:
DateField returnDateField = new DateField("Fecha de vuelta", DateField.DATE_TIME); Calendar calendar = Calendar.getInstance(); calendar.setTime(tomorrow()); calendar.set(Calendar.HOUR, 10); calendar.set(Calendar.MINUTE, 0); calendar.set(Calendar.AM_PM, Calendar.PM); returnDateField.setDate(calendar.getTime()); mainForm.append(returnDateField);
Dado que MIPD no dispone de tipos para calculo de fechas estos se debern realizar manualmente:
private Date manana() { Date hoy = new Date(); Date manana = new Date(hoy.getTime()+(24*60*60*1000)); return manana; }
Pg: 77
Java Mvil J2ME
La interfaz de usuario: DateField (II)

package com.f2i.jmd.ui; import javax.microedition.lcdui.*; import java.util.*; public class DateFieldMIDlet extends BaseUIMIDlet { public DateFieldMIDlet() { super(); mainForm.setTitle("DateFieldMIDlet"); DateField startDateField = new DateField("Fecha de vencimiento", DateField.DATE_TIME); startDateField.setDate(new Date()); mainForm.append(startDateField); DateField returnDateField = new DateField("Fecha de vuelta", DateField.DATE_TIME); Calendar calendar = Calendar.getInstance(); calendar.setTime(manana()); calendar.set(Calendar.HOUR, 10); calendar.set(Calendar.MINUTE, 0); calendar.set(Calendar.AM_PM, Calendar.PM); returnDateField.setDate(calendar.getTime()); mainForm.append(returnDateField); }
Pg: 78
Java Mvil J2ME
La interfaz de usuario: DateField (III)

private Date manana() { Date hoy = new Date(); Date manana = new Date(hoy.getTime()+(24*60*60*1000)); return manana; } public void commandAction(Command c, Displayable d) { super.commandAction(c, d); } }
Pg: 79
Java Mvil J2ME
La interfaz de usuario: Gauge (I)

Gauge se utiliza para mostrar y editar un valor en un rango, el cdigo para su creacin seria:
Gauge gauge = new Gauge("Valor", true, 20, 5); gaugeForm.append(gauge);
El primer parmetro especifica la etiqueta, el segundo es un boleano que indica si es editable, el tercero el valor final, y el ltimo el inicial. El valor puede ser recuperado con el mtodo getValue del objeto, la forma de dibujo puede variar en funcin de que el Gauge sea editable.
package com.f2i.jmd.ui; import javax.microedition.lcdui.*; import java.lang.Integer; public class GaugeMIDlet extends BaseUIMIDlet { protected Gauge gauge1; protected Gauge gauge2; public GaugeMIDlet() { super(); mainForm.setTitle("GaugeMIDlet"); gauge1 = new Gauge("Valor 1", true, 20, 5); mainForm.append(gauge1); gauge2 = new Gauge("Valor 2", false, 20, 5); mainForm.append(gauge2);
Pg: 80
Java Mvil J2ME
La interfaz de usuario: Gauge (II)

mainForm.addCommand(okCommand); mainForm.setCommandListener(this); } public void commandAction(Command c, Displayable d) { if (c == okCommand) { int valor=gauge1.getValue(); Integer valin = new Integer(valor); Alert alert = new Alert("Valor selecionado"); alert.setString("El Valor es " + valin.toString()); alert.setTimeout(5000); alert.setType(AlertType.INFO); display.setCurrent(alert, mainForm); gauge2.setValue(valor); } else { super.commandAction(c, d); } } }
Pg: 81
Java Mvil J2ME
La interfaz de usuario: StringItem (I)

Un StringItem es un Item utilizado para Mostar texto esttico en un Form. Esta formado por una etiqueta y el texto en si. Este no se puede editar por el usuario:
StringItem addressLine1 = new StringItem("Direccin 1", "Sabadell, 67"); stringItemForm.append(addressLine1);
Ejemplo:
package com.f2i.jmd.ui; import javax.microedition.lcdui.*; public class StringItemMIDlet extends BaseUIMIDlet { private Command stringItemCommand = new Command("StringItem", Command.SCREEN, 1); public StringItemMIDlet() { super(); mainForm.setTitle("StringItemMIDlet"); mainForm.addCommand(stringItemCommand); } public void commandAction(Command c, Displayable d) { if (c == stringItemCommand) { Form stringItemForm = new Form("Detalles de direccin"); StringItem addressLine1 = new StringItem("Direccin 1", "Sabadell, 67");
Pg: 82
Java Mvil J2ME
La interfaz de usuario: StringItem (II)

StringItem addressLine2 = new StringItem("Direccin 2", "Barcelona"); StringItem postcode = new StringItem("Cdigo Postal", "08003"); stringItemForm.append(addressLine1); stringItemForm.append(addressLine2); stringItemForm.append(postcode); stringItemForm.addCommand(backCommand); stringItemForm.addCommand(exitCommand); stringItemForm.setCommandListener(this); display.setCurrent(stringItemForm); } else if (c == backCommand) { display.setCurrent(mainForm); } else { super.commandAction(c, d); } } }
Pg: 83
Java Mvil J2ME
La interfaz de usuario: TextField (I)

Un elemento TextField es similar en aspecto a un StringItem, excepto que un TextField permite al usuario modificar o introducir el texto. Un TextField puede tambin aplicar filtros al texto que se introduce; el filtro se considera una mascara de entrada. Para crear un TextField con el contenido del texto inicializado, utilizan al constructor siguiente:
TextField addressLine1 = new TextField("Direccin 1", "Sabadell, 67", 20, TextField.ANY);
El ltimo parmetro pasado al constructor es donde las mascaras de entrada pueden ser especificados. Las mascaras disponibles son ANY, EMAILADDR, NUMERIC, PASSWORD, PHONENUMBER, y URL. En cada caso, nicamente la entrada indicada por la mascara ser aceptada por el campo. Cuando el usuario ha acabado de modificar o incorporar del texto, el texto del campo puede ser recuperado llamando el mtodo getString. El cdigo siguiente muestra cmo un TextField se podra utilizar en una aplicacin:
package com.f2i.jmd.ui; import javax.microedition.lcdui.*; public class TextFieldMIDlet extends BaseUIMIDlet { private Command textFieldCommand = new Command("TextField", Command.SCREEN, 1);
Pg: 84

public TextFieldMIDlet() { super(); mainForm.setTitle("TextFieldMIDlet"); mainForm.addCommand(textFieldCommand); } public void commandAction(Command c, Displayable d) { if (c == textFieldCommand) { Form textFieldForm = new Form("Confirme su direccin"); TextField addressLine1 = new TextField("Direccin 1", "Sabadell, 67", 20, TextField.ANY); TextField addressLine2 = new TextField("Direccin 2", "Barcelona", 20, TextField.ANY); TextField postcode = new TextField("Cdigo Postal", "08003", 5, TextField.NUMERIC); textFieldForm.append(addressLine1); textFieldForm.append(addressLine2); textFieldForm.append(postcode); textFieldForm.addCommand(okCommand); textFieldForm.addCommand(backCommand); textFieldForm.addCommand(exitCommand); textFieldForm.setCommandListener(this); display.setCurrent(textFieldForm); }
Pg: 85
Java Mvil J2ME
La interfaz de usuario: TextField (II)
Java Mvil J2ME
La interfaz de usuario: TextField (III)

else if (c == okCommand) { Form textFieldForm = (Form)d; TextField addressLine1 = (TextField)(textFieldForm.get(0)); TextField addressLine2 = (TextField)(textFieldForm.get(1)); TextField postcode = (TextField)(textFieldForm.get(2)); // display the result Alert alert = new Alert("Direccin entrada"); alert.setString("La direccin es:\n" + addressLine1.getString() + "\n" + addressLine2.getString() + "\n" + postcode.getString()); alert.setTimeout(5000); alert.setType(AlertType.INFO); display.setCurrent(alert, mainForm); } else if (c == backCommand) { display.setCurrent(mainForm); } else { super.commandAction(c, d); } } }
Hasta ahora hemos utilizado dos subclases de Screen, que son Alert y Form, a continuacin vamos a estudiar los otros dos tipos: List y TextBox
Pg: 86
Java Mvil J2ME
La interfaz de usuario: List (I)

La lista es un tipo de Screen que permite al usuario seleccionar elementos. Tanto List como ChoiceGroup se basan en el mismo interfaz. La principal diferencia es el mbito de utilizacin, un ChoiceGroup siempre se deber utilizar dentro de un formulario. List soporta los mismos tipos, todo y que la implementacin no tiene por que ser la misma que en ChoiceGroup, recordmoslos: IMPLICIT, EXCLUSIVE, y MULTIPLE. La creacin se realizara del siguiente modo:
List list = new List("Pelculas", List.EXCLUSIVE, MOVIES, null);
Como en ChoiceGroup, la seleccin se recupera de la lista usando los mtodos getSelectedIndex y getString:
int i = list.getSelectedIndex(); String movieSelected = list.getString(i);
Una lista MULTIPLE se crea de forma similar, y las selecciones se recuperan de la misma manera que las selecciones mltiples para un ChoiceGroup.
List list = new List("Pelculas", List.MULTIPLE, MOVIES, null); String movieSelected = new String(); boolean[] selections = new boolean[list.size()]; list.getSelectedFlags(selections); for (int i=0; i<selections.length; i++) if (selections[i]) movieSelected += list.getString(i) + "\n";
Pg: 87
Java Mvil J2ME
La interfaz de usuario: List (II)

Seria interesante construir un cdigo que pusiera en practica los dos tipos de lista, utilizando la lista de pelculas de BaseUIMIDlet, de forma similar a como se ha ido realizando en los apartados anteriores, el resultado debera ser algo similar a:
Pg: 88
Java Mvil J2ME
La interfaz de usuario: TextBox

El TextBox es un tipo de pantalla que permite la entrada de texto en formato libre. En un dispositivo Palm se visualiza como una pantalla de Memo. El TextBox utiliza el mismo concepto de mascaras de entrada que TextField. El modo de creacin seria:
TextBox textBox = new TextBox("Pelculas", "", 20, TextField.ANY);
Para recuperar el contenido:

String movieSelected = textBox.getString();
Pg: 89
Java Mvil J2ME
La interfaz de usuario: Ticker

Por ltimo vamos a analizar la clase Ticker, los objetos Ticker son como letreros con informacin que se desplaza. Un objeto Ticker se crea del siguiente modo:
Ticker ticker = new Ticker("Informacin: Llevese 2 pelculas al precio de 1...");
El Ticker se muestra en cualquier objeto derivado de Screen, usando el mtodo del setTicker. El MIDlet siguiente es igual que el ChoiceGroupMIDlet, excepto que se ha aadido un Ticker en cada pantalla de la aplicacin.
Ticker en el formulario principal, en la demostracin de ChoiceGroup y en un Alert

Pg: 90
Java Mvil J2ME
Almacenamiento de informacin (I)

Dado que un PDA no se puede conectar siempre con un servidor de el cual recuperar la informacin, almacenar la informacin en el dispositivo local es muy importante. A continuacin exploraremos los mtodos disponibles para almacenar informacin. MIDP proporciona unas APIs simples de base de datos de sistema para almacenar la informacin en el dispositivo. El sistema de APIs se llama "Record Management System" (RMS). Estas APIs incluye mtodos para crear, para actualizar, para buscar, y para suprimir bases de datos. La implementacin de la base de datos se deja en manos de la correspondiente implementacin de MIDP en el dispositivo. En los dispositivos Palm, la base de datos del RMS se implementa como una DB de Palm OS. A continuacin estudiaremos la API RMS para almacenar informacin.
Pg: 91
Java Mvil J2ME
Almacenamiento de informacin (II) Las propiedades de estos almacenes de registros son:

1. 2. 3. 4. 5. Cada Record Store est compuesto por cero o ms registros. Un nombre de Record Store es sensible a maysculas y minsculas y est formado por un mximo de 32 caracteres UNICODE. Dentro de una suite no pueden coexistir dos Record Stores con el mismo nombre. Si una suite de MIDlets es borrada del dispositivo MID, todos los RecordStores pertenecientes a esa suite se borrarn. Es posible que un MIDlet acceda a un Record
Adems de un nombre, cada Record Store tambin posee otros dos atributos:
Nmero de versin: Es un valor entero que se actualiza conforme vayamos insertando, modificando o borrando registros en el Record Store. Podemos consultar este valor invocando al mtodo RecordStore.getVersion(). Marca temporal: Es un entero de tipo long que representa el nmero de milisegundos desde el 1 de enero de 1970 hasta el momento de realizar la ltima modificacin en el Record Store. Este valor lo podemos obtener invocando al mtodo RecordStore.getLastModified().
Pg: 92
Java Mvil J2ME
Mtodos generales de RecordStore
Pg: 93
Java Mvil J2ME
Manipulacin de registros
Pg: 94
Java Mvil J2ME
Uso de RecordStore (I)

La API RMS se encuentra en el paquete javax.microedition.rms del MIDP. La clase central del paquete es RecordStore, que representa un almacn RMS. La clase de RecordStore se utiliza para realizar todas las operaciones en los registros. Las operaciones disponibles para el desarrollador son:
Crear, Abrir, Cerrar o Suprimir un RecordStore. Agregue un nuevo registro, suprima un registro, iterar sobre los registros. Filtros y comparadores pueden desarrollarse para clasificar y filtrar los registros segn lo deseado. Obtenga la informacin sobre un RecordStore, nmero de registros, tamao, la cantidad de memoria restante para el RecordStore, su nombre, el tiempo que la ultima modificacin, y el nmero de veces que se ha modificado (es decir, la versin). Vincular un "listener" para recibir una notificacin cuando se modifica un registro.
Para crear y para abrir un RecordStore nuevo, utilizamos el mtodo esttico openRecordStore sobre un objeto RecordStore:
store = RecordStore.openRecordStore(recordStoreName, true);
El segundo parmetro del openRecordStore es un valor boleano para indicar si deseamos generar una excepcin si no existe el RecordStore. Si el valor es true, openRecordStore crear un nuevo RecordStore si no puede encontrar uno existente con el nombre facilitado, abrindolo, y retornando una referencia al objeto. Se retorna una referencia al objeto, por lo que mas de un MIDlet de la misma suite puede acceder al RecordStore.
Pg: 95
Java Mvil J2ME
Uso de RecordStore (II)

Si nicamente se desea abrir un RecordStore se puede utilizar false en este parmetro. En este caso, una excepcin de tipo RecordStoreNotFoundException se lanzara si no existiese el RecordStore. Para obtener informacin sobre el RecordStore, los siguientes mtodos de la clase de RecordStore se pueden utilizar:
StringBuffer result = new StringBuffer(); result.append("Nombre: " + store.getName() + "\n"); result.append("Registros: " + store.getNumRecords() + '\n'); result.append("Tamao: " + store.getSize() + " bytes\n"); result.append("Bytes disponibles: " + store.getSizeAvailable() + " bytes\n"); result.append("Versin: " + store.getVersion() + "\n");
Para cerrar un RecordStore, llamamos simplemente el mtodo closeRecordStore del objeto RecordStore:
store.closeRecordStore();
Observar que cada llamada del mtodo del openRecordStore necesita el correspondiente closeRecordStore. Se debe tener en cuenta que en cada ocasin que se llama a openRecordStore se incrementa un contador de referencia, por tanto es necesario realizar closeRecordStore para decrementar este contador. El RecordStore no se cierra realmente hasta que el contador es cero.
Pg: 96
Java Mvil J2ME
Uso de RecordStore (III)

Para eliminar totalmente un RecordStore, utilizamos el mtodo deleteRecordStore:
RecordStore.deleteRecordStore(recordStoreName);
Dado que un RecordStore se puede compartir por los MIDlets de una suite, puede ser posible que otro MIDlet est teniendo acceso al RecordStore que estamos intentando suprimir. En ese caso, el mtodo deleteRecordStore lanzar una RecordStoreException. La informacin se almacena en el RecordStore en forma de registros, y cada registro es un array de bytes. Los mtodos para guardar y recuperar registros de un RecordStore deben realizarlo como un array de bytes. Como primera instancia, tener que almacenar la informacin como array de bytes puede parecer un mecanismo incmodo. Sin embargo, con el uso de ByteArrayOutputStream, de ByteArrayInputStream, DataOutputStream y DataInputStream, no es tan complicado como podra parecer. Como ejemplo podemos modificar la aplicacin para ordenar pelculas en videos o DVDs. El objeto bsico podra ser el siguiente:
Pg: 97
Java Mvil J2ME
Uso de RecordStore: Ejemplo

package com.f2i.jmd.persistence.rms; import java.io.*; public class Movie { public String title; public String actors; public long yearReleased; public Movie() { } public Movie(String title, String actors, long yearReleased) { this.title = title; this.actors = actors; this.yearReleased = yearReleased; } public String toString() { StringBuffer result = new StringBuffer(title); result.append(", estrenado "); result.append(yearReleased); result.append(", estrellas "); result.append(actors); return result.toString(); } }
Pg: 98
Java Mvil J2ME
Uso de RecordStore: Serializacin (I)

El perfil MID no define un esquema para serializacin. Vamos a definir un esquema simple de serializacin para almacenar objetos en RMS que despus tambin podra ser utilizado para enviar estos objetos sobre una red. Para el esquema simple de serializacin, definimos un interfaz que tenga dos mtodos:
package com.f2i.jmd.persistence.rms; import java.io.*; public abstract interface Serializable { public void writeObject(DataOutputStream dos) throws IOException; public void readObject(DataInputStream dis) throws IOException; }
Los objetos que implementen este interfaz deben definir una forma especifica de guardar el estado del objeto hacia un DataOutputStream, y de recuperar de (implementar serializable a la definicin de la clase) un DataInputStream. As pues, necesitamos agregar dos mtodos a nuestra clase Movie:
Pg: 99
Java Mvil J2ME
Uso de RecordStore: Serializacin (II)

public void writeObject(DataOutputStream dos) throws IOException { dos.writeUTF(title); dos.writeUTF(actors); dos.writeLong(yearReleased); } public void readObject(DataInputStream dis) throws IOException { title = dis.readUTF(); actors = dis.readUTF(); yearReleased = dis.readLong(); }
Utilizaremos un DataOutputStream con un ByteArrayOutputStream por debajo para escribir el objeto a un registro RecordStore. La ventaja de este esquema simple para la serializacin es que no hay necesidad de cambiar la definicin de la clase Movie tanto para almacenar su contenido como mas adelante para enviar este contenido sobre un conexin HTTP. Por tanto en J2SE, la forma de escribir un array de bytes es crear un DataOutputStream con un ByteArrayOutputStream asociado:
Pg: 100
Java Mvil J2ME
Uso de RecordStore: Serializacin (III)

ByteArrayOutputStream bos = new ByteArrayOutputStream(); DataOutputStream dos = new DataOutputStream(bos);
Una vez se haya creado el DataOutputStream, podemos enviarlo al objeto Movie para que se guarde a si mismo:
movie.writeObject(dos); //Escribe el objeto en el Stream
Dado que DataOutputStream tiene un ByteArrayOutputStream asociado, es fcil obtener el contenido del stream en forma de un array de bytes:
byte[] ba = bos.toByteArray();
Para guardar este array en el RecordStore, utilizamos el mtodo addRecord en el objeto RecordStore:
store.addRecord(ba, 0, ba.length);
Para recuperar un objeto del RecordStore, utilizamos un DataInputStream con un ByteArrayInputStream asociado. Llamando el mtodo del readObject en el objeto Movie, se leer el array de bytes del registro, rellenndose el objeto con la informacin de la pelcula guardada es ese registro:
ByteArrayInputStream bis = new ByteArrayInputStream(store.getRecord(recordId)); DataInputStream dis = new DataInputStream(bis); Movie movie = new Movie(); movie.readObject(dis);
Pg: 101
Java Mvil J2ME
RecordEnumeration
Para recuperar un conjunto de registros del RecordStore, RMS proporciona el interfaz RecordEnumeration. RecordEnumeration proporciona la capacidad de avanzar y retroceder sobre los registros del RecordStore. Para obtener un RecordEnumeration, se debe llamar el mtodo enumerateRecords en el objeto RecordStore:
RecordEnumeration re = store.enumerateRecords(this, this, false);
Pg: 102
Java Mvil J2ME
RecordEnumeration: Filtros (I)

El primer parmetro proporciona la capacidad de aplicar un filtro en la enumeracin. El filtro es un objeto que implementa el interfaz RecordFilter, esto implica que dispone de un mtodo matches. El mtodo matches retorna true si el registro se incluir en la enumeracin. Como ejemplo, si se desearan todas las pelculas con el ttulo que comenzara con "The" se desarrollara un mtodo matches como sigue:
public boolean matches(byte[] candidate) { boolean result = true; Movie movie = null; try { ByteArrayInputStream bis = new ByteArrayInputStream( candidate); DataInputStream dis = new DataInputStream(bis); movie = new Movie(); movie.readObject(dis); } catch (Exception e) { System.out.println(e); e.printStackTrace(); } result = movie.title.startsWith("The"); return result; }
Pg: 103
Java Mvil J2ME
RecordEnumeration: Filtros (II)

El mtodo matches se llama para cada registro en el RecordStore, proporcionando un array de bytes al mtodo para que pueda validar la condicin del filtro. En el ejemplo anterior, se lee el objeto Movie del DataInputStream (con el ByteArrayInputStream asociado) y se prueba si su ttulo comienza con los caracteres "The". Si es as se retorna true y el registro se incluye en la enumeracin. Si no se provee ningn objeto para el filtro todos los registros del RecordStore se incluyen en la enumeracin. El segundo parmetro del mtodo enumerateRecords proporciona la capacidad de especificar un orden en la enumeracin. Si un objeto implementa la interfaz RecordComparator se especifica como el segundo parmetro, el mtodo compare del interfaz se llamara para cada par de registros en el RecordStore. Por ejemplo, si se deseara clasificar los registros por orden alfabtico del ttulos de la pelcula, se debera desarrollar un mtodo compare similar al siguiente:
Pg: 104
Java Mvil J2ME
RecordEnumeration: Ordenacin (I)

public int compare(byte[] rec1, byte[] rec2) { Movie movie1 = null; Movie movie2 = null; try { ByteArrayInputStream bis1 = new ByteArrayInputStream(rec1); DataInputStream dis1 = new DataInputStream(bis1); movie1 = new Movie(); movie1.readObject(dis1); ByteArrayInputStream bis2 = new ByteArrayInputStream(rec2); DataInputStream dis2 = new DataInputStream(bis2); movie2 = new Movie(); movie2.readObject(dis2); } catch (Exception e) { System.out.println(e); e.printStackTrace(); } // ordenar por titulo int result = movie1.title.compareTo(movie2.title);
Pg: 105
Java Mvil J2ME
RecordEnumeration: Ordenacin (II)

if (result < 0) { return RecordComparator.PRECEDES; } else if (result > 0) { return RecordComparator.FOLLOWS; } else { return RecordComparator.EQUIVALENT; } }
Para cada par de registros en el RecordStore (despus de que se ha aplicado el filtro), el correspondiente par de array de bytes se enva al mtodo compare. Como antes, es posible convertir los byte arrays en objetos Movie. Si el ttulo del primer objeto de la pelcula precede lxicograficamente al ttulo del segundo, el mtodo compare retorna RecordComparator.PRECEDES una constante predefinida. Si el ttulo de la primera pelcula sigue al ttulo de la segunda, el mtodo compare retorna RecordComparator.FOLLOWS. Si son iguales, el mtodo retorna RecordComparator.EQUIVALENT. Si no se provee ningn comparador al mtodo enumerateRecords, los registros se clasifican en un orden indefinido.
Pg: 106
Java Mvil J2ME
RecordStore: Ejemplo
Se adjunta el cdigo de las clases Movie, Serializable y RmsMIDlet, que sirven de demostracin de lo expuesto anteriormente. A continuacin se exponen una pantallas de ejemplo del el cdigo anterior:
Pg: 107
Java Mvil J2ME
RecordListener (I)
La API RMS incluye la capacidad de definir un objeto record listener, que seguir la actividad del RecordStore. Un objeto que implementa la interfaz RecordListener se puede agregar como listener a un RecordStore, y los mtodos de notificacin provistos por el interfaz sern llamados cuando un registro del RecordStore se aada, se actualice, o se suprima. Para registrar un listener se debe usar el mtodo addRecordListener en el objeto RecordStore:
store.addRecordListener(this);
A partir de ese momento y hasta que se cierre el RecordStore, el objeto referido por this ser notificado cuando el RecordStore cambie. Tres mtodos separados se definen en el interfaz de RecordListener:
public void recordAdded(RecordStore store, int recordId); public void recordChanged(RecordStore store, int recordId); public void recordDeleted(RecordStore store, int recordId);
Para demostrar cmo trabaja un record listener, podemos ampliar el ejemplo anterior RmsMIDlet para agregar registros de pelculas en un thread diferente ejecutado en background. El objeto de MIDlet se registra como RecordListener, y el correspondiente mtodo es invocado cada vez el thread agrega un nuevo registro a Movie. [NOTA] Palm OS no soporta de forma nativa los threads en background. Sin embargo, la definicin de CLDC impone el soporte a threads, por tanto la KVM implementa este soporte.
Pg: 108
Java Mvil J2ME
RecordListener (II)
En primer lugar se creara el thread referenciado:
package com.f2i.jmd.persistence.rms; import java.io.*; import javax.microedition.rms.*; public class RmsThread extends Thread { int count = 0; Movie[] movies = null; RecordStore store = null; public RmsThread(int count, Movie[] movies, RecordStore store) { this.count = count; this.movies = movies; this.store = store; }
Pg: 109
Java Mvil J2ME
RecordListener (III)
public void run() { try { // aadir el numero especificado de pelculas en el RecordStore, // pausa entre cada registro aadido for (int i=0; i<count; i++) { ByteArrayOutputStream bos = new ByteArrayOutputStream(); DataOutputStream dos = new DataOutputStream(bos); Movie movie = movies[i % movies.length]; // escribir el objeto en el stream movie.writeObject(dos); byte[] ba = bos.toByteArray(); store.addRecord(ba, 0, ba.length); // esperamos sobre 1 segundo sleep(1000); } store.closeRecordStore(); } catch (Exception e) { e.printStackTrace (); } } }
Pg: 110
Java Mvil J2ME
RecordListener (IV)
Esta clase derivada de thread inserta un nuevo registro y queda en pausa por un segundo, repitiendo este proceso un determinado numero de veces. A continuacin se debe definir un nuevo Command Inicio que ponga en ejecucin el thread.
Command startCommand = new Command("Inicio", Command.SCREEN, 1); ... mainForm.addCommand(startCommand); ... if (c == startCommand) { store = RecordStore.openRecordStore(recordStoreName, true); store.addRecordListener(this); RmsThread thread = new RmsThread(5, movies, store); thread.start(); }
Por ltimo, es necesario implementar los mtodos del RecordListener. En este ejemplo, recuperaremos el registro de la pelcula y mostraremos el ttulo del registros agregado o actualizado. Observar que al intentar recuperar el registro afectado en el mtodo recordDeleted fallar, y una excepcin del tipo InvalidRecordIDException se lanzar:
Pg: 111
Java Mvil J2ME
RecordListener (V)
public void recordAdded(RecordStore store, int recordId) { resultItem.setLabel ("Status:"); resultItem.setText("Pelcula aadida: " + getMovieFromRecord(store, recordId).title); } public void recordChanged(RecordStore store, int recordId) { resultItem.setLabel ("Status:"); resultItem.setText("Pelcula actualizada: " + getMovieFromRecord(store, recordId).title); } public void recordDeleted(RecordStore store, int recordId) { resultItem.setLabel ("Status:"); resultItem.setText("Pelcula eliminada: " + recordId); }
Pg: 112
Java Mvil J2ME
RecordListener (VI)
Ahora es necesario implementar el correspondiente getMovieFromRecord como sigue:
Movie getMovieFromRecord(RecordStore store, int recordId) { Movie movie = new Movie(); try { ByteArrayInputStream bis = new ByteArrayInputStream(store.getRecord(recordId)); DataInputStream dis = new DataInputStream(bis); movie.readObject(dis); } catch (Exception e) { System.out.println(e); e.printStackTrace(); } return movie; }
Pg: 113
Java Mvil J2ME
RecordStores en Palm OS
La implementacin de los RecordStores es dependiente del dispositivo, y puede variar entre plataformas. Esta implementacin no esta definida en las especificaciones de MIDP ni en las de CLDC. La implementacin de Palm OS utiliza una base de datos del dispositivo para guardar los RecordStores. Se puede acceder a esta DB de forma idntica a otras DB de Palm, por ejemplo para sincronizar los datos, simplemente seria necesario crear un driver de acceso, pero esto no se recomienda por la siguientes razones:
El formato de la base de datos no se especifica ni se soporta, y puede cambiar. Hay maneras soportadas de transferir informacin a y desde un dispositivo.
Los estndares se deben utilizar siempre que sea posible por las siguientes razones:
Los estndares simplifican la migracin de aplicaciones a otras plataformas soportadas. Los estndares facilitan la lectura del cdigo generado por nosotros. Una aplicacin conforme a un estndar es mas fcil que funcione en modelos posteriores. Una aplicacin que siga los estndares tendr ms posibilidades de utilizar las nuevas caractersticas que dispongan las prximas versiones de la plataforma
Si an as se desea acceder directamente a las DB de Palm OS en este link se podr encontrar ms informacin:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0108&L=kvminterest&D=0&H=0&O=T&T=1&P=49045%20.
Pg: 114
Java Mvil J2ME
Otras Bases de Datos para Java

Si una aplicacin necesitara mas de lo aportado por RMS de MIDP se podran adquirir productos de terceros como los que se exponen a continuacin. Ambos productos descritos proveen una aplicacin MIDP de bases de datos compatible JDBC. PointBase PointBase Micro es una implementacin de un subconjunto de la API JDBC que se encuentra en J2SE, preparado pata para trabajar en un entorno MIDP. El lenguaje utilizado es SQL estndar. El archivo JAR ocupa menos de 45 KB. La base de datos puede residir integramente en el dispositivo, o sincronizarse con el producto PointBase UniSync. Para ms informacin sobre PointBase Micro: http://www.pointbase.com/ ReqwirelessDB ReqwirelessDB proporciona el acceso a cualquier base de datos JDBC estndar desde una aplicacin MIDP. Se proporciona la API JDBC para uso de la aplicaciones MIDP, y un servlet para el servidor donde reside la DB a la que se desea acceder. Para ms informacin sobre Reqwireless: http://www.reqwireless.com/
Pg: 115
Java Mvil J2ME
Comunicaciones (I)
La principal ventaja de los dispositivos mviles es su posibilidad de conectividad, todo y que esta era en un inicio escasa, se estn realizando grandes progresos a medida que los dispositivos tienen un grado de integracin mayor y los estndares de conectividad van evolucionando. CLDC define un conjunto de APIs de conectividad llamado Generic Connection Framework (GCF). Este conjunto de APIs es suficiente para establecer redes de bajo nivel entre dispositivos mviles y con sistemas de mayor potencia. MIDP utiliza GCF para establecer un conjunto de clases que soportan streams y esto se amplia hasta soportar conexiones HTTP 1.1 en el caso de MIDP 1.0 y HTTPS en el caso de MIDP 2.0. Sin poder compararse con el framework ofrecido por J2SE en java.net, principalmente debido a los problemas inherentes de las restricciones de memoria, y las necesidades del dispositivo. Los diseadores de CLDC generalizaron las caractersticas de establecimiento de una red de J2SE, proporcionando un marco uniforme para soportar los nuevos dispositivos y los nuevos protocolos que estos pueden requerir.
Pg: 116
Java Mvil J2ME
Comunicaciones (II)
Connection Connector DatagramConnection InputConnection OutputConnection StreamConnectionNotifier
StreamConnection
ContentConnection
CommConnection
SocketConnection
HttpConnection
SecureConnection javax.microedition.io.*
HttpsConnection
javax.microedition.io.* (Interface) MIDP 1.0 javax.microedition.io.* (Interface) MIDP 2.0
Pg: 117
Java Mvil J2ME
Comunicaciones (III)
Para el establecimiento bsico de una red, J2SE incluye clases tales como socket, HttpURLConnection, DatagramSocket, MulticastSocket, ServerSocket, InetAddress, URL, y URLConnection en el paquete java.net. Generalmente, cada protocolo es manejado por una clase diferente. Por ejemplo, los datagramas son implementados por la clase DatagramSocket, y las conexiones HTTP son manejadas por la clase HttpURLConnection. Sin embargo, en el CLDC de J2ME, las clases para el establecimiento de una red son absolutamente diferentes. Ninguna de las clases bsicas referentes a conectividad en J2SE existe en el CLDC de J2ME. De hecho, el paquete de java.net no existe. Las clases del GCF estn situadas en un paquete especifico del CLDC, llamado javax.microedition.io. En el GCF, la clase Connector maneja todos los protocolos de establecimiento de una red soportados en el dispositivo. El resultado es que el cdigo de una aplicacin es bsicamente el mismo independientemente del protocolo que utilice. Se debe tener en cuenta que los protocolos soportados no estn especificados en el nivel de configuracin. La especificacin de los protocolos pertenece a los perfiles. Esto es consistente con la premisa de que los perfiles especifican las caractersticas que aprovechan de las capacidades del dispositivo. La clase Connector tiene varios mtodos estticos, que se utilizan para crear conexiones. Estos mtodos se resumen a continuacin:
Pg: 118
Java Mvil J2ME
La forma genrica de abrir una conexin es utilizar el mtodo esttico de Connection tal como sigue
Connector.open("<protocolo>:[<destino>][;<parmetros>]");
Comunicaciones (IV)
Pero tambin se pueden utilizar las siguientes variantes:

Crea y abre una conexin, usando una URL. Crea y abre una conexin, usando una URL y un modo (leer, escribir, o leer/escribir). Crea y abre una conexin, usando una URL, un modo, y un flag para lanzar excepciones por timeout. Crea y abre un input stream de datos para la conexin. Crea y abre un output stream de datos para la conexin. Crea y abre un input stream para la conexin. Crea y abre un output stream para la conexin.
Pg: 119
static Connection open(String name) static Connection open(String name, int mode) static Connection open(String name, int mode, boolean timeouts) static DataInputStream openDataInputStream(String name) static DataOutputStream openDataOutputStream(String name) static InputStream openInputStream(String name) static OutputStream openOutputStream(String name)
Java Mvil J2ME
Comunicaciones (V)
El formato de los argumento del mtodo open debe ser conforme con la sintaxis estndar para URIs
El estndar para URIs se define en RFC2396, que se puede encontrar en http://www.ieft.org/rfc/rfc2396.txt
El argumento < protocolo > corresponde al protocolo (http/file/...) que se utilizar para la conexin. El argumento opcional < destino > se interpreta en funcin del protocolo. Para conexiones orientadas a red, este parmetro se refiere a una direccin, en formato nombre o IP. Para otros protocolos este argumento se interpreta en funcin del protocolo, si en un futuro se soportan archivos, este argumento contendra el path y el nombre del archivo. Los argumentos opcionales < parmetros > contienen duplas nombre-valor separadas por punto y coma. Por ejemplo, ";nombre1=valor1;nombre2=valor2". Aunque len la especificacin de MIDP se define nicamente el soporte HTTP, HTTP y HTTPS se soportan en la especificacin MIDP 2.0 de J2ME, as como otros modos (socket, serversocket, comm, datagram) pero esto es de forma experimental. Para dispositivos Palm con la JVM de SUN nicamente se dispone del obligado HTTP, esto tiene la ventaja que cualquier cdigo desarrollado para Palm ser totalmente portable, dado que todos los dispositivos que implementen MIDP disponen de este protocolo.
Pg: 120
Java Mvil J2ME
HttpConnection (I)
Para entender el funcionamiento de las APIs de red de MIDP, podemos observar el siguiente ejemplo simple que descarga una pgina desde una conexin HTTP.
private String getPage(String url) throws IOException { HttpConnection c = null; String result = null; try { c = (HttpConnection)Connector.open(url); DataInputStream dis = c.openDataInputStream(); byte[] buffer = new byte[(int)c.getLength()]; dis.readFully(buffer); result = new String(buffer); } catch (Exception e) { Alert alert = new Alert("Error"); alert.setString(e.toString()); alert.setTimeout(Alert.FOREVER); display.setCurrent(alert, mainForm); System.out.println(e.getMessage()); } finally { if(c != null) c.close(); } return result; }
Pg: 121
Java Mvil J2ME
HttpConnection (II)
En este ejemplo, utilizamos Connector para abrir una HttpConnection, que se utiliza a continuacin para abrir un stream de entrada de datos. Para descargar los primeros bytes de la pgina del URL especificado, se utiliza el mtodo readFully() para leer todo el array de bytes. Notar que se utiliza el mtodo getLength para crear el array de bytes del tamao necesario. Lo que ocurre en las interioridades de este cdigo es: En primer lugar la conexin HTTP no se realiza cuando se ejecuta el mtodo open de Connector. En este punto se considera que se esta en estado de establecimiento de conexin, la conexin HTTP todava no se ha realizado con el servidor. Se realiza la conexin y los datos se envan y se reciben cuando uno de los mtodos siguientes se llama, causando en HttpConnection una transicin del estado "establecimiento" al estado "conectado": getResponseMessage openInputStream getHeaderFieldInt openOutputStream getHeaderFieldDate openDataInputStream openDataOutputStream getExpiration getDate getLength getLastModified getType getHeaderField getEncoding getHeaderFieldKey getHeaderField getResponseCode
Pg: 122
Java Mvil J2ME
HttpConnection (III)
Para probar este ejemplo, en el mtodo commandAction de HttpNetworking.java podemos utilizar el cdigo siguiente para establecer la conexin:
public void commandAction(Command c, Displayable d) { try { if (c == getCommand) { resultItem.setLabel("Requesting page..."); resultItem.setText("");
String result = getPage( "http://localhost/fichero.html");

resultItem.setLabel("Received..."); resultItem.setText(result); } else if (c == exitCommand) { destroyApp(false); notifyDestroyed(); } } catch (Exception e) { e.printStackTrace(); resultItem.setLabel("Error:"); resultItem.setText(e.toString()); } }
Pg: 123
Java Mvil J2ME
HttpConnection (IV)
Se puede utilizar NetCat (nc -l -p 80) en el servidor destino para capturar la peticin y enviar una respuesta compatible HTTP, p.ex: Peticin:
" GET /fichero.html HTTP/1.1 Host: localhost:80 Content-Length: 0 "
Respuesta:
" HTTP/1.1 200 OK Content-Length: 54 Content-Type: text/html Java en dispositivos mviles Ao 2004 F2i Sabadell "
Pg: 124
Java Mvil J2ME
Acceso a Internet desde un dispositivo Palm

Vamos a realizar un inciso en el curso sobre Java, para ver las posibilidades de conexin de los dispositivos mviles, y concretamente de Palm para obtener un acceso a Internet. Opciones: Cradle con conexin serie o Bluetooth Conexin por Inflarojos o USB Disponibilidad de conexiones WireLess Para la primera opcin la conexin entre el dispositivo el PC y Internet pasa por establecer un tnel PPP, esto debe realizar mediante software, en el caso de bluetooth utilizando el dispositivo serie virtual, todo y que es posible establecer tambin una pasarela mediante una red bluetooth y "ICS" las posibilidades son: Instalar el software http://www.mochasoft.dk/home.html Establecer un servicio RAS en Windows 2000, XP, NT que permita al dispositivo acceder a un servicio de pasarela: http://bwinton.latte.ca/Palm/ppp.html Para establecer una red bluetooth y compartir la conexin a Internet mediante ICS: http://www.whizoo.com/bt_setup/ Para establecer una conexin por Infrarrojos o USB se debe realizar lo mismo que en los puntos anteriores, es decir, es necesario un servicio PPP, que puede ser RAS o el software de mochasoft pero con un driver de virtualizacin a puerto serie del puerto de infrarrojos (http://www.ircomm2k.de/) o del USB
Pg: 125
Java Mvil J2ME
Acceso a Internet desde un dispositivo

El tercer caso es mucho mas simple, dado que los dispositivos Palm dotados de una interfase wireless incorporan un stack Tcp/Ip y esto facilita enormemente la conectividad, simplemente debemos configurar nuestro dispositivo de acuerdo con la topologa de nuestra red. Para dispositivos mviles es mucho ms sencillo, y por supuesto mas caro, consiste en establecer una conexin a travs del ISP correspondiente, abonando para ello las cuotas de conexin. Los dispositivos Palm tambin ofrecen la posibilidad de establecer una conexin por infrarrojos, bluetooth, o un cable especifico a un telfono mvil para crear una conexin PPP con el correspondiente ISP.
Pg: 126

Java S9

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Java S9

Cargado por

Copyright:

Formatos disponibles

S9

Java per a dispositius mbils.

Estius Universitaris 06/07

Java Mvil J2ME

Java en dispositivos mviles

Estius Universitaris 06/07

Java Mvil J2ME

Java 2, Micro Edition. (1'5h)

Estius Universitaris 06/07

Java Mvil J2ME

Entornos de desarrollo (2h)

Estius Universitaris 06/07

Java Mvil J2ME

Estructura bsica de un Midlet (3h)

Estius Universitaris 06/07

Java Mvil J2ME

Almacenamiento de Informacin (3h)

Estius Universitaris 06/07

Java Mvil J2ME

Java 2 Micro Edition (J2ME)

Estius Universitaris 06/07

Java Mvil J2ME

Java 2, Micro Edition

Estius Universitaris 06/07

Java Mvil J2ME

Estius Universitaris 06/07

Java Mvil J2ME

J2ME, CDC & CLDC

A continuacin se presenta un esquema de los perfiles definidos para la CDC y CLDC.

Estius Universitaris 06/07

Java Mvil J2ME

CLDC vs CDC (I)

Estius Universitaris 06/07

Java Mvil J2ME

CLDC vs CDC (II)

Restricciones referentes a JVMS (Java Virtual Machine Specification)

Estius Universitaris 06/07

Java Mvil J2ME

CLDC vs CDC (III)

Connected Device Configuration (CDC)

Estius Universitaris 06/07

Java Mvil J2ME

CLDC vs CDC (IV)

Estius Universitaris 06/07

Java Mvil J2ME

Estius Universitaris 06/07

Java Mvil J2ME

CLCD: MIDP (I)

MIDP no cubre las reas siguientes:

Estius Universitaris 06/07

Java Mvil J2ME

CLDC: MIDP (II)

Se puede obtener una copia de la especificacin de MIDP 2.0, en http://www.jcp.org/jsr/detail/118.jsp .

Estius Universitaris 06/07

Java Mvil J2ME

CLDC: Paquetes Opcionales

Paquete Opcional FileConnection

Estius Universitaris 06/07

Java Mvil J2ME

CDC Profiles (I)

Estius Universitaris 06/07

Java Mvil J2ME

CDC Profiles (II)