Java per a dispositius mòbils. Sabadell, del 5 al 6 de juliol de 2007

S9 Java per a dispositius mòbils. Sabadell, del 5 al 6 de juliol de 2007 Vicenç Soler i Juan Manuel Fernández, professors de l Escola Universitària d Informàtica de Sabadell.

Java en dispositivos móviles Vicenç Soler Juan Manuel Fernández 1 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 móviles. Introducción a la arquitectura J2ME, Presentación de la arquitectura básica de Java i como esta se adapta en función del dispositivo sobre el que se coloca, se presentan los estándares que hay detrás de esta arquitectura y se catalogan para uso futuro del alumno. Dispositivos. (1'5h) PDA, PocketPCs, Mobile Devices, PIM Objetivos: Catalogar los dispositivos móviles, se pretende que el alumno sea crítico a la hora de desarrollar una aplicación en J2ME para que esta cubra la mayor parte de dispositivos. Pàg: 2

Programa (II) Entornos de desarrollo (2h) Diferentes entornos IDE. Instalación del Software para desarrollo. Instalación y configuración del Emulador de PALM Objetivos: Evaluar diferentes entornos de desarrollo, se referencia un conjunto amplio de ellos, y se aporta una visión 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 móviles (1h) CPU Pantalla Memoria Objetivos: Analizar las características del entorno donde se ejecuta la aplicación con el objetivo de evidenciar las sustanciales diferencias de desarrollo que se deben considerar para los dispositivos móviles. Concienciar al alumno de las concesiones necesarias en las aplicaciones J2ME. Pàg: 3 Programa (III) Estructura básica de un Midlet (3h) Gestor de aplicaciones Ciclo de vida Estructura de un Midlet Objetivos: Mostar la estructura básica de las aplicaciones para dispositivos móviles, crear una aplicación básica y analizarla, ver los problemas de desarrollo, compilación 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. Pàg: 4

Programa (IV) Almacenamiento de Información (3h) En MIDP Implementación en Palm OS Otros contenedores de información En PersonalJava Objetivos: Presentar las diferentes APIs para la gestión de la información en los dispositivos móviles en general y en algunos en particular, y como estas deben ser tratadas desde las aplicaciones para un correcto ciclo de vida. Se aborda también el almacenamiento externo de esta información. Comunicaciones (3h) Framework de comunicaciones en CLCD Comunicaciones en PocketPC Objetivos: Introducción a la intercomunicación de dispositivos móviles, las restricciones que por sus características se encuentran es este tipo de dispositivos. WebServices Futuro Objetivos: Integración de las aplicaciones y los dispositivos en la empresa, y los mecanismos que se encuentran disponibles para poder realizarla. Objetivos: Análisis del futuro de las aplicaciones Java en los dispositivos móviles, mesa redonda con los alumnos para ver su opinión con respecto a este tipo de dispositivos, y análisis de tendencias del mercado. Pàg: 5 Ámbito de Java Java 2 Micro Edition (J2ME) Pàg: 6

Java 2, Micro Edition Configuraciones: J2ME se define en términos de configuraciones y de perfiles. Una configuración es un core para la funcionalidad básica, mientras que un perfil se define sobre una configuración existente. Así, un perfil proporciona una funcionalidad extendida que explota las capacidades del dispositivo sobre el que se van a ejecutar las aplicaciones. También podemos encontrar los paquetes opcionales, los cuales se definen sobre los perfiles y configuraciones. Pàg: 7 Configuraciones de J2ME Una configuración es una combinación de una máquina virtual Java y de una colección de los interfaces de programación de aplicaciones (APIs) para una determinada clase del dispositivo. Una configuración proporciona la base para uno o más perfiles en un dispositivo. Un perfil es un sistema de APIs que dota de más funcionalidad y se adapta específicamente a las especificaciones de un determinado dispositivo. Una configuración define un sistema básico de APIs que se debe estar implementado en todos los dispositivos que soporten la configuración (dispositivos de baja potencia, con poca cantidad de memoria, etc.). El perfil que se sustenta sobre la configuración, debe implementar los APIs de la configuración, y los específicos del perfil (profile), como pueden ser los específicos de un PDA, un teléfono móvil, etc. Es importante observar que la configuración especifica las capacidades de la máquina virtual asociada, pero no impone una maquina virtual particular. Los vendedores de perfiles y configuraciones tienen libertad de proporcionar su propia máquina virtual, siempre que se adapte a la especificación (Ex. J9VM IBM, KVM SUN). Pàg: 8

J2ME, CDC & CLDC Hay dos configuraciones definidas actualmente en J2ME: la configuración de dispositivo con conexión limitada (CLDC) y la configuración de dispositivo con conexión (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 continuación se presenta un esquema de los perfiles definidos para la CDC y CLDC. El personal profile se sitúa sobre el personal basis y el foundation profile los cuales extiende la configuración CDC. El perfil Mobile Information Device (MID) extiende la configuración CLDC, junto con paquetes opcionales como pueden ser el Personal Information Management (PIM) y el FileConnection. Pàg: 9 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 características básicas. Un dispositivo de CLDC: es accionado por las baterías, 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 asignación dinámica de objetos. Estas características definen una variedad amplia de dispositivos, incluyendo pagers, teléfonos móviles, y PDAs. El CLDC define una base común para estos dispositivos en las áreas siguientes: Paquetes de Java base Capacidades de lenguaje Capacidades de la JVM Conectividad e I/O Seguridad Internacionalización No cubre otras áreas que puedan ser especificas del dispositivo, por ejemplo el interfaz de usuario, el ciclo de vida de aplicación, gestión de eventos. Estas áreas son cubiertas por los perfiles. La máquina 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 dispondrán de las siguientes características: Pàg: 10

CLDC vs CDC (II) Connected Limited Device Configuration (CLDC) Restricciones referentes a JLS (Java Language Specification) Sin soporte de coma flotante (ninguna operación de coma flotante, literales de coma flotante, tipos, o valores). Sin soporte a la finalización. Soporte básico de excepciones, el número de las clases de error es limitado. Restricciones referentes a JVMS (Java Virtual Machine Specification) Ningún soporte a coma flotante.. Ningún 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 finalización. Sin Weak References. Método diferente de verificación de classfile Formato de classfile y cargador (loader) diferente. El CLDC hereda la mayoría 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. Pàg: 11 CLDC vs CDC (III) Connected Limited Device Configuration (CLDC) La versión 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 métodos 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 básico para referencias Weak de J2SE's. Se agrega el paquete java.lang.ref. Las clases Calendar, Date y TimeZone en java.util son más consistentes con las versiones de J2SE. Se ha agregado la clase Error en java.lang.noclassdeffounderror. Algunos métodos añadidos a clases existentes, por ejemplo el método intern() a la clase java.lang.string, y el método tostring() a la clase java.util.date. La especificación completa de CLDC 1,1 está disponible de http://www.jcp.org/jsr/detail/139.jsp. Connected Device Configuration (CDC) La CDC es un súper conjunto de CLDC. La CDC incluye todas las APIs definidas por el CLDC, incluyendo los paquetes java.* y javax.microedition.*. La CDC se diseña para los dispositivos de más memoria (2 MB o más, disponible para la plataforma de Java) y una conexión 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) deberían ser portables a CDC (las capacidades de AWT se definen en los perfiles del CDC). Pàg: 12

CLDC vs CDC (IV) Connected Device Configuration (CDC) Una implementación de CDC debe soportar totalmente JLS y JVMS. Los paquetes de la CDC se diseñan 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 encriptación para la serialización de objetos. Sin soportar firma segura de código, certificados, almacenamiento de claves, JDK 1.1 Identity, e IdentityScope. java.security.cert java.text, con soporte mínimo 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 implementación de CDC deben soportar la entrada-salida del archivo (I/O) (por lo menos en modo read-only) y datagramas. Pàg: 13 Profiles CLDC Actualmente sólo existe un perfil (profile) para la configuración 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 más limitados en recursos, como pueden teléfonos móviles, y pagers. La ventaja de la elección de este perfil, es que aporta la mínima expresión para todos los dispositivos, de este modo una aplicación que corra sobre este perfil, podrá ejecutarse en todos los dispositivos que lo implementen. Pàg: 14

CLCD: MIDP (I) La especificación de MIDP define los requisitos adicionales para el dispositivo destino, más 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 especificación MIDP 1.0 sobre CLDC 1.0, proporcionan funcionalidad en los apartados siguientes: Gestión de ciclos de vida de la aplicación. Interfaz de usuario Almacenamiento persistente Redes Timers MIDP no cubre las áreas siguientes: APIs A nivel sistema Instalación y almacenaje de la aplicación Seguridad más allá de lo especificado en CLDC. 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 gestión del ciclo de vida de la aplicación. Estos paquetes se denominan javax.microedition.lcdui, javax.microedition.rms, y javax.microedition.midlet, respectivamente. Pàg: 15 CLDC: MIDP (II) Una aplicación 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 aplicación de MIDP debe extender la clase MIDlet e implementar tres de sus métodos definidos como abstractos: startapp, pauseapp, y destroyapp. Estos métodos 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 método pauseapp para permitir liberar los recursos compartidos. Activo. Se llama el método startapp después 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 también hacer que el MIDlet entre en estos estados, usando los métodos notifypaused, notifydestroyed, y resumerequest. MIDP 2.0 se construye sobre MIDP 1.0, es compatible hacia atrás, esto garantiza que las aplicaciones desarrolladas para MIDP 1.0 también funcionen en MIDP 2.0. Definido en JSR118, la especificación final fue lanzada en noviembre de 2002. Asume funcionalidad de CLDC 1.0, aunque también 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 generación de tonos y reproducción de sonido. javax.microedition.pki. Certificados para las conexiones de red seguras. Se puede obtener una copia de la especificación de MIDP 2.0, en http://www.jcp.org/jsr/detail/118.jsp. Pàg: 16

CLDC: Paquetes Opcionales De igual modo que el profile MIDP, para explotar las características 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 añade el paquete javax.microedition.pim a CLDC. El propósito de este paquete es proveer al desarrollador el acceso y gestión de la libreta de direcciones, la lista de tareas y el calendario del PDA. Paquete Opcional FileConnection El paquete opcional de FileConnection agrega a CLDC 1.0 o superior el paquete javax.microedition.io.file. Este paquete añade otro tipo de conexión al framework genérico 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. Pàg: 17 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 implementación del foundation profile debe soportar los protocolos especificados por la CDC, y además debe apoyar los sockets y HTTP. Personal Basis Profile Este profile proporciona la capacidad para una presentación básica de interfaz de usuario, pero no tiene soporte para GUI s 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. Pàg: 18

CDC Profiles (II) Personal Profile El personal profile es el camino para la migración hacia J2ME de las aplicaciones de PersonalJava, y fue desarrollado por el JCP como JSR62. Ester Profile añade al Personal Basis Profile soporte para Web y entorno para la ejecución 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 estándares del JDK 1.1. Xlets. Un Xlet es un interfaz de la gestión del ciclo de vida, similar al MIDlet. Un Xlet define tres métodos. El sistema hace que el Xlet cambie su estado. Los estados definidos son Destroyed, Paused, y Active. Aplicaciones. Aplicaciones estándar de Java, definido como clase con un método public static void main(string[]). El Personal Profile agrega al Foundation Profile estos paquetes: 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 Pàg: 19 CDC Profiles (III) Diferencias entre el perfil personal y JDK 1.3 Los paquetes y las clases del Personal Profile son típicamente subconjuntos de los paquetes y de las clases del JDK 1.3. Hay un conjunto pequeño de APIs en el Personal Profile que tiene restricciones en su uso. Son: java.awt.alphacomposite. Aproximación de la regla de SRC_OVER. java.awt.component. La implementación puede ignorar las llamadas para fijar el cursor visible. java.awt.dialog. La implementación puede limitar el tamaño, puede impedir redimensionar, puede limitar la localización en la pantalla, y puede no soportar un título 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 implementación puede no permitir fijar el carácter de echo. En cada caso, una propiedad del sistema deberá ser puesta a true si la implementación 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 Pàg: 20

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 definición, basada en J2ME. Cuando los diseñadores del perfil personal comenzaron a definirlo, lo hicieron con JDK 1.3, quitado todos los APIs deprecados y que consideraron innecesarios para los dispositivos móviles 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 específicos a PersonalJava. También hereda algún APIs de Java 1.2 para apoyar seguridad en control de acceso y firmas de código. La portabilidad del código sin modificación de JDK 1.1.8 a PersonalJava es por lo tanto posible pero dependerá de la aplicación. La mayoría de las ocasiones en que una aplicación 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 código fuente será bastante portable entre las dos plataformas. javax.microedition.* Pàg: 21 Dispositivos Por que utilizando Java nos hemos de preocupar de la plataforma? Tal i como se ha discutido en la presentación anterior J2ME no es totalmente portable, hemos de considerar aspectos como la JVM donde se ejecutara nuestra aplicación (PersonalJava y MIDP), así como los paquetes opcionales de los que disponga el dispositivo destino. Por norma general se recomienda estructurar la aplicación en el código funcional común que se pueda ejecutar independiente de la plataforma, y separarlo de la presentación de usuario, la persistencia y conectividad, esto puede ser una tarea compleja. Dado que el punto anterior es de difícil cumplimiento, normalmente se escoge la plataforma destino antes de diseñar la aplicación, dado que muchas aplicaciones para dispositivos móviles son orientadas a cliente servidor, esto afectara significativamente a diseño y realización de la aplicación. A continuación vamos a enumerar algunos de los dispositivos móviles más comunes y sus características más significativas. Al seleccionar una plataforma PDA para el desarrollo de Java, hay un gran número de factores a considerar. En la consideración de estos factores, es importante recordar los dos subconjuntos principales de dispositivos, dependiendo del SO: Palm OS y PocketPCs. Estos tienen filosofías totalmente diferentes, a continuación se enumeran algunas de ellas. Es importante considerar siempre que aunque Java funcionará en ambos dispositivos, la riqueza de la plataforma varía, según las capacidades del dispositivo, y, por consiguiente, la configuración. Esto es principalmente debido a las diferencias en filosofía de diseño de las configuraciones de J2ME según el tipo de dispositivo. Pàg: 22

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. Energía de proceso baja y larga duración de la batería. Los dispositivos PALM OS funcionan a con CPUs de 20 MHz o 33 MHz, y típicamente 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 asemejándose a los PocketPC. PocketPCs Herencia del PC. El PocketPCs es básicamente un PC en miniatura. Rica funcionalidad. Un PocketPC es básicamente 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 energía de proceso y una vida más corta de las baterías. Los PocketPCs disponen actualmente de CPUs de 200 MHz a 400 MHz, y sobre 32Mb a 64Mb de RAM. Pàg: 23 PocketPC Casio E-200 HP ipaq 3970 Compaq ipaq 3870 Toshiba e740 Media Comparativa de precios en USD Diciembre 2002 Men or $600 $715 $537 $550 $601 Mayo r $650 $780 $680 $600 $678 Palm OS Handspring Treo 270 Palm m515 Palm i705 Sony CLIE PEG- NR70V Media Men or $500 $300 $298 $510 $402 Mayor $700 $400 $450 $600 $538 En esta selección de dispositivos high-end PocketPC y Palm, podemos observar que los PocketPC son entre un 25% y un 50% más caros que los dispositivos high-end Palm OS. Pàg: 24

Factores a considerar en la decisión de la plataforma (I) Coste PocketPCs es generalmente más costoso que los dispositivos Palm OS. Tal i como se puede observar en la tabla anterior. Estándar Corporativo Si hablamos de desarrollos para usuarios corporativos, o para la propia organización, los estándares corporativos para PDAs afectan claramente a la eleción de la plataforma. Según el grupo tecnológico Winn (en fecha diciembre de 2002), Palm OS ha sido elegido por el 85% de las compañías 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. Riqueza de funcionalidad 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 estándares de PIM (es decir, libros de direcciones, notas, listas de la tarea, y calendarios). El paquete opcional de PIM se diseña para permitir el acceso fácil a las funciones de PIM de un PDA desde Java. PersonalJava no tiene específicamente 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. Riqueza del soporte Java El soporte Java es importante si se es desarrollador Java que desea escribir aplicaciones para PDAs. Aunque PersonalJava es más rico en APIs de Java y más cercano a J2SE que MIDP y los paquetes opcionales de CLDC, PersonalJava carece el APIs para tener acceso a las características especificas de un PDA. Pàg: 25 Factores a considerar en la decisión de la plataforma (II) Soporte Wireless Aunque ambos dispositivos son capaces de operar wireless, tanto con soporte WiFi y Bluetooth, la disponibilidad de estas características 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 máquinas virtuales de Java (VMs) en los PDAs. Market Share - Actual y tendencia En los años 90, el Palm OS era el sistema operativo dominante para PDA en el mercado. Desde entonces, Microsoft ha desafiado esa hegemonía 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. Donde estará el vendedor / fabricante del dispositivo en dos años? La mayoría de los fabricantes de PDAs tendrán a corto plazo nuevos modelos basados en la CPU de Intel XScale. Esto provocara una clara disminución de las diferencias Hardware entre dispositivos Palm OS y PocketPC, como ejemplo destacar que Palm OS v5 es funcionalmente idéntico a las versiones anteriores, pero sin las limitaciones que tenían sus predecesores. Pàg: 26

Comparativa PDAs Clasificación Java vs PDA PersonalJava está disponible en los dispositivos de PocketPC, mientras que MIDP está disponible en los dispositivos Palm OS. A continuación se enumeran las implementaciones J2ME actualmente disponibles. PersonalJava se incluye en la tabla aunque no es estrictamente una implementación J2ME, por el contrario está disponible para casi cada dispositivo PocketPC. Comparación de dispositivos Palm OS Los dispositivos Palm estan evolucionando rápidamente, tanto a nivel Hardware como SO. También existen nuevos fabricantes que crean dispositivos que ejecutan Palm OS, a continuación se muestra una tabla con una selección de los dispositivos producidos por Palm Inc. y con licencias de Palm OS. Pàg: 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 CPU 68 K Clasificación Java vs PDA StrongARM Intel XScale StrongARM StrongARM StrongARM StrongARM Intel XScale StrongARM StrongARM 68K 68K 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. 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 Pàg: 28

Comparación 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 Dynamic Heap [a] 128 KB 128 KB 128 KB 256 KB 128 KB 256 KB 96 KB 128 KB 256 KB 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 CPU Type Dragonball EZ Dragonball EZ Dragonball/Dragonball EZ Dragonball EZ Dragonball EZ Dragonball VZ Dragonball EZ Dragonball EZ Dragonball EZ Dragonball EZ Dragonball Dragonball EZ Fuente: http://www.palmos.com/dev/tech/hardware/compare.html. [a]: Dependiendo de la versión de Palm OS instalada [b]: Esta versión es la de referencia, en algunos dispositivos puede haberse upgradeado. CPU Speed 16 MHz 16 MHz 16 MHz 20 MHz 16 MHz 33 MHz 16 MHz 16 MHz 20 MHz 16 MHz 16 MHz 16 MHz Pàg: 29 Preparando el entorno de desarrollo A continuación se enumerara el software necesario para el desarrollo de las aplicaciones de ejemplo de este curso. Las herramientas utilizadas están disponibles de forma libre o con mínimo coste, se han evitado los IDEs comerciales por las siguientes razones: Aprender a programar en una nueva plataforma es más eficiente contra más elemental es el entorno de desarrollo, la utilización de un IDE a menudo oculta aspectos fundamentales de la programación y el deployment de la aplicación. Siempre se esta a tiempo de utilizar un IDE, cuando se entiendan los mecanismos de construcción de aplicaciones en la plataforma. Se dispone de mayor libertad de programación, 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. Pàg: 30

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 debería poder destacar la sintaxis Java y XML de modo que el código fuente sea fácil de leer. Java SDK ( http://java.sun.com/j2se/downloads.html ). Utilizaremos 1.1.8 (para compilar código 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 propósitos de desarrollo personal, se debe observar que MIDP para Palm no es libre para distribuir comercialmente. Pàg: 31 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 aplicación en el PDA es recomendable realizar un test en el entorno POSE. Esto implica un bucle de programación - prueba - corrección mucho más rápido. POSE está disponible para Windows, MacOS, y Unix. También 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 sesión del emulador tal y como se observa en el siguiente grafico. Pàg: 32

Configurando el emulador de Palm OS (II) En este momento ya dispondremos de un entorno de emulación totalmente funcional. Pàg: 33 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 emulación para diversos dispositivos. También 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 máquina 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 más información sobre KVM. Se debe instalar J2ME Wireless Toolkit en el directorio por defecto. Pàg: 34

MIDP para Palm OS Si se escoge un entorno genérico de desarrollo MIDP para Palm será necesaria una utilidad para convertir la aplicación MIDP (JAR/JAD) en un PRC (ejecutable para Palm), esto es realizado por la suite MIDP de Sun. Destacar que J2MEWTK también 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 parámetros 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 estándar JAD/JAR en un PRC para descargar en el dispositivo. Una implementación 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 también incluye la capacidad de capturar los streams System.out y System.err. Para instalar el entorno MIDP para Palm tan sólo es necesario sincronizar el archivo MIDP.prc en el dispositivo. Pàg: 35 Ejecutar aplicaciones java en Palm (I) Como norma general para la creación de cualquier aplicación para Palm deberemos seguir los siguientes pasos: Compilación de la aplicación: El compilador utilizado será versión 1.1, se ha de tener en cuenta que tanto MIDP como CLDC están basado en el bytecode de Java 1.1. Los parámetros para una compilación básica: <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 código fuente compilado, pero para poder ejecutar este código en una KVM se debe realizar un proceso de preverificación, este proceso se realiza de la siguiente forma: Cuando se trabaja con J2SE la máquina virtual Java (JVM) lleva a cabo un proceso de verificación en tiempo de ejecución. Esto ocupa ciertos recursos que en dispositivos inalámbricos son relativamente escasos. Debido a las restricciones de estos dispositivos se ha creado en J2ME un proceso denominado preverification consistente en llevar a cabo parte de la verificación de la KVM off-line, el resto será llevado a cabo como una verificación normal. <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 Pàg: 36

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 aplicación midlet. Concretamente: El nombre de la aplicación, el icono a utilizar, y el nombre de la clase de la aplicación. Vendedor e información de la versión. Versión 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: Pàg: 37 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 tamaño del archivo jar. Pàg: 38