jueves, 29 de abril de 2010

Introducción a J2ME Parte XVII

Otras alternativas a la programación con Java

Cuando la portabilidad, una de las principales requerimientos que nos hace elegir Java como plataforma de programación de dispositivos móviles, no es primordial, entonces podemos utilizar otras alternativas. Otros motivos que nos pueden inducir a no tomar Java como la plataforma idónea para nuestros  desarrollos es que los desarrolladores tienen que esperar en ocasiones a que se desarrolle la máquina virtual y un API para el dispositivo con el que tenemos que trabajar, y unas veces podremos esperar, pero otras no. También tenemos que tener en cuenta el rendimiento que debe ofrecer nuestra aplicación porque con Java, la máquina virtual tiene que interpretar realmente un programa en byte-code en tiempo de ejecución, con la consiguiente pérdida de velocidad. Si necesitamos máxima velocidad de ejecución, quizá Java no sea la mejor opción y tenemos que buscar alguna otra alternativa. Entre estas destacamos:

WAP y WML

Cuando no se necesite ningún procesamiento ni almacenamiento en el dispositivo una buena opción es el empleo del Wireless Application Protocol (WAP) junto con el Wireless Markup Language (WML).  WAP es un conjunto de especificaciones para construir aplicaciones basadas en web para redes inalámbricas. WML es la parte de WAP que especifica el formato de la información para que pueda ser transferida entre dispositivos. WAP se basa en parte en Internet para trasladar la información a las pantallas de los teléfonos móviles o PDAs, dotados estos con navegadores WAP.

Otros lenguajes

La mayoría del software escrito hoy en día no emplea Java, sino que lenguajes como C++, C o Visual Basic se presentan como los más populares para estas tareas.  Las compañías han desarrollado completos entornos integrados para estos lenguajes en diferentes sistemas operativos como Windows CE o Palm OS.
Otro lenguaje que está teniendo bastante éxito es SuperWaba, también dedicado a la programación de dispositivos pequeños. Define un lenguaje, una máquina virtual, un formato de ficheros .class y un conjunto de clases base. SuperWaba desciende de Waba y es compatible con esta.  La sintaxis de los programas escritos para SuperWaba es un subconjunto del lenguaje Java, lo que permite que los desarrolladores que estén familiarizados con Java puedan comenzar rápidamente a utilizar el SuperWaba. El formato de los ficheros clase (.class) de SuperWaba son también subconjuntos del formato Java. Sin embargo, SuperWaba no deriva de Java ni tiene que ver con Sun Microsystems. El lenguaje definido por SuperWaba, su máquina virtual y el formato de los ficheros clase han sido diseñados de forma tal que sean óptimos para su uso en PDAs. Las características de Java que usaban mucha memoria o que eran innecesarias para los PDA's han sido omitidas en el diseño del lenguaje y su máquina virtual.
 

Introducción a J2ME Parte XVI

Otras plataformas JAVA

Existen otras tecnologías Java, guiadas por sus propias especificaciones, que están fuera de J2ME, para desarrollar aplicaciones en dispositivos distintos a los que se dedica J2ME. Veamos brevemente algunas de ellas.

JavaCard

La tecnología JavaCard tiene por objeto permitir el desarrollo de aplicaciones en Java que puedan ser usadas en tarjetas inteligentes. Las principales complicaciones tienen que ver con lo limitado de los recursos de hardware, mientras que las ventajas se relacionan con la posibilidad de ocupar un lenguaje de alto nivel en un ambiente en que lo usual es programar en algún tipo de ensamblador difícil de depurar.
Algunas tarjetas del estilo a las de crédito se les está dotando de un microprocesador o un chip de memoria. Algunas de estas tarjetas inteligentes "smart  cards" poseen la capacidad de procesar, por sí mismas, datos almacenados en ella. Otras necesitan la asistencia de un lector, pero contienen un repertorio de instrucciones para manipular los datos.  Además, no necesitan acceder a sistemas remotos, como es el caso de las de banda magnética. Típicamente, las tarjetas tiene 1 Kbyte de memoria RAM, 16 Kbyte de EEPROM y 24 Kbytes de ROM.
Las aplicaciones de estas tarjetas se están extendiendo velozmente, ya que por ejemplo las están utilizando ya varias entidades bancarias, gobiernos para sustituir tarjetas de identificación o carnets de conducir o empresas de transporte para sustituir los sistemas actuales de tarjetas magnéticas.
JavaCard fue diseñado para ofrecer una solución fiable a la protección de datos y recursos mediante Java. Teniendo en cuenta el reducido entorno para el que ha sido pensado, JavaCard elimina ciertas construcciones de Java consideradas como demasiado complejas o no aplicables para la programación de tarjetas inteligentes no son incorporadas y por otro lado se agregan facilidades específicas para el manejo de transacciones con tarjetas inteligentes (atomicidad de un grupo de operaciones, objetos persistentes, etc.). Las políticas de seguridad de Java (conocidas como el sandbox model) que prohíben cualquier interacción entre objetos de diferentes applets fueron modificadas, y en algunos casos, debilitadas: JavaCard, por ejemplo, permite que un objeto sea compartido por diferentes applets.
Cuando una tarjeta que contiene uno o varios applets se inserta o presenta de alguna forma a un lector de tarjetas, la máquina virtual de esta plataforma identifica el applet con el que se quiere comunicar y el lector le envía una serie de mandatos a ejecutar.
La tecnología JavaCard está compuesta por tres componentes: la máquina virtual (JCVM), el entorno de ejecución (JCRE) -que actúa como sistema operativo- y el API. La máquina virtual la forman un conversor, es decir, una máquina virtual fuera de la tarjeta (residente en un PC, por ejemplo) y otra intérprete que reside en la tarjeta.  La primera convierte ficheros de clases de Java en los conocidos como Converted Applets, que son ejecutados por el intérprete.

EmbeddedJava

Este tipo de Java está dirigido a desarrollar aplicaciones relacionadas con el acceso a red, concretamente con la entrega de servicios bajo demanda. Para conseguirlo, un servidor de Java embebido se integra en cualquier dispositivo de red específico, como por ejemplo, una pasarela, máquinas de venta en la calle, dispensadores de gasolina, automóviles, de tal forma que el servicio se efectúe a través de la red.  La máquina virtual no requiere más de 500 Kbytes.

JavaPhone

Es un API desarrollado para dos tipos nuevos de teléfonos: los teléfonos inteligentes y los teléfonos con pantalla para Internet.  Los primeros conjugarán comunicaciones por voz, fax, correo electrónico, comunicación vía radio, paginación, acceso a Internet, planificación de tareas al estilo de los PDAs y muchas otras funciones que los teléfonos móviles, PDAs y paginadores presentan. Los segundos, son pantallas de vídeo y opcionalmente teclados  que permiten comunicaciones personales en Internet. JavaPhone ofrece una biblioteca de clases para desarrollo de aplicaciones en estos teléfonos futuristas.

Java TV

El API de Java para la televisión digital interactiva ofrece una plataforma para escribir programas Java para controlar la televisión y los "set-top boxes" creados para el entretenimiento digital, de manera que sean independientes de la tecnología subyacente de emisión.  Entre algunas de las aplicaciones podemos destacar la posibilidad de seleccionar la cámara desde la que queremos ver un partido de fútbol o una jugada concreta, o seleccionar vídeos o juegos bajo demanda. Java TV se compone de una máquina virtual Java estándar y varias bibliotecas del propio lenguaje Java y específicas.
 

Introducción a J2ME Parte XV

Entrega e instalación de MIDlets
La entrega e instalación de aplicaciones en dispositivos, así como su desinstalación y eliminación del sistema no viene determinada por la especificación MIDP, ya que son muy específicas de cada dispositivo, aunque sí hace referencia a un software llamado Application Management Software (AMS - Software de gestión de aplicaciones), que es el que se encarga de estas tareas. Tanto el Wireless Toolkit como la edición MIDP para PalmOS tiene sus propias implementaciones del gestor, permitiendo que el software se instale de dos formas diferentes:

Desde un ordenador local, por medio de una conexión de velocidad relativamente alta.

Esta forma es la típica para los PDAs, pues normalmente viene asociadas a un ordenador portátil o de sobremesa con el que periódicamente se sincronizan. Este proceso consiste en trasladar los datos del usuarios desde el aparato al ordenador y enviar copias de software y también datos en la dirección contraria. El MIDP de PalmOS permite la instalación de MIDlets suites durante la sincronización. Una vez que se han instalado, pueden ser se pueden ejecutar en el PDA como cualquier otra aplicación.

Desde una red de ordenadores a la cual esté el dispositivo conectada.

Este es el método más común para teléfonos móviles y dispositivos inalámbricos similares, aunque también la utilizan PDAs con conectividad a una red.  Este proceso es el ya conocido como entrega Over-The-Air (OTA), lo que permite hacer la instalación desde servidores HTTP.    
 El proceso básico es la instalación de los MIDlet suites en un servidor web, ofreciendo hiperenlaces a ellos. Desde un teléfono, el usuario activa ese enlace para bajárselo  vía WAP o un micronavegador de Internet.  Es decir, el que suministra el MIDlet escribe un a página como la siguiente y la cuelga en su web:

                      pincha aquí para bajarte el fichero.
                     
El usuario del móvil se conecta a la página donde el fichero JAD se ha dejado y se lo baja. El fichero miMIDPletSuite.jad contendría algo parecido a esto:
MIDlet-Name: miMIDPletSuite
                       MIDlet-Jar-URL: http://miempresa.com/miMIDPletSuit.jar  
                       MIDlet-jar-Size: 8592
Una vez descargado en el móvil, el control pasa al software de gestión de aplicaciones del aparato, el cual muestra al usuario el contenido y éste decide si instalarlo o no. En este momento sólo se ha descargado un fichero JAD de tamaño pequeño.  Si se decide instalar, la aplicación AMS localiza el URL donde está el fichero JAR y la pide al servidor. Seguidamente pasa a instalarla. El AMS envía, una vez finalizado el proceso, un código al servidor indicando si ha habido algún error o no, y en caso de haberlo, el tipo.
El programa AMS también se encarga de realizar la actualización de MIDlet suites ya existentes. Como el fichero JAD también contiene la versión del software que se va a instalar, el gestor de aplicaciones determinará si es una versión más moderna que la que ya hay en el dispositivo, en cuyo caso pide permiso al usuario para llevar a cabo su instalación.  Además, debe permitir la selección de MIDlets y su posterior ejecución. Por último, también es el encargado de realizar la eliminación del software a petición del usuario. Los MIDlets no se pueden borrar individualmente, sino que se debe liberar el almacenamiento persistente que se le asignó al MIDlet suite.
 

Introducción a J2ME Parte XIV

Breve descripción de los principales entornos integrados
Un entorno de desarrollo integrado (las siglas en inglés son IDE) tiene como objetivo mejorar la productividad del desarrollador ofreciéndole un conjunto de herramientas totalmente cohesionadas entre sí, a través de un inferfaz gráfico de usuario.
Como mínimo, un IDE estará compuesto por un editor, un gestor de proyectos, un entorno de ejecución y un depurador.  Si nos centramos en aquellos que soportan J2ME, éstos deberían contemplar las siguientes herramientas:
  • Gestor de proyectos (ficheros fuente y atributos de los MIDlets).
  • Editor (de código y recursos).
  • Construcción de ficheros de clases (compilación, eliminación de información necesaria y preverificación del código fuente).
  • Generación de paquetes (empaquetado de MIDlets en ficheros JAR y JAD).
  • Emulación (ejecución de MIDlets en un emulador de dispositivo).
  • Depurador de MIDlets.
  • Documentación y tutoriales, ya que al ser el desarrollo de aplicaciones J2ME un proceso complejo que integra muchos aspectos de Ingeniería del software, cualquier ayuda es poca en ese sentido.
Algunas otras características adicionales que pueden ser interesantes son:
  • Apoyo a la entrega de aplicaciones. J2ME Over-the-air (OTA) estandariza el proceso de búsqueda, descarga, autenticación, verificación y ejecución de una aplicación Java para un dispositivo móvil.
  • Desarollo completo de aplicaciones, no sólo la parte del dispositivo, que actuarán como clientes, sino los propios servidores que se ejecutarán en ordenadores de sobremesa.
  • Herramientas RAD (Rapid Application Development), que permiten construir visualmente interfaces de usuario.
Hay que tener en cuenta que en el mercado de dispositivos móviles, cada vendedor tiene su propias herramientas de desarrollo, emuladores de dispositivos y aplicaciones para el análisis del rendimiento. 
Algunos de los IDEs principales son:

J2ME Wireless ToolKit (J2MEWTK) 


Contiene una implementación de referencia de J2ME (MIDP) y múltiples emuladores de dispositivos. Este entorno de Sun se encuentra disponible para sistemas operativos de la familia Windows y Unix/Linux. En realidad no es un IDE como tal, pues no posee prestaciones de edición y depuración, que son imprescindibles.  Sí contiene un mínimo entorno de desarrollo con un interfaz gráfico para compilar, empaquetar y ejecutar aplicaciones MIDP.

JBuilder 7 Enterprise con MobilSet3


JBuilder es ya un entorno clásico dentro del desarrollo con Java para varias plataformas. Posee tres ediciones, de las cuales la más completa es la Enterprise. Es precisamente sobre esta donde se fundamenta su uso con J2ME, ya que para desarrollar en este lenguaje para  móviles hay que instalarse un módulo adicional llamado MobileSet. Una vez instalado, añade prestaciones adicionales a JBuilder, como entornos de compilación y ejecución y ayudantes específicos.

Sun ONE Studio 4 Mobile Edition

Este entorno ofrece tres posibilidades: Community, Mobile y Enterprise. Las dos primeras son gratuitas. La versión Mobile tiene pocas prestaciones como IDE, aunque su diseño modular permite que terceros puedan desarrollar e integrar nuevos componentes.

Metrowerks CodeWarrior Wireless Studio 7


La edición profesional incluye desde un Java 2 SDK hasta un gran número de emuladores de dispositivos y compiladores.

jVise from S5 System

Está basado en el proyecto Eclipse, el cual ofrece un conjunto de funcionalidades como IDE en un motor de ejecución. Tanto vendedores como desarrolladores individuales pueden añadir características adicionales al entorno.
 

Introducción a J2ME Parte XIII

Desarrollo de aplicaciones para dispostivos móviles - Consejos

Consejos para el desarrollo

    Algunos consejos para desarrollar aplicaciones con J2ME pueden ser los siguientes:
  1. Evite ejecutar tareas computancionalmente intensivas en el dispositivo. Cuando sea posible, la alternativa más sencilla es hacer que una posible aplicación servidora en una máquina servidora sea la haga el cálculo y que la aplicación que corre en el dispositivo sólo se encargue de la gestión del interfaz y de mínimas operaciones.Simplifique la aplicación, es decir, dejarla tan simple como sea posible, eliminando características superfluas. Esta decisión básicamente debe realizarse en tiempo de diseño. Si se va la necesitar un requerimiento sólo de vez en cuando, entonces lo mejor es desarrollar una segunda aplicación auxiliar que la contenga, dando la oportunidad a los usuarios a que puedan eliminar dicha aplicación si no la necesitan.
  2. Escriba aplicaciones más pequeñas (Smaller is better) ya que consumirá menos memoria, requerirá menos tiempo de instalación y de inicialización al ser ejecutada. Un aspecto para alcanzar este fin es el de reducir el número de clases de la aplicación.
  3. Utilice menos  memoria en tiempo de ejecución. Para ello podemos considerar el uso de tipos escalares en sustitución de objetos más complejos siempre que sea posible, como son int y boolean, por ejemplo, ya que cada vez que construimos un tipo, el constructor entra en funcionamiento reservando el espacio de memoria requerido para alojarlo. También otro consejo en este sentido es alojar objetos cuando realmente sea necesario (lazy instantiation). Así, cuando vayamos a utilizar un objeto podemos preguntar previamente si ha sido creado o simplemente apunta a null.
  4. Libere los recursos del programa tan pronto como se acaben de utilizar.  Una vez que se finalice el uso de conexiones a bases de datos, a la red, a ficheros, etc., liberarlos, ya que dejaremos libre la memoria que implica su gestión y se pondrán a disposición de otras aplicaciones.
  5. Reutilice objetos en lugar de continuamente crearlos y abandonarlos.  La idea, por tanto, es escribir métodos de inicialización  de objetos y también de dejarlos en un estado neutro para posteriormente poder emplearlos en otros menesteres.
  6. Evite excepciones cuando se pueda, ya que redundará en la reducción del tamaño de los ficheros de clase y el número de objetos que se alojen en memoria. Siempre que se pueda solventar el problema de otra forma es mejor.
  7. Utilice variables locales, ya que es más lento acceder a un miembro de una clase que a una variable local.  Por ejemplo, si accedemos a una variable miembro dentro de un bucle una y otra vez, será conveniente asignar el miembro a una variable local, que se almacenará en la pila, y acceder continuamente a ella.  También es útil esta técnica para operar con elementos de un vector en vez de acceder directamente por medio del vector.
  8. Evite concatenación de cadenas de caracteres debido a que se emplea un par de llamadas a métodos de la clase String más la del constructor correspondiente. Esto lo tenemos que tener más en cuenta, aún si cabe, si se hace en un bucle.
  9. Emplee hilos. Por norma general, todas aquellas operaciones que lleven más de una décima de segundo deberían ejecutarse en un hilo separado, de tal forma que no se bloquee el interfaz de usuario, aspecto muy importante en los dispositivos móviles.

Introducción a J2ME Parte XII

Desarrollo de aplicaciones para dispostivos móviles.
El desarrollo de aplicaciones destinadas a dispositivos móviles, desde el punto de vista de la Ingeniería del Software, no debe diferir sustancialmente de los pasos a dar cuando se construyen aplicaciones para ordenadores de sobremesa o estaciones de trabajo.  Así, podríamos establecer los siguientes pasos previos:

Análisis de requerimientos.

El analista de turno deberá determinar, normalmente con varias entrevistas con los usuarios, las necesidades que estos tienen y los requerimientos que se les pedirán a la aplicación. Por ejemplo, en el caso de un análisis para una aplicación que se ejecutará en un dispositivo móvil, algunos de estos requerimientos generales pueden ser la facilidad de uso, que se pueda ejecutar en teléfonos móviles, PDAs y paginadores, que permita una conexión a una entidad mayor para obtener datos actualizados o devolver otros, o también, que sea capaz de almacenar cierta información de manera persistente.

Diseño de la aplicación. 

Es muy importante en este tipo de aplicaciones el crear programas separados por cada uno de los posibles usos que se le dé a la aplicación. De esta manera cada programa será más pequeño y se adaptará mucho mejor a las características de los dispositivos móviles.  Por tanto, a la hora del diseño nos plantearemos esta tarea seriamente, pues finalmente serán varias las ventajas de hacerlo así. Ya en la fase de implementación se tendrá que establecer un mecanismo que controle las diferentes aplicaciones.
 En cuanto al diseño del interfaz de usuario, debemos decidir  la correspondencia entre la aplicación y la pantalla. Los diseñadores en esta fase no deben considerar cómo los usuarios operarán con el dispositivo para llevar a cabo una tarea, o cómo se notificará a la aplicación las acciones del usuario. Se deben concentrar sólo en el objetivo de la pantalla y en la tarea que permitirá llevar a cabo.  Sun recomienda en esta etapa que se haga un "story board" conteniendo en cada viñeta los requerimientos para la pantalla correspondiente. En otra fase se decidirá qué tipo de controles vamos a utilizar para realizar entradas de datos y cómo vamos a presentar la información. En este punto, las características generales en cuanto a pantalla del dispositivo pueden marcar claramente el tipo de diseño de interfaz: lo que en uno se puede disponer en una única pantalla, en otro podremos necesitar varias.
El almacenamiento persistente es un aspecto a tener en cuenta en nuestro diseño. La pregunta a responder es: ¿qué datos deben sobrevivir a la finalización de la aplicación y estar disponibles para la siguiente vez que se vaya a ejecutar? Otra cuestión, que no se debe plantear en esta fase sino en la de implementación es qué utilizar para realizar ese almacenamiento. Una primera respuesta es aquel formato que se emplee para enviar y recibir datos entre el dispositivo J2ME y el sistema externo. Con esto evitamos una fase de conversión de formatos. Si el dispositivo posee sistemas de ficheros, entonces podemos optar por la creación de un fichero con una estructura más o menos compleja y usar las bibliotecas de Java para acceder a ellos. Otra alternativa también puede ser emplear sistemas de gestión de bases de datos relacionales, aunque en el caso de tener que tener que almacenar un gran volumen de datos y realizar gran cantidad de accesos.
Finalmente, debemos tener en cuenta dentro del diseño aspectos relacionados con la conectividad y con la entrada / salida, ya que son puntos muy importantes que van a determinar la portabilidad de la aplicación.  Por tanto, en este momento deberemos tomar decisiones en un nivel de abstracción alto, que luego se concretarán cuando determinemos claramente el tipo de dispositivo y sus prestaciones.

Implementación de la aplicación.

Esta etapa vendrá marcada por la elección del lenguaje, plataforma y herramientas de desarrollo (depuradores, entornos integrados,...). Con J2ME, teniendo en cuenta tipo de dispositivo con el que vamos a trabajar, decidiremos la configuración y perfil más adecuados.

Los pasos a seguir en esta fase hasta instalar el programa en el dispositivo serían los siguientes:
  1. Escritura del código.
  2. Compilación de la aplicación.
  3. Eliminación de información de clases innecesaria (obfuscate). Esta etapa es opcional y en ella se renombran clases, métodos, interfaces, con objeto de hacerlo ambiguo. Un paquete obtenido de esta fase lo protege de la descompilación y de la ingeniería inversa. Además, reduce el tamaño de los ficheros de clase, dando lugar a ficheros JAR más pequeños.
  4. Ejecución del preverificador para añadir la información de "clase verificada" a los ficheros de clase.
  5. Empaquetamiento de la aplicación: creación del fichero JAR y JAD.
  6. Ejecución en un emulador apropiado.
  7. Instalación en el dispositivo y ejecución. En este caso existen dos modos de hacerlo: en el primero, se descargará la aplicación a través de una conexión de red, se cargará en memoria, se ejecutará la aplicación, y finalmente se eliminará cualquier traza de ésta en el dispositivo; en la segunda, y siempre que el dispositivo lo permita, se instalará físicamente. En el entorno J2ME, Java Application Manager (JAM) es un gestor que controla la descargar, instalación, lanzamiento y desinstalación de aplicaciones en el dispositivo.

Introducción a J2ME Parte XI

Un vistazo más profundo a la arquitectura J2ME:  MIDP

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.

Introducción a J2ME Parte X

Un vistazo más profundo a la arquitectura J2ME: CLDC 
Como ya hemos visto, J2ME se sustenta en dos bloques principales: la configuración y el perfil. Volviendo a repasar estos conceptos, una configuración define la plataforma mínima necesaria para un grupo de dispositivos que tienen similar memoria y capacidades de procesamiento. Se compone de una máquina virtual, unas características del lenguaje Java y un conjunto mínimo de clases que soporta ese grupo de dispositivos. Por otro lado, un perfil extiende una configuración y completa las necesidades específicas para una cierta familia de dispositivos. Un perfil tiene asociado un conjunto específico de bibliotecas mínimas.

Configuraciones

J2ME presenta dos configuraciones: CLDC y CDC. La primera se dedica a dispositivos con estrictas limitaciones de memoria, capacidad de cálculo, consumo y conectividad de red. Por otro lado, CDC se encarga de dispositivos con más potencia. Parte de CLDC es un subconjunto de CDC, por lo que la portabilidad de aplicaciones se puede conseguir cuando nos movemos de un entorno más restringido a otro más rico. De la misma manera, y siguiendo en el hilo de la portabilidad, una aplicación en J2ME podrá ejecutarse en J2SE normalmente, salvo que se utilicen las bibliotecas específicas de J2ME.

CLDC

Veamos más detalladamente algunas características de CLDC, ya que es la configuración en la que nos centraremos en este curso. Comencemos por las propiedades mínimas requeridas a un dispositivo para poder desarrollar con esta configuración:
  • De 160 a 512 Kbytes de memoria disponible para el entorno de Java.
  • Un procesador de 16 o 32 bits.
  • Consumo de energía bajo (generalmente utilizan baterías).
  • Permiten algún tipo de conectividad a una red (lo normal, es una conexión intermitente, con un ancho de banda bajo -sobre 9600 bps- y a menudo inalámbrica.
Al tener como objetivo dispositivos con prestaciones reducidas, CLDC elimina una gran cantidad de características que sí aparecen en J2SE, tanto en el propio lenguaje Java como en la máquina virtual, como por ejemplo:
  • Interfaz nativo de Java (Java Native Interface -JINI) (Máquina virtual). 
  • Cargadores de clases definidas por el usuario (Máquina virtual).
  • Grupos de hilos e hilos demonios (Máquina virtual).
  • Finalización (lenguaje Java).
  • Referencias débiles (Máquina virtual).
  • Reflexión (Máquina virtual).
  • Tipos de datos de punto flotante (lenguaje Java).
  • Algunos aspectos de seguridad y APIs (Máquina virtual).
  • Verificación de ficheros de clases (Máquina virtual).
  • Posee algunas limitaciones en las gestiones de errores (lenguaje Java).
Pero ¿qué razones se consideraron para eliminar esas prestaciones? Por supuesto, una de ellas se basa en cuestiones de ahorro de memoria, ya que el tamaño general del API queda reducido. Aunque otras también han sido quitadas por cuestiones de aligerar el procesador, como es el caso de las operaciones en punto flotante, o la verificación de las clases. Concretamente, esta operación, que identifica y rechaza ficheros de clases inválidas, se realizaba en la máquina virtual en la edición J2SE, pero en ese caso aumenta su tamaño. Por esta razón, en J2ME la verificación se hace en dos partes: la primera, la preverificación, en un ordenador distinto; la segunda sí se lleva a cabo en el propio dispositivo, pero en este caso es mucho más simple y rápida.  Más adelante estudiaremos de manera más detallada el proceso de verificación.
Con respecto a la seguridad, al no definir CLDC completamente el sistema de seguridad de Java deben eliminarse prestaciones que sí figuran en el J2SE (por ejemplo, JINI, que permite la utilización de una biblioteca de clases escrita en otros lenguajes -enlazado en tiempo de ejecución) y que harían muy vulnerables las aplicaciones. Por ejemplo, sin este modelo de seguridad, un cargador de clases definido por el usuario podría alterar la forma en que el camino de las clases fuera recorrido, pudiendo una aplicación sustituir trozos de las bibliotecas del núcleo de Java y ganar acceso al dispositivo de tal forma que pudiera dañarlo.
También se considera la simple conveniencia como criterio: algunas clases pueden ser desarrolladas por los programadores basadas en otras que sí se mantienen. Igual ocurre con algunos métodos de clases. Por otro lado, otras clases se eliminan por que no tiene razón de ser: java.io.File tiene sentido si se trabaja en un sistema de ficheros, pero muchos dispositivos no disponen de él. En su lugar, CLDC utiliza las propias prestaciones del dispositivo.  Otro ejemplo en este sentido son la finalización de objetos, ya en el J2SE puede ocurrir que nunca se lleve a cabo. La eliminación de gestión de errores, por último, va en la linea de la utilidad de la acción, y del tiempo consumido en ello. Una excepción es un error que puede ser recuperable; un error, por el contrario, representa problemas muy serios y generalmente dependientes directamente del dispositivo, por lo que no merece la pena hacerlo.
En cuanto a la máquina virtual de CLDC, KVM, requiere entre 40 y 80 Kbytes dependiendo de las opciones de compilación y el tipo de dispositivo para el que se compile.  Esto implica que se podrán ejecutar aplicaciones con un total de 128 Kbytes. Aparte de esto, se necesitan otros 32 Kbytes para memoria dinámica de la aplicación a ejecutar. KVM está implementada en C y está diseñada para ser tan completa y rápida como sea posible. De hecho, puede ejecutarse de un 30 a un 80% de la velocidad de la JVM.
Volviendo a la verificación de clases, la máquina virtual de Java estándar efectúa un proceso en tiempo de ejecución que se denomina verificación de clases, el cual se lleva a cabo antes de cargar ninguna clase en memoria. El objetivo es asegurar la integridad de los ficheros donde se almacena una clase Java y que el código en ella no intente acceder a memoria fuera de su espacio de nombres, eliminando la posibilidad de que pueda sustituir alguno de los paquetes del núcleo de Java (java.* o javax.*), y poniendo así en juego la seguridad del sistema.  Esta etapa juega un papel muy importante en el modelo de seguridad de Java.
Para que nos hagamos una idea, J2SE verifica, entre otros, estos puntos:
  • Inicialización de todas las variables locales antes de su uso.
  • El constructor de un objeto debe ser llamado justo seguidamente de la creación del mismo, y antes de que se use.
  • Cada constructor tiene que comenzar con una llamada al constructor de su superclase.
  • Las variables locales y miembros estáticos deben contener referencias a objetos que sean asignables legalmente.
Si nos trasladamos a CLDC, este proceso será muy costoso en términos de uso de recursos, ya que requiere mucha memoria, procesador y espacio para código binario.  Es por esto por lo que los diseñadores de KVM decidieron hacer la verificación de clases de manera diferente a como se hace con JVM. Así, antes de que la clase se llegue a emplear en el dispositivo, ésta es modificada externamente por una utilidad "preverificadora". La idea es añadir al fichero clase generado por javac nuevo código que identifique la clase como válida (pasa a ser una clase verificada). Seguidamente, se transfiere al dispositivo y la KVM sólo tiene que comprobar si esta información está o no presente o contiene o no la información correcta. En cualquiera de los dos casos negativos, el proceso de carga se interrumpe y se lanza una excepción. Esta comprobación se puede hacer justo cuando se carga la clase o como parte del proceso de instalación de la aplicación. En cualquier caso es un proceso más rápido que la preverificación y requiere menos memoria.

miércoles, 28 de abril de 2010

Introducción a J2ME Parte IX

Tipos de dispositivos móviles - Sistemas Operativos

La familia Windows

Windows CE es el Sistema Operativo que Microsoft ha desarrollado a partir de Windows 95, para dispositivos móviles, y sirve de base para el desarrollo de los sistemas específicos de cada dispositivo. Lo que los usuarios finales disfrutan, no es Windows CE tal y como ha sido desarrollado. En cada tipo de dispositivo se implementa, desde las posibilidades que permite la versión de Windows CE disponible, una interfaz y las funcionalidades requeridas. Así, el Pocket PC 2000, 2002 y 2003 se han desarrollado específicamente para los PDAs. Windows CE nació como un sistema operativo de fácil programación, sólido, transparente y que podía implantarse desde un ordenador a una lavadora, nevera, microondas incluso videoconsolas (DreamCast). De hecho, se pensó en integrarlo en todo lo que no fuera un PC.
Windows CE .NET, es la evolución de Windows CE 3.0 bajo la filosofía distribuida de .NET. Es pues, un escenario de trabajo que deberá ser adaptado a cada dispositivo. Esta nueva versión tiene muchas ventajas, que pueden ser aplicadas a cada uno de los sistemas operativos derivados. Según Microsoft, Windows CE .NET, incorporará la posibilidad de manejar las conexiones Bluetooth, Microsoft Internet Explorer, Windows Media 8 y DirectX y será compatible con una amplio rango de procesadores como Xscale, ARM, MIPS, SH o x86. Cada sistema operativo derivado, tomará las propiedades que le competan. Para obtener más información sobre esta familia de sistemas, véase el sitio de Microsoft.
Los dispositivos PDA que disponen de Pocket PC son dispositivos con una magnífica pantalla de 240 x 320 píxeles a todo color. Son muy potentes, con procesadores de entre 133 y 206 Mhz y 16, 32 ó 64 Mbytes de RAM, por lo que son capaces de reproducir vídeo o música y ejecutar aplicaciones multimedia con gran rapidez. También disponen de altavoz y salida de audio para auriculares. Además incluyen diversos tipos de ranuras o slots de expansión, que permiten insertar tarjetas de diversos formatos (Multimedia, CompactFlash o PCMCIA) para aumentar memoria o incorporar módems, discos duros, tarjetas de red, etc.

Palm OS

La primera versión fue desarrollada por el fabricante de los DCM Palm para el modelo Pilot en 1996. Actualmente son muchos los fabricantes como Oracle, Nokia, Handspring, Symbol y Sony que utilizan diversas variantes y versiones de este Sistema Operativo que en conjunto representan el 66 % de todos los sistemas instalados en computadores de mano.  Según la filosofía de Palm, se intenta tratar a la computación móvil no como versiones en miniatura de los sistemas de sobremesa, sino como dispositivos y aplicaciones dedicados a tareas y usos que tienen su propia identidad y reclaman sus propios recursos y soluciones.
En los últimos años, la versión más extendida ha sido la 4.1 que entre sus principales características, presenta el soporte "teórico" de 65.000 de colores así como la gestión de tarjetas de memoria externa. Recientemente Palm Computing se dividió en dos empresas distintas, una de hardware y otra de software, Palm Source – la cual ha presentado Palm OS 5 que es realmente un sistema diferente a los anteriores aunque esto se refiera más al funcionamiento interno que a lo relativo a su utilización externa.
Para mantener la compatibilidad con la generación anterior del sistema operativo, la nueva versión incluye un emulador llamado PACE que permite ejecutar las más de 50.000 aplicaciones existentes. Además, cualquiera que sea la norma considerada, WiFi Lan, Bluetooth, GSM/GPRS, o CDMA, el sistema Palm OS 5 integra las APIs necesarias. O sea, que los dispositivos equipados con Palm OS 5 pueden comunicarse fácilmente con todos los dispositivos existentes que estén basados en esas normas tales como teléfonos móviles, impresoras, módems, etc. Las normas de seguridad incorporadas en el sistema, permiten que las transacciones sean hechas de forma segura, considerando también, el uso de firmas digitales homologadas. También ofrece servicios de encriptación  para las conexiones.
El sistema incluye asimismo un navegador para Internet, el NetFont que suporta entre otras normas, HTML 4.01, XHTML, los GIFs animados, el modo seguro de acceso a la red VPN (Virtual Private Network) y la interpretación de código JavaScript. Estas normas ya utilizadas en los sistemas de los computadores de sobremesa se introducen por vez primera en los equipos de mano.
En cuanto a los dispositivos que contiene Palm OS, la característica más llamativa es su reducido tamaño y ligereza: pesan entre 120 y 170 gr, y son en general más pequeños que los Pocket PC. Todos tienen una pantalla de 160x160 píxeles, normalmente monocroma. Usan procesadores de 16-33 Mhz que son suficientes para que el dispositivo funcione con rapidez, y disponen de 2 u 8 Megabytes de memoria RAM.

Linux

LINUX es un sistema operativo compatible UNIX. Dos características muy peculiares lo diferencian del resto de los sistemas más extendidos en el mercado, la primera, es que es libre, esto significa que no hay costos por sus licencias, la segunda, es que el sistema viene acompañado del código fuente. LINUX se distribuye bajo la licencia pública del proyecto GNU que fue lanzado en 1984 para desarrollar el Linux de libre distribución. El sistema ha sido diseñado y programado por multitud de programadores alrededor del mundo. El núcleo del sistema sigue en continuo desarrollo. En los últimos tiempos, ciertas casas de software comercial han empezado a distribuir sus productos para Linux y la presencia del mismo en empresas aumenta rápidamente por la excelente relación calidad-precio que se consigue.
En los últimos años, algunos fabricantes de dispositivos móviles han incorporado Linux a sus productos. Se están desarrollando versiones de Embedded Linux que constituyen la tercera alternativa a Palm OS y Windows CE para los computadores de mano. Así, LinuxDevices.com, ha creado ha creado una guía de referencia para computadores de mano basados en Linux, con la que pretende mantener actualizados de manera permanente los productos Linux para pequeños dispositivos. Si bien el modelo Sharp Zaurus SL-5x00 fue el primer computador de mano con Linux pre-instalado, hay actualmente versiones de Embbeded Linux para casi todas las marcas.

Epoc

El sistema operativo de Psion se llama EPOC, nombre del núcleo del antiguo sistema operativo de la Psion serie 3. Hasta 1997 Psion no comenzó a licenciar el EPOC32, la versión de 32 bytes para la serie 5. Permite realizar multitarea y pretende competir con Windows CE. El recibimiento fue frío y sólo Philips mostró algo de interés. Pero Psion reaccionó y a mediados de 1998 creó la alianza Symbian -junto con Ericsson, Nokia, Motorola y Matsushita- con el propósito de hacer de EPOC un sistema operativo único. El premio de esta apuesta es elevado: los 600 millones de usuarios de dispositivos móviles en año 2002.

Introducción a J2ME Parte VIII

Tipos de dispositivos móviles - El Personal Digital Assistant (PDA)
Un Personal Digital Assistant, o más conocido como PDA, es como su propio nombre indica un organizador digital. Básicamente ofrece calendarios, blocks de notas y agendas para teléfonos, como características comunes, por lo que en un futuro no muy lejano reemplazarán las agendas clásicas. También permiten descargar correo electrónico y otros materiales desde un ordenador, o con aquellos que ya están equipados con un módem, acceder a Internet.
Normalmente consisten en una pantalla, que suele ser táctil (utilizando un lápiz especial el usuario realiza la entrada de datos, eliminando la necesidad de un teclado, lo que facilita el transporte en el bolsillo. Además, reconocen la escritura sobre su pantalla), un procesador, memoria y un sistema operativo.  Además, permiten, como ya hemos dicho, conectividad con el ordenador de sobremesa, lo que posibilita salvaguardar los datos y exportarlos a bases de datos o a aplicaciones más elaboradas, o transferir nuevas aplicaciones al asistente.
Hay una amplia variedad de asistentes personales. Si nos fijamos en la pantalla, los hay desde los que son monocromos o como mucho presentan una escala de colores, hasta los que poseen más de 65.000. El tamaño también cambia de un modelo a otro y el tipo: los basados en matrices activas, presentan una mejor calidad que los basados en pasivas, los cuales consumen menos energía. Con respecto a esto, las baterías suelen ser recargables y removibles. La memoria varía entre los 2 y los 64 Mbytes. La primera cantidad es suficiente para aplicaciones básicas de block de notas, calendario, agenda y varias utilidades más. Si lo que se desea es almacenar ficheros grandes como fotos, bases de datos o programas de gran tamaño es imprescindible una memoria de mayor capacidad. Como ejemplo, citar que los PDAs de última generación son excepcionales para jugar y entretenerse, leer libros, ver fotos, escuchar música e incluso reproducir películas.   La memoria se puede ampliar mediante tarjetas.
Inicialmente la conexión al PC se realizaba mediante un cable, pero actualmente ésta se puede efectuar sin él, de manera inalámbrica. La sincronización se lleva a cabo mediante infrarrojos o radio (como es el caso de Bluetooth). De esta manera, a los usuarios se les permite intercambiar información como entradas de una agenda o correos electrónicos simplemente situándolo próximo al ordenador de sobremesa.  Pero la conexión inalámbrica va más allá aún, pues los PDAs pueden tener conectividad a una red "wireless" de área local o usar un módem CDPD (Cellular Digital Packet Data) para acceder a Internet, lo que aumenta sus posibilidades, como son las de navegación por la World Wide Web o el envío y recepción de correo electrónico, entre otras.
Un PDA, con respecto a un móvil, presenta algunas ventajas en general:
  • Las pantallas son más grandes y la visualización se mejora.
  • La interacción con el usuario es más fácil (fundamentalmente por ser la pantalla táctil).
  • Es más potente, desde el punto de vista computacional.
Sin embargo, también presentan algunos contras:
  • Necesita accesorios para comunicarse
  • El precio es mayor que el de un teléfono móvil.
 

Introducción a J2ME Parte VII

Tipos de dispositivos móviles - El teléfono móvil
Los teléfonos móviles son de los aparatos sofisticados que encontramos en nuestro cotidiano quehacer. Para comprimir y descomprimir señales digitales codificadas, tienen que procesar millones de cálculos por segundo. No obstante, se componen de apenas algunos componentes. Son estos:  
  • Un micrófono microscópico.
  • Un altavoz.
  • Una pantalla de cristale líquido o plasma.
  • Un teclado.
  • Una antena.
  • Una batería.
  • Una placa de circuitos. 
El móvil posee un microprocesador que realiza cálculos a gran velocidad, llamado DSP, o «Digital Signal Processor» (Procesador Digital de Señales). Este procesador hará toda la compresión y descompresión de los datos a la velocidad de 40 MIPS (Millones de Instrucciones Por Segundo). El microprocesador trata todas las tareas del teclado y de la pantalla, gestiona los comandos y controla las señales de la estación de base, además de coordinar las demás funciones.
Las ventajas que presenta un teléfono móvil como tipo de dispositivo móvil son varias:
  • Muy extendido.
  • Ligeros y transportable.
  • Económico.
  • Poseen prestaciones de comunicación innatas.
Por el contrario, también muestran algunos inconvenientes:
  • Poca potencia de proceso.
  • Poca memoria.
  • Capacidades de visualización limitada.
  • Interacción avanzada difícil.
En verdad, un teléfono móvil no es realmente un teléfono, pero sí un aparato de radio. Un teléfono móvil utiliza dos frecuencias diferentes: una para hablar y otra para escuchar, permitiendo una conversación normal. Un aparato de radio tiene 40 canales, un teléfono móvil comunica a través de millares. No obstante, como los teléfonos móviles funcionan en un sistema de células, y una radio transmite directamente para otro aparato, es decir, la radio tiene que ser mucho más potente, a pesar de tener un alcance de poco más de seis kilómetros.

¿Cómo se produce la comunicación?

La operadora de telefonía móvil correspondiente reparte el área en varios espacios, en varias células, normalmente hexagonales (forma geométrica que permite ocupar todo el espacio y se aproxima mucho a la circunferencia), compuesto de una inmensa red de hexágonos. En cada célula existe una estación base transmisora, típicamente, una simple antena. Cada célula consigue utilizar varias decenas de canales, lo que da la posibilidad que varias decenas de personas se comuniquen simultáneamente por ella. Cuando una persona se mueve de una célula para otra, pasa a utilizar la frecuencia de la nueva célula, dejando libre la célula anterior para ser usada por otra persona. Como las distancias de transmisión no son muy grandes, los teléfonos móviles pueden transmitir con poca energía, luego, con pequeñas baterías que permiten un tamaño y un peso reducido. Son, por tanto, las células, que tornan posibles los teléfonos móviles como los conocemos hoy. Por ello la expresión: teléfonos celulares.

Sistemas de telefonía móvil

En cuanto a los sistemas de telefonía, el primero de ellos es  GSM, que fue diseñado originalmente para transmitir voz, pero con el tiempo la tecnología les posibilitó también operar en modo de transferencia de datos. Los terminales operan por conmutación de circuitos, pudiendo ésta ser visualizada como dos interruptores que necesitan estar encendidos para que exista transmisión de información. Esto lleva a que el establecimiento de conexión conlleva tiempos de espera, debido a la necesidad de los dos módems estar conectados uno con el otro simultáneamente y que la llamada esté siempre abierta, aún cuando no existe transferencia de datos. Esta forma de transmisión es extremamente limitada en términos de capacidad, a pesar de estar a ser desarrollada tecnología como el HSCSD (High Speed Circuit Switched Data) que permitirá una velocidad máxima de 56 Kbps. Otro problema es el hecho de no ser posible a esta tecnología soportar el IP (Internet Protocol), lo que impide el acceso directo a Internet.
El estudio de las limitaciones de GMS origina la necesidad de un sistema basado en la transmisión de datos por paquetes (IP). En 1998 el ETSI (European Telecommunications Standards Institute), la entidad reguladora de las telecomunicaciones europeas, concluyó sus estudios sobre la definición de las normas de un nuevo sistema, el GPRS, que permite una mayor capacidad de transmisión de datos. GPRS permitirá una velocidad máxima teórica de 177.2 Kbps, en caso de que utilice todos los recursos del sistema.  Finalmente, el GPRS permitirá toda una nueva serie de aplicaciones dentro de los móviles, apenas accesibles hasta ahora a quien posea un ordenador personal, tales como la visualización de páginas de la Web, FTP, IRC, animación, etc. En resumen, el GPRS traerá consigo los siguientes beneficios:
  • Conexión a Internet permanente (siempre "on-line").
  • Establecimiento instantáneo de la conexión. 
  • Posibilidad de que la facturación del servicio sea realizada según la cantidad de información transmitida / recibida, al envés de ser contabilizado el tiempo que se está conectado.
  • Una mayor velocidad de transmisión de datos.
El UMTS (Universal Mobile Telecommunication System) es el nuevo protocolo que será utilizado en Europa por la 3ª generación de teléfonos móviles. Integrado en el proyecto de crear un estándar que pueda ser utilizado mundialmente (al revés de la 2ª generación, cuyos sistemas americano y europeo son incompatibles), el UMTS deberá alterar la forma de como los móviles son utilizados actualmente, al permitir capacidades multimedia y un acceso sin límites a Internet.
Con los adelantos tecnológicos de los últimos años dentro de Internet y de la telefonía móvil, se asiste ahora a una convergencia cada vez mayor entre estos dos medios de comunicación. El UMTS representará la unión de ambos en una única plataforma. También designado de 3G, o tercera generación de teléfonos móviles, este sistema permitirá que el usuario pueda acceder a imágenes y vídeos, así como a Internet de manera veloz, calidad de voz casi igual a la de las redes fijas, y una larga lista de otras funciones diversas.
El UMTS resulta de la necesidad de implantar una nueva generación de teléfonos móviles debido al aumento del número de usuarios de este medio de comunicación. El éxito del sistema GSM, dentro de Europa, conllevó la saturación de las frecuencias de radio que le fueron originalmente atribuidas. Tal problema creó la necesidad de lanzar una nueva generación y, a través de ésta, ampliar el espectro electromagnético disponible así como permitir el acceso a nuevos servicios.
La tecnología UMTS no será limitada a las redes móviles, estando prevista su utilización por otras redes.  La tecnología digital utilizada por el UMTS se denomina de WCMDA (Wide Code Multiple Division Access). Los datos son transmitidos en banda ancha, siendo divididos en paquetes antes de la transmisión, los cuales son después reunidos por el terminal antes de presentar la información en la pantalla. Este sistema está basado en el protocolo americano de los teléfonos móviles de segunda generación (el CMDA), no siendo compatible con el GSM.
Además de las funciones básicas a que estamos habituados en nuestro móvil, como simplemente telefonear a alguien o enviar / recibir mensajes, el UMTS permitirá acrecentar una nueva serie de características hasta ahora casi inaccesibles o apenas presentes en las películas de ciencia-ficción. El sistema permitirá el acceso a Internet a una velocidad más rápida que los módems normales, así como la transmisión de faxes, imágenes, vídeos y datos. Al mismo tiempo que estaremos telefoneando será posible visualizar en la pantalla, en tiempo real, la persona con quien comunicamos, en caso de que ésta también posea un móvil UMTS. El acceso a Internet será bastante más rápido y sin limites, pudiéndose acceder a cualquier tipo de información, en cualquier lugar en que estemos. Información, comercio y entretenimiento multimedia estarán disponibles en pantalla, en un sistema que integrará las redes de telecomunicaciones móviles, fijas y por satélite. Además del "roaming" a escala mundial, el UMTS permitirá la convergencia de los varios tipos de redes existentes.
Según la Comisión Europea, los servicios UMTS deberán poseer las siguientes características:
  • Capacidad multimedia y una gran movilidad. 
  • Acceso eficiente a Internet.
  • Alta velocidad. 
  • Portabilidad entre los varios ambientes UMTS (permitiendo el acceso a las redes UMTS terrestres y de satélite). 
  • Compatibilidad entre el sistema GSM y el UMTS, debiendo los terminales poseer "dual band" o funcionar en ambos los sistemas. 
Esta nueva tecnología deberá alterar radicalmente la manera como utilizamos los teléfonos móviles. Las personas tendrán el móvil más tiempo delante de los ojos que pegado a la oreja, debido a que este pasará a ser un dispositivo multimedia, como la televisión o la computadora. Al mismo tiempo, la transmisión de datos ocupará una parte mayor del tiempo de utilización del teléfono móvil, debido a todas las posibilidades existentes (enviar faxes, e-mails,...). La calidad de voz será semejante a la de los teléfonos fijos y la velocidad de transmisión de datos superior a la de un módem normal, lo que podrá significar que las personas usen apenas el móvil, en sustitución del teléfono fijo y del acceso a Internet a través del ordenador. Además, se tendrá la posibilidad de tener Internet en la palma de la mano.
 

Introducción a J2ME Parte VI

Tipos de dispositivos móviles
Antes de entrar detalladamente a describir algunos de los dispositivos móviles, vamos a concretar detalladamente el concepto de dispositivo que estará subyacente en el resto del curso. En inglés existe una amplia gama de términos para referirse a este tipo de aparatos: "information device", "information appliance", "consumer electronic", "embedded device" o "small device", por ejemplo.  En definitiva:
  • son aparatos pequeños,
  • con algunas capacidades de procesamiento,
  • móviles o no,
  • con conexión permanente o intermitente a una red,
  • con memoria limitada,
  • diseñados específicamente para una función, pero que pueden llevar a cabo otras más generales.
  • Normalmente se asocian al uso individual de una persona, tanto en posesión como en operación, el cual puede adaptarlos a su gusto.
  • La mayoría de estos aparatos pueden ser transportados en el bolsillo del propietario y 
  • otros están integrados dentro de  otros mayores, controlando su funcionalidad (como puede ser el ordenador integrado en una lavadora).
Sigamos con la descripción genérica de los mismos. Una característica importante es el concepto de movilidad: los dispositivos móviles son aquellos suficientemente pequeños para ser transportados y empleados durante su transporte.  Normalmente se sincronizan con un sistema de sobremesa para actualizar aplicaciones y datos. Un PDA es móvil, pero por ejemplo, un teléfono con pantalla para Internet, no sería móvil. Una aplicación de estos dispositivos es un vendedor que carga en su PDA, en su despacho, antes de salir de la oficina, los datos de los clientes que tiene que visitar. Durante su visita actualiza o modifica la información y, una vez termina su ruta, ya en la oficina, actualiza los datos en la aplicación corporativa.
Otro concepto importante es el término inglés "wireless" (en español, optaremos por inalámbrico).  Un dispositivo inalámbrico es aquel que es capaz de comunicarse o acceder a una red sin cables. Por ejemplo, un teléfono móvil, paginadores, comunicadores de bolsillos o PDAs. Este tipo de dispositivos se comportan como si estuvieran directamente conectados a una red mediante un cable, dando la impresión al usuario que los datos están almacenados en el propio dispositivo. Por ejemplo, el mismo vendedor puede cambiar a un teléfono móvil y emplearlo para consultar algún dato de un cliente justo antes de visitarlo.
Los conceptos de móvil y sin cables muchas veces se confunden. Por ejemplo, un PDA con datos en él y aplicaciones para gestionarlos puede ser móvil, pero  no tiene por qué ser wireless, ya que puede necesitar un cable para conectarse al ordenador y obtener o enviar datos y aplicaciones. Veamos otro ejemplo. Un teléfono móvil equipado con un pequeño navegador puede navegar por Internet. En este caso, se considera wireless, pero no se considerará móvil si no dispone de un valor añadido en forma de aplicaciones que aporte alguna función cuando no está conectado a otros sistemas. Si el PDA es capaz de conectarse a una red para obtener datos "en medio de la calle", entonces también será wireless.
Algunas de las características que hacen que estos dispositivos sean diferentes de los ordenadores de sobremesa son los siguientes:
  • Funcionalidad limitada.
  • No necesariamente extensible y actualizable.
  • En pocos años el usuario deberá cambiarlo.
  • Más barato.
  • Menos complicado en su manejo.
  • Fácil de aprender su operación.
  • No se requieren usuarios expertos.
Algunos de estos dispositivos son los siguientes:
  • Paginadores.
  • Comunicadores de bolsillo.
  • Teléfonos con pantalla para Internet (Internet Screen Phones).
  • Sistemas de navegación de automóviles.
  • Sistemas de entretenimiento.
  • Sistemas de televisión e Internet (WebTV).
  • Teléfonos móviles.
  • Organizadores y asistentes personales digitales (Personal Digital Assistant ).
Veamos a continuación de una forma más detallada los dispositivos que mayormente trataremos en este curso: el teléfono móvil y el PDA.
 

Introducción a J2ME Parte V

¿Son J2ME y WAP competidores?

Una idea muy común y errónea es que J2ME y WAP son competidores, es decir, ambos sirven para lo mismo y simplemente son dos filosofías diferentes para resolver un único problema. Podemos ver que esta creencia es totalmente falsa simplemente prestando atención a las definiciones de ambos conceptos.
  • Wireless Application Protocol (WAP) es un protocolo de comunicaciones diseñado para permitir que dispositivos wireless con pantallas pequeñas y conexiones de baja velocidad puedan acceder a Internet y aplicaciones de intranets. 
  •  J2ME es una tecnología que permite desarrollar aplicaciones genéricas para este tipo de dispositivos.
Vemos por tanto que son cosas muy diferentes y que no pueden competir entre sí, incluso son tecnologías complementarias, pues expande el uso de las aplicaciones que disponen de posibilidad de acceso a redes sin cable. Así, un usuario de PDA, por ejemplo, puede bajarse una aplicación que desea instalar mediante un navegador WAP estándar.

Introducción a J2ME Parte IV

Origen y breve descripción de J2ME - Arquitectura
La arquitectura de J2ME define configuraciones (configurations), perfiles (profiles) y paquetes opcionales, como elementos básicos para desarrollar aplicaciones que se ajustan a las características de un amplio rango de dispositivos. Cada combinación se optimiza según la memoria, la capacidad de procesamiento y de entrada/salida de una categoría específica de dispositivos.

Configuraciones

Las configuraciones están compuestas por una máquina virtual y un conjunto mínimo de bibliotecas de clases, las cuales serían un mínimo denominador común con que contarán todos los dispositivos de una configuración dada; o lo que es lo mismo ofrecen la funcionalidad para un rango particular de dispositivos con características comunes.
Existen dos configuraciones actualmente: Connected Limited Device Configuration (CLDC) y Connected Device Configuration (CDC):
  • CLDC es la más pequeña de las dos, diseñada para dispositivos con conexiones de red intermitentes, un procesador lento y memoria limitada (teléfonos móviles y PDAs, por ejemplo), es decir, CPUs de 16 o 32 bits y una memoria mínima de 128 a 256 Kbytes de memoria disponible para la implementación de Java y las aplicaciones. CLDC está estrechamente asociado a lo que se conoce como "Java inalámbrico" (Wireless Java), es decir la posibilidad de que teléfonos móviles puedan descargarse  aplicaciones Java, conocidas como MIDlets.  
  • CDC está orientado a dispositivos con más memoria, procesadores más rápidos y un ancho de banda mayor (por ejemplo, TV set-top boxes), es decir, los aparatos que están entre los que trata CLDC y los ordenadores de sobremesa. Esta configuración incluye una máquina virtual completa y un subconjunto de J2SE mayor.  Los dispositivos a los cuales se dirige esta configuración tienen CPUs de 32 bits y como mínimo 32 Mbytes de memoria para la plataforma y las aplicaciones.
En la siguiente figura podemos ver un cómo se relacionan las dos configuraciones existentes y también con respecto a J2SE.
Configuraciones J2ME
Las especificaciones de las configuraciones no indican ningún tipo de implementación de la máquina virtual, por lo que cada cual puede crear sus propios entornos de ejecución. Los que ha desarrollado Sun son Kilobyte Virtual Machine (KVM) para CLDC y C Virtual Machine (CVM).
En este curso estudiaremos de manera más detallada la configuración CLDC.

Perfiles

Con objeto de ofrecer un completo entorno de ejecución específico para cada categoría de dispositivo, las configuraciones se deben combinar con un conjunto de APIs de alto nivel, conocidas como perfiles, que definen el modelo de ciclo de vida de la aplicación, el interfaz de usuario y el acceso a las propiedades específicas del dispositivo. Algunos de los perfiles existentes son (varios todavía en la etapa de definición):
  • Mobile Information Device Profile (MIDP). Diseñado para teléfonos móviles y PDAs, incluye la interfaz de usuario, conectividad de red, almacenamiento local de datos y gestión de aplicaciones. Combinado con CLDC, MIDP aporta un entorno de ejecución para Java que minimiza los consumos de memoria y de procesador.  
  • Foundation Profile (FP). Este perfil es el de nivel más bajo asociado a CDC, ya que los perfiles CDC pueden ser vistos como capas que se añaden a  para proveer funcionalidades a los diferentes dispositivos. FP suministra una implementación de CDC con capacidades de acceso a red que se utiliza para aplicaciones embebidas en alto grado y sin interfaz de usuario.
  • Personal Profile (PP) es un perfil diseñado expresamente para dispositivos con un interfaz gráfico completo y con posibilidad de ejecución de applets. Incluye además las bibliotecas del Abstract Windows Toolkit (AWT). Añade, por tanto, un interfaz de usuario básico a FP.
  • Personal Basis Profile (PBP) es un subconjunto de PP que suministra un entorno para dispositivos que se puedan conectar a una red y que dispongan de un interfaz un poco más desarrollado que aquellos que posean los dispositivos donde PP va dirigido.
  • PDA Profile (PDAP) es similar al MIDP pero diseñado para PDAs que tengan mejores pantallas y más memoria de los teléfonos móviles. 
  • Game Profile (GP) ofrece la plataforma para escribir juegos en dispositivos CDC.
Actualmente el perfil más utilizado es MIDP, que será el que estudiemos con profundidad en este curso.
En el siguiente gráfico podemos ver un esquema modular con las diferentes configuraciones, perfiles y máquinas virtuales:
j2me
Las aplicaciones desarrolladas para un determinado perfil serán portables a cualquier dispositivo que soporte ese perfil. Cabe destacar también que un mismo dispositivo puede soportar varios perfiles y que sobre una configuración también pueden residir diversos perfiles.

Introducción a J2ME Parte III

Descripción de J2ME - Origen y evolución

Java comenzó su andadura como lenguaje de programación a mediados de la década de los noventa del siglo pasado. Originalmente fue concebido como un lenguaje para poder programar un amplio rango de aparatos electrónicos con capacidades de conectividad a partir de otro dispositivo del tipo de un asistente personal digital.  El espíritu inicial era realizar una adaptación de C++, tomando lo mejor de él y a la vez mejorándolo y que se adecuara a las restrictivas condiciones ofrecidas por los chips de los aparatos a programar, teniendo como principales objetivos la fiabilidad y la seguridad. Además, se intentaba que una vez que fuera desarrollado el programa, éste se pudiera ejecutar en varios tipos diferentes de aparatos sin necesidad de volver a compilarlo.
 Con la llegada de Internet y los primeros navegadores para la World Wide Web, los desarrolladores de Java se dieron cuenta de su aplicabilidad a este nuevo medio, naciendo así la tecnología de los applets de Java, que permite, de nuevo, poder desarrollar una aplicación una única vez y ejecutarla tantas veces cómo se desee en un conjunto heterogéneo de ordenadores conectados a la Red.
Así, en Mayo de 1995 Sun lanzó oficialmente Java al mercado con el Java Development Kit (JDK) en su versión 1.02., es decir, un entorno de desarrollo y una implementación del lenguaje Java.  Este JDK fue ampliado  y mejorado (se subsanaron algunos problemas), dando lugar a la versión 1.1. De ahí se pasó a la siguiente, el SDK 1.2 (Software Development Kit), la cual, entre otras muchas características, incluía una colección nueva de clases y elementos para el diseño de interfaces gráficos. Surgieron seguidamente la versión, SDK 1.3 y, finalmente y actual, el SDK 1.4.
Cabe destacar en este punto la distinción entre la plataforma Java y las diferentes versiones JDK y SDK. El primero se refiere al lenguaje abstracto y a la especificación del mismo. Los segundos son, como ya hemos dicho, implementaciones que ha realizado Sun, así como un conjunto de herramientas que ofrece esta empresa para facilitar el desarrollo de aplicaciones.  Si nos fijamos en la plataforma, sólo ha habido dos versiones principales Java 1 y Java 2.  La segunda se introdujo coincidiendo con la llegada de el SDK 1.2.
Y finalmente, ya en 1999, se vuelve a cerrar el ciclo que lleva a Sun a desarrollar una versión de Java especialmente diseñada para dispositivos móviles: Java 2 Micro Edition, basada en una máquina virtual llamada KVM.  Este primera versión sólo contenía una única máquina virtual y un único API (inicialmente diseñados para Palm OS), hecho que puso de manifiesto la insuficiencia de esta solución para la gran variedad de dispositivos diferentes. De esta forma, en el año 2000, nació la primera versión de una configuración, es decir, el Connected Limited Device Configuration (J2ME CLDC 1.0).  Una configuración ofrece el API básico para programar dispositivos, aunque no aporta todas las clases necesarias para desarrollar una aplicación completa.  Por tanto, la primera configuración no tenía las herramientas necesarias para permitir a los desarrolladores escribir programas para el dispositivo Palm.  En julio de 2000 nació la primera implementación de un perfil, concretamente el llamado Mobile Information Device Profile (MIDP), aunque no estaba destinado a PDAs sino a teléfonos móviles y a paginadores.  A partir de este primer perfil, J2ME fue considerablemente aceptado por la comunidad de desarrolladores de dispositivos móviles, expandiéndose a una gran velocidad hasta nuestros días.
Por tanto, actualmente, la versión 2 de Java de Sun Microsystem contiene tres ediciones distintas:
  • Standard Edition (J2SE): entorno básico de Java. Ofrece un conjunto de clases  y APIs (Application Program Interface - Interfaz para Programas de Aplicación) que permiten desarrollar  y ejecutar aplicaciones clientes y servidoras, así como programas que se ejecuten en navegadores (applets).  Ya está en la calle el J2SE 5.0.
  • Enterprise Edition (J2EE): agrupa APIs Java y tecnologías que no están basadas en este lenguaje. Se aconseja para el desarrollo de aplicaciones distribuidas. 
  • Micro Edition (J2ME): específicamente diseñado para desarrollar aplicaciones para dispositivos embebidos y electrónicos, que tienen características peculiares ya que dos ediciones anteriores no son adecuadas para su utilización con ellos. Éstos dispositivos normalmente tienen una potencia limitada, posibilidad de conectividad a una red (normalmente sin cables) y poseen interfaces gráficos.
En la siguiente ilustración podemos ver gráficamente la relación entre cada una de las ediciones de Java y los tipos de dispositivos con que se podrían programar:
Ediciones de Java 2 y dispositivos.

Algunas diferencias que ofrece J2ME con respecto a J2EE, directamente derivadas de las condiciones en las que se va a hacer uso de esta edición, son las siguientes
  • Tipos de datos: J2ME no incluye los tipos float y double, ya que la mayoría de los dispositivos CLDC no tienen unidad de coma flotante debido fundamentalmente a que es una operación muy costosa.
  • Preverificación: La verificación del código en J2ME se hace fuera del dispositivo, con objeto de reducir la carga de la máquina.
  • Inclusión de los ficheros "descriptor" y "manifiesto" al empaquetar ficheros J2ME, conteniendo información sobre las aplicaciones que incluyen.
  • Nueva biblioteca gráfica adaptada a los dispositivos con memorias de poco tamaño y pantallas también pequeñas.
  • No existe un método main como entrada para la ejecución de la función. Éste se sustituye por el método "start app".
  • La recolección de basura se hace de manera manual y no automática como en el J2EE. Esta decisión se toma así para reducir la utilización de la memoria.

Introducción a J2ME Parte II

¿Es Java un lenguaje apropiado para programar dispositivos móviles?
Pero... ¿por qué Java para programar dispositivos móviles? Existe una razón fundamental para elegir este lenguaje para desarrollar nuestras aplicaciones en estos dispositivos especiales: Java nos da la posibilidad de escribir una vez el programa y poder ejecutarlo en cualquier tipo de plataforma sin tener que recompilarlo de nuevo (Write Once, Run Anywhere (WORA) - Escríbelo una vez y ejecútalo en cualquier lugar).  Esta independencia lo convierte en un firme candidato.  Otra razón es que en muchos casos es la única alternativa que dispone el programador, pues varios fabricantes han optado únicamente  por él para desarrollar aplicaciones. Pero también hay otras razones que aporta Java:
  • Extensión dinámica: la habilidad de un programa Java para descargar código en tiempo de ejecución, yendo a buscar nuevos ficheros de clases sustituyendo las ya existentes o simplemente añadiéndolos a las aplicaciones.
  • Seguridad: Java ofrece un entorno de ejecución seguro para programas con acceso a red. La máquina virtual de Java lleva a cabo una verificación estricta del código antes de la ejecución, asegurando que éste no trata de saltarse las protecciones impuesta por el lenguaje, utilizar punteros que accedan directamente a memoria o usar el objeto equivocado. 
  • Portabilidad: cada dispositivo dispone de un hardware con características peculiares que hace difícil encontrar un conjunto de bibliotecas que permitan desarrollar programas más o menos independientes del soporte físico. La máquina virtual de Java asegura esta portabilidad. 
  • Fiabilidad: teniendo en cuenta que algunos de los tipos de dispositivos que tratamos en este curso deben realizar tareas críticas, las aplicaciones que las implementan no deben fallar, ni tampoco ponerse fácilmente en manos de hackers. En ese sentido, Java es un lenguaje seguro, suministrando esa fiabilidad buscada. Para tal fin, requiere la obligación de la estructuración del código en paquetes, fuertes verificaciones de compilación y ejecución (fuerte tipado, comprobación de límites en vectores, pruebas de desbordamiento de pila,...), dispone un mecanismo eficiente para la gestión de excepciones y de memoria (elimina los punteros, asignación dinámica de memoria transparente al usuario y su posterior liberación -de esta manera se evitan errores).
  •  Código reutilizable: debido a la orientación a objetos de Java, se consiguen características como la facilidad en el desarrollo, la reutilización del código y la mayor calidad del código. 
Así, Sun Microsystems volvió a los orígenes de Java y desarrolló una nueva edición de la versión de Java 2: J2ME (Java 2 Micro Edition). Y una razón fundamental puede ser las características especiales que tiene estos dispositivos: un ejemplo es la cantidad de memoria que reservará un dispositivo de este tipo para una aplicación Java, las clases y la máquina virtual, ya que suele ser apenas pocos cientos de kilobytes. Con este espacio, las dos ediciones anteriores no son apropiadas, por lo que esta empresa pensó en la posibilidad de desarrollar una nueva totalmente adaptada a las características específicas de los dispositivos pequeños.

martes, 27 de abril de 2010

Introducción a J2ME Parte I

Introducción

En este curso vamos a estudiar la edición de la plataforma Java que Sun Microsystems ha diseñado específicamente para dispositivos móviles y embebidos: Java 2 Micro Edition (J2ME).  Aunque en esta introducción veamos una visión general de J2ME y su entorno, en este curso nos centraremos en el estudio de las herramientas y bibliotecas que ofrece J2ME para la programación de dispositivos específicos como teléfonos móviles y asistentes personales digitales.
La expansión de ordenadores personales en nuestro entorno hace que éstos sean ya una herramienta de trabajo muy necesaria y, por supuesto, de diversión. Hoy en día hay ordenadores en casi todas las casas, hecho originado fundamentalmente por la bajada de los precios de unos años a nuestros días.  Pero cada vez, los ordenadores son más potentes y nos dan muchas más posibilidades,  lo que hace que no sólo estén en el lugar de trabajo y en nuestro hogar, sino que nos los podamos encontrar en cualquier ámbito de nuestra vida: en el coche, en la lavadora, en la televisión,...
La tecnología está haciendo posible que se reduzcan también los tamaños de los ordenadores y que nos los podamos meter en el bolsillo y transportarlos sin dificultad alguna, como es el caso de los asistentes personales digitales (Personal Digital Assistant -PDA). Estos dispositivos son ordenadores con todo el significado de la palabra, pues disponen de capacidad de procesamiento y almacenaje de datos.
Las comunicaciones también han evolucionado velozmente. Ahora podemos bajarnos música de ordenadores situados en Nueva Zelanda en pocos segundos, o escribirnos en tiempo real con nuestro amigo de vacaciones en China desde nuestro ordenador. Pero ya no nos hace falta un cable para comunicarnos, ahora podemos hacerlo fácilmente mediante el aire, por radio, por ejemplo. Y esta tecnología está al alcance de todos: el teléfono móvil, que ya tiene prestaciones de un ordenador.
Por tanto, vemos que la evolución se centra en fabricar aparatos más pequeños, dotándoles de habilidad de comunicación y potencia de cálculo.  Independientemente del tipo de aparato, les requerimos que más o menos nos den las mismas prestaciones en cualquier momento. Pero eso es un problema para los desarrolladores, porque se les pide lo mismo, pero en sitios más pequeños cada vez.
Hasta hace poco, la programación de estos dispositivos se hacía en código máquina o en ensamblador. La razón básica era que se disponía de entornos de ejecución muy restringidos, por lo que el uso de lenguajes de programación de alto nivel era impracticable. Esto implicaba el hecho de tener que desarrollar completamente a medida, es decir, específicamente para el dispositivo, con el consiguiente esfuerzo y lentitud en los desarrollos.
El lenguaje de programación Java permitía escribir un programa una vez y poder ejecutarlo en multitud de ordenadores, con diferentes plataformas sin tener que compilarlo de nuevo. Esa es una gran ventaja y una característica muy deseable en el entorno de los pequeños dispositivos, por lo que se ha exportado esa filosofía a estos aparatos. Así, mediante J2ME se podrán escribir aplicaciones para una gran variedad de dispositivos diferentes.  Por supuesto, esta nueva edición de Java no es la misma que se utiliza para desarrollar aplicaciones distribuidas en Internet, por ejemplo, sino que es una versión reducida que se adapta claramente a las características físicas de los pequeños dispositivos.

Iniciación a J2ME Parte V (Final)

Nokia APIs
Nokia ha desarrollado unas APIs especiales, que por supuesto solo funcionan en sus propios teléfonos. Estas APIs incluyen soporte para gráficos y sonido, entre otras cosas. Aquí veremos rápidamente las características mas importantes de las APIs.
  • com.nokia.mid.ui

    • DeviceControl: vibracion y luz
    • DirectUtils: graficos
    • FullCanvas
    • DirectGraphics
  • com.nokia.mid.sound.Sound
Clase Sound
Los formatos de sonido que soporta son:
  • Tone-base (FORMAT_TONE)
Sound tono = new Sound(frecuencia, duracion);

tono.setGain(255);
tono.play(1);
  • Nokia Smart Messagin ring tone format
    (FORMAT_TONE)
Sound sonido = new
Sound(ringtoneByteArray,
Sound.FORMAT_TONE);
  • Digitized audio format (FORMAT_WAV)
    Para saber si el telefono soporta este formato:
Int[] formatos = Sound.getSupportedFormats();
La clase Sound viene con un listener para saber cuando ha cambiado el estado del audio, si ha dejado de tocar, ha empezado, etc.
tono.setSoundListener(this);

Public
void soundStateCahnged(Sound sonido, int evento)
{ }

DeviceControl
  • Luz de pantalla: DeviceControl.setLights(id de luz, nivel de intensidad);
  • Flases: DeviceControl.flashlights(duracion);
  • Vibracion:
    DeviceControl.startVibra(frecuencia, duration);
    DeviceControl.stopVibra();
FullCanvas
Un canvas que ocupa toda la pantalla. En este canvas no es posible implementar comandos. Así que es necesario tratar los comandos como teclas normales usando los eventos keyPressed() o keyReleased(). commandAction() no se usa.
DirectGraphics
Es una extensión de MIDP UI Graphics, que incluyes metodos extras para dibujar poligonos y rotar imágenes. Tambien soporta los colores ARGB (Alpha Channel) para hacer transparente una imagen, por ejemplo.
SMS APIs
Para MIDP 1.0, las APIs de Nokia para SMS solo funcionan en las Series 30. Ahora MIDP 2.0 implementa un listener para SMS recibidos y unas nuevas APIs. Desafortunadamente no las he probado nunca, así que no se funcionan o no en otros teléfonos, por ejemplo, Series 60.
Cualquier pregunta que tengas, publicala en el foro, ya que así, además de responderte a tí, responderé a todos los demás usuarios que estén interesados en el tema.