Un vistazo más profundo a la arquitectura J2ME:  MIDP Versión: 2.0, Septiembre, 2006 Juan Manuel Fernández Luna Web: http://decsai.ugr.es/~jmfluna, Mail: jmfluna@decsai.ugr.es

(C) Decsai Web: http://decsai.ugr.es

Pasando seguidamente a los perfiles,  éstos suministran un interfaz de usuario, métodos de entrada y mecanismos de persistencia, así como un entorno de desarrollo completo para un conjunto específico de dispositivos, soportando sus características concretas. Los perfiles son necesarios porque las configuraciones no presentan ninguna de estas  prestaciones.  La razón principal para crear diferentes perfiles es el hecho de que, por ejemplo, un teléfono móvil tiene diferentes funcionalidades y conductas que una lavadora (al primero se le requerirá envío y recepción de correo electrónico, pero no funciones de inicio y parada programadas, como a la lavadora). Así, J2ME oferta al programador el concepto de perfil, el cual define una plataforma común para un grupo determinado de dispositivos, los cuales comparten características y funciones.  Un dispositivo puede cubrir más de un perfil.

Los perfiles se asentan sobre una configuración dada y utilizan los servicios que ofrece, aunque es la parte de la arquitectura J2ME que más cerca se encuentra del aparato físico. Para el caso de CLDC, su único perfil es MIDP (Mobile Information Device Profile), el cual cubre el mercado de dispositivos móviles, que comparten características como memoria limitada, pantalla pequeña, conexión a algún tipo de red inalámbrica y mediante banda ancha limitada y alimentados normalmente por baterías . El software desarrollado con MIDP se ejecuta en el KVM suministrado por CLDC.

MIDP - MIDlets

Las aplicaciones MIDP se denominan "MIDlets", las cuales pueden utilizar tanto las facilidades aportadas por MIDP como las APIs que MIDP hereda de CLDC, pero nunca acceden directamente al sistema operativo subyacente, por lo que no serían portables. Un MIDlet consiste en una clase Java, como mínimo, derivada de la clase abstracta MIDP, y que se ejecutan en un entorno de ejecución dentro de la máquina virtual, la cual provee un ciclo de vida bien definido controlado mediante métodos de la clase MIDlet que cada MIDlet debe implementar. También estas aplicaciones usan métodos de esta clase abstracta para conseguir servicios de su entorno. Un grupo de MIDlets que están relacionados se suelen agrupar en un MIDlet suite. Todos estos MIDlet se empaquetan,  instalan, desinstalan y borran como una única entidad y comparten recursos tanto en tiempo de ejecución  (se ejecutan en la misma máquina virtual, lo que implica que compartirán instancias de de todas las clases de Java cargadas en la máquina virtual), como estáticos (el almacenamiento persistente se gestiona en el nivel de suite).

Veamos seguidamente algunos detalles sobre los dispositivos que soportan MIDP. Comenzando con los requerimientos de memoria, MIDP necesita 128 KB de RAM disponible para la implementación correspondiente. A esta cantidad debemos sumarle la que necesita CLDC y como mínimo 32 Kbytes para almacenar la pila de la aplicación, tamaño que obliga al programador a tener bastante cuidado a la hora de diseñar las aplicaciones. Además, los dispositivos MIDP cuentan con 8 Kbytes como mínimo de memoria no volátil que se utiliza como almacenamiento persistente, que no se borra tras apagar el aparato (salvando el problema del cambio de batería).

Sobre las pantallas de los dispositivos, la especificación MIDP indica que ésta requiere 96 pixels de ancho por 54 de alto y que debe soportar al menos dos colores (como es el caso de muchos teléfonos móviles, en contraposición con algunas PDAs que tienen pantallas de 160 pixels en ambas direcciones y 65.536 colores diferentes).

Con respecto a los tipos de entradas del dispositivo, el rango es muy amplio: desde los que tienen un teclado alfanumérico completo, hasta aquellos que permiten escribir en ciertas áreas de la pantalla, pasando por los teclados de los teléfonos móviles. La especificación mínima requiere un teclado que permita marcar los números del 0 al 9, junto con el equivalente a las teclas del cursor y un botón de selección.

MIDP no asume que los dispositivos estén permanentemente conectados a una red, ni siquiera que soportan TCP/IP, pero que sí tienen algún tipo de acceso a una red. En este sentido, la especificación sí establece que soporte HTTP 1.1, bien mediante una pila de protocolos o una pasarela WAP.

También los sistemas operativos de los dispositivos tienen restricciones con respecto a MIDP. Por ejemplo, deben ofrecer un entorno de ejecución protegido donde la máquina virtual pueda correr, o algún tipo de apoyo para el acceso a una red, como puede ser el caso de un API para programar sockets, sobre el cual el protocolo HTTP se pueda implementar.  Es el sistema operativo el que ofrecerá acceso al teclado y al posible dispositivo puntero, entregando los correspondientes eventos que surjan. Además, será el encargado de abstraer al MIDP la pantalla, ya que será visto por él como una matriz de pixels, y de ofrecer un interfaz para el acceso al almacenamiento persistente.

Un aspecto muy importante a tener en cuenta es el de la seguridad. J2SE ofrece un modelo de seguridad potente y flexible, y a la vez, costoso en términos de memoria, razón por la cual CLDC y MIDP no incluyen ningún tipo de prueba en las llamadas al API de las que incluye J2SE. Para un usuario de un dispositivo móvil esto puede suponer un peligro, porque el MIDlet no está limitando en ningún sentido. Es por esto por lo que el usuario debería ser bastante cuidadoso a la hora de instalar nuevas aplicaciones.

Los MIDlets necesitan empaquetarse antes de que sean trasferidos a un dispositivo para su instalación: tanto la subclase MIDlet correspondiente como las clases que requiera y el resto de ficheros necesarios (como pueden ser ficheros de imágenes) constituirán un único fichero JAR, incluyendo el conocido como manifiesto del JAR (contiene información de empaquetado que indica qué se almacena en el fichero JAR). Adicionalmente se emplea otro segundo fichero conocido como Java Application Descriptor (JAD). El manifiesto del JAR almacena el dispositivo, el nombre y la versión del MIDlet suite en el JAR correspondiente, así como qué ficheros de clase se corresponde con cada MIDlet, información útil para instalar los MIDlets. El segundo es un fichero de texto que contiene una lista de atributos junto con su valor correspondiente. Algunos atributos están también contenidos en el manifiesto del JAR, ya que éste puede ser grande y su transferencia lenta debido a la baja velocidad del acceso a la red que suelen tener estos dispositivos, en vez de descargar el JAR completo, se descarga el fichero JAD, el cual es mucho más pequeño y rápido de transferir, se muestra por la pantalla del dispositivo y se decide si se instala o no.