Introducción. Arquitectura de la plataforma J2ME. Configuraciones. CDC. CLDC. Diferencias entre J2SE y CLDC. Perfiles. MIDP. Requisitos de hardware. Requisitos de software Paquetes opcionales. Máquinas virtuales. Características.

1. Introducción a la plataforma J2ME Jorge Iván Meza Martínez < [email_address] > http://www.jorgeivanmeza.com/ http://educacion.misservicios.net/

3. Introducción J2ME es un subconjunto de la plataforma Java preparado para desarrollar aplicaciones para dispositivos móviles con escasos recursos (memoria, pantalla, dispositivos de entrada, etc) como lo son teléfonos celulares, PDAs, beepers, etc. Imágen tomada de developers.sun.com .

4. Introducción Basa su arquitectura en una máquina virtual (JVM) cuya implementación es dependiente del proveedor del dispositivo, sin embargo esta debe cumplir con el estándar básico. Con esto Java intenta extender su premisa “ write it once, run it everywhere ” a los dispositivos móviles. Sin embargo debido a las posibles variaciones entre los distintos proveedores esta permisa no siempre se cumple con precisión. En comparación con J2SE, el desarrollo de aplicaciones móviles se encuentra seriamente restringido debido a las limitaciones de recursos de los dispositivos objetivo.

5. Introducción Con respecto a los dispositivos específicos donde se ejecutarán las aplicaciones, el API de J2ME se encuentra dividido en configuraciones (familias horizontales de dispositivos): CDC y CLDC. Sobre estas se apoyan los perfiles (familias verticales de dispositivos): MIDP, los cuales amplían el alcance de su implementación. Mas adelante se profundizará el conocimiento de estos términos. La plataforma J2ME se construye a partir de la unión de múltiples especificaciones cuya gran mayoría pasan a través del Java Community Process (JCP), programa que recibe las solicitudes como Java Specification Requests (JSR) y las analiza para posteriormente descartarlas o implementarlas según sean sus conclusiones.

6. Arquitectura La arquitectura de J2ME busca ser lo mas modular y escalable posible para conservar su funcionalidad y portabilidad entre la muy heterogénea gama de dispositivos objetivo. Para esto se divide en capas según el tipo de dispositivo (características y funcionalidades) sobre el cual se va a implementar la plataforma.

7. Arquitectura El sistema operativo es desarrollado por el proveedor del dispositivo. Sobre él se implementa la máquina virtual de Java, la cual es también desarrollada por el proveedor del dispositivo adaptándose a las particularidades de este y cumpliendo con los requisitos mínimos especificados por Sun Microsystems . El proveedor del dispositivo es libre de agregar funcionalidades (API) propietarias mas allá del estándar para explotar al máximo los recursos específicos del dispositivo, sin embargo si se utiliza este API particular las aplicaciones desarrolladas ya no serán portables entre otros dispositivos de diferentes proveedores.

8. Arquitectura La configuración se relaciona con el tipo de dispositivo y hace referencia al conjunto mínimo de características de la máquina virtual y de las librerías de clases que van a estar disponibles para un conjunto de dispositivos según sus características. Las configuraciones mas conocidas son la CLDC ( connected limited device configuration ) y la CDC ( connected device configuration ).

9. Arquitectura

10. Arquitectura El perfil se relaciona con el nivel de aplicación y define el conjunto mínimo de APIs disponibles para una determinada familia de dispositivos, de manera mas específica y especializada que la proporcionada por la configuración . Los perfiles se implementan para una configuración especifica. Las aplicaciones se desarrollan para un perfil determinado. Un dispositivo pertenece a una única configuración pero puede soportar múltiples perfiles .

11. Arquitectura El primer perfil que se desarrollo y por ende el mas utilizado es MIDP ( mobile information device profile ) para CLDC. Este perfil posibilita el desarrollo de aplicaciones móviles con intefaz gráfica de usuario, acceso a la red, sonido, seguridad, almacenamiento de datos, etc. Este es el perfil utilizado para desarrollar aplicaciones móviles destinadas a teléfonos móviles y beepers con pantallas reducidas, conexión HTTP inalámbrica y memoria limitada.

12. Arquitectura

14. Configuraciones - CDC Configuración para dispositivos conectados , definida por la especificación JSR-36 . Orientada a dispositivos con procesadores de 32 bits y 2MB o mas de memoria total disponible (para RAM, ROM, JVM y librerías). Cuentan con conexión a la red (generalmente inalámbrica) y con un ancho de banda limitado. Ejemplos de estos dispositivos son equipos portátiles corriendo Windows Mobile, equipos de televisión interactiva, terminales de puntos de venta (POS), sistemas de navegación, consolas de videojuegos, reproductores de audio digital, etc. A esta configuración se le asocia el perfil Foundation Profile .

15. Configuraciones - CLDC Configuración para dispositivos con conexión limitada , definida por la especificación JSR-30 y mejorada por la JSR-139 . Orientada a dispositivos con procesadores de 16 o 32 bits entre 8 a 32 Mhz y con una cantidad total disponible de memoria de al menos 160 a 512KB hasta 2MB incluyendo el perfil y paquetes adicionales. Cuentan con una conexión de red con acceso intermitente y bajo ancho de banda. Su máquina virtual se conoce como Kilo Virtual Machine (KVM).

16. Configuraciones - CLDC Es la configuración mas restrictiva en término de recursos: potencia de cálculo, memoria, alimentación, despliegue de información, interfaces de entrada, etc. A esta configuración se le asocia el perfil MIDP . Los teléfonos móviles son un buen ejemplo de esta configuración.

17. Diferencias entre J2SE y CLDC No hay soporte para tipos y operaciones de punto flotante. La revisión [1.1] empieza a incluír este soporte. Sólo se definen las excepciones Error , OutOfMemoryError y VirtualMachineError . En [1.1] se incluye NoClassDefFoundError . Cualquier otra condición de error será tratada de acuerdo a la implementación de la JVM. No hay soporte para Java Native Interface (JNI), reflexión , serialización ni ninguna interfaz de bajo nivel que dependa de ellos. En [1.1] se incluye soporte para K Native Interface (KNI).

18. Diferencias entre J2SE y CLDC No hay finalización de objetos (llamado al método finalize() ). No se permiten cargadores de clases específicos, es decir, no se puede influír en la manera como se cargan las clases. El proceso de verificación se realiza en dos etapas. La preverificación se realiza en el momento del desarrollo. Para el soporte de internacionalización, CLDC debe proporcionar el soporte a la conversión entre flujos ( streams ) y Unicode .

19. Diferencias entre J2SE y CLDC Las clases de J2SE que son incluidas por J2ME deberán ser un subconjunto de las mismas, es decir, no pueden incluír miembros o métodos públicos adicionales. Todas las clases particulares a la configuración CLDC deberán residir bajo el paquete javax.microedition .

20. Perfiles Un perfil es un conjunto de clases que aumentan la funcionalidad de una configuración (para un grupo de dispositivos con unas características definidas) . El perfil mas utilizado es Mobile Information Device Profile (MIDP) para CLDC, el cual fue definido por JSR-37 y mejorado por JSR-118 . Este perfil permite desarrollar aplicaciones con interfaz de usuario, almacenamiento de datos, comunicación por red encriptada, desarrollo de juegos, manipulación de audio y video, etc . a dispositivos como teléfonos móviles y beepers.

21. Perfiles El perfil MIDP será el utilizado para el desarrollo de las aplicaciones móviles ( midlet ) durante este curso. Existen otros perfiles disponibles para el desarrollo de aplicaciones destinadas a otros dispositivos cmo son el PDA Profile (PDAP) basado en MIDP para el desarrollo de aplicaciones para PDAs, el Foundation Profile (FP) que incluye clases de J2SE adicionales, el Personal Basis Profile (PBP) que incluye soporte para AWT y el Personal Profile (PP) que incluye soporte para applets e interfaz gráfica de usuario ampliada. Estos últimos basados en la configuración CDC.

22. Perfiles - MIDP Como se mencionó anteriormente, el perfil MIDP amplía la funcionalidad (API) de la plataforma Java mas allá de lo provisto por la configuración CLDC para una familia de dispositivos con recursos limitados. Por razones de seguridad y portabilidad, MIDP no permite el acceso directo al sistema operativo. Sun Microsystems proporciona la implementación de referencia de este perfil , la cual sirve como base de implementación para los proveedores de los dispositivos quienes deben desarrollar un código nativo adicional para integrar la plataforma con su sistema operativo específico. Este código de integración no es portable.

23. MIDP - Requisitos de hardware Estos son los requisitos mínimos de hardware asociados a los dispositivos con soporte para el perfil MIDP. Al menos 128KB de memoria para almacenar la implementación de MIDP además de lo requerido por la implementación de CLDC. Se requieren también 32KB de espacio para la pila de objetos y 8KB de memoria no volátil para guardar información persistente ante la falta de suministro eléctrico. Los teléfonos actuales proveen comunmente al menos 2MB de memoria a la plataforma. Pantallas de mínimo 96x54 píxeles y soportar al menos dos colores.

24. MIDP - Requisitos de hardware Teclado numérico, teclas de dirección y botón de selección. Los teléfonos móviles cuentan adicionalmente con representación de las teclas alfanuméricas y botones de opciones. Algún tipo de conexión a la red (probablemente inalámbrica, ejemplo WIFI y GPRS ), ya sea de manera incorporada o a través de un módem externo. Con respecto a la red no se asume conexión permanente ni soporte directo para TCP/IP por parte del perfil , sin embargo debido al extenso uso que se le da al protocolo HTTP es necesario que el proveedor del dispositivo implemente el soporte para la versión 1.1.

25. MIDP – Requisitos de software Estos son los requisitos mínimos de software asociados a los dispositivos con soporte para el perfil MIDP. Soporte para comunicación por red, ya sea directamente el protocolo HTTP, un API de bajo nivel que permita implementarlo ( sockets ) o indirectamente como una pasarela . Acceso a los dispositivos de entrada (teclado, stylus , etc), generación de eventos durante su manipulación y conversión de códigos a un conjunto estándar.

26. MIDP – Requisitos de software Acceso a la pantalla del dispositivo como un mapa de bits . Almacenamiento permanente que persista cuando se apague el dispositivo y una interfaz del sistema operativo para su manipulación.

27. Paquetes opcionales Los paquetes opcionales son librerías de clases (API) que proveen características adicionales y específicas pero que debido a sus características no pertenecen a ninguna configuración o perfil, ni definen por si mismos un entorno completo de aplicación, sin embargo pueden ser utilizadas y compartidas por diferentes perfiles. Su soporte por parte del dispositivo será opcional, es decir, si el dispositivo cuenta con los recursos de hardware y software necesarios para implementar los paquetes, por este motivo no pueden ser incluídos en un perfil general. Ejemplos de estos paquetes opcionales son los relacionados con Bluetooth , Wireless Messaging API (WMA), RMI Optional Package y JDBC Optional Package entre otros.

28. Máquinas virtuales Kilo Virtual Machine (KVM) para CLDC y Compact Virtual Machine (CVM) para CDC. Desarrolladas por Sun Microsystems. Los proveedores de dispositivos pueden licenciar estas máquinas virtuales o realizar su propia implementación que cumpla con los requerimientos de la especificación. Su implementación se inició con el proyecto Spotless cuyo objetivo era la implementación de una máquina virtual completa para los dispositivos PalmPilot con PalmOS .

29. Características de las VM Tamaño de la memoria virtual y librerías de clases entre 50 y 80KB de código objeto. Reducida utilización de memoria (KB). Rendimiento efectivo en entornos de 16 y 32 bits. Arquitectura portable minimizando las secciones de código dependientes del dispositivo.

30. Características de las VM Recolección de basura ( garbage collection ) y multihilo ( multithreading ) independientes del sistema operativo. Diseño modular para la configuración de dispositivos específicos. Implementación de tipos de datos de punto flotante y enteros largos son opcionales. No es necesaria la implementación de la finalización de objetos.

31. Características de las VM No se incluye el soporte para Java Native Interface (JNI). La verificación de las clases se realiza en el momento del desarrollo (preverificación). El soporte para arreglos multidimensionales es opcional. No es posible manipular directamente por parte de la aplicación la carga de clases.

32. Fin de la presentación. Creative Commons (CC)