QUÉ ES UN DISPOSITIVO MÓVIL

Transcripción

1 QUÉ ES UN DISPOSITIVO MÓVIL La era de la información ha llegado, y con ella, las comunicaciones han mantenido la pauta en alta. Y para que exista comunicación, aparte de todos aquellos sistemas que la permiten, debe haber algunos en las manos de los usuarios, que les posibiliten el acceso a estos sistemas. Si bien existen gran cantidad de dispositivos que permiten este acceso (como los computadores, teléfonos y la televisión interactiva) las comunicaciones se han visto en la necesidad de ser ubicuas (es decir, de poderse usar en cualquier momento y lugar) por lo que una nueva gama de dispositivos han aparecido: Los dispositivos móviles. Para responder a la pregunta de qué son? solo debemos mirar a nuestro alrededor. Celulares, Ipods, Iphones, Blackberrys, Ipad, y cualquier otro tipo de artilugio comunicativo salta a la vista cuando estamos en una universidad, en un transporte, o incluso en nuestras casas. Y esa es la primera característica de un dispositivo móvil: Su portabilidad. Son aparatos que se usan para comunicarnos, y que son portables, que pueden llevarse de manera cómoda. Esta comunicación se da porque para estos dispositivos es posible conectarse a una red, sea de datos, o de telefonía, de manera permanente o intermitente. Esta conexión implica también cierta capacidad de procesamiento de información en el tiempo (al menos la que se envía y se recibe de la red), cierta capacidad de almacenamiento de la misma (sino, no sería posible su procesamiento en el tiempo, Dónde la tendríamos mientras la vamos procesando?) y aunque su función es la de la comunicación, pueden prestar servicios diferentes a este. Podemos resumir entonces que un dispositivo móvil es un aparato portable, con cierta capacidad de procesamiento y memoria, que tiene un acceso relativo a una red y cuyo propósito es el de comunicar principalmente, aunque puede tener algún otro propósito. 1

2 Si, hasta un reloj que se conecte a internet es un dispositivo móvil. Si mi MP3 lo hace, o se comunica con otro MP3, también lo es. Pero mi computador portátil, aunque hace todo esto, no es tan portable como un celular, por lo que no puede decirse que es un dispositivo móvil. Clases de dispositivos móviles Han aparecido una gran variedad de dispositivos móviles en el mercado, lo que ha hecho necesaria la aparición de estándares que agrupen la definición de dispositivos móviles. Estos estándares fueron definidos de la siguiente manera. 1. Dispositivo móvil de datos limitados: Son aquellos dispositivos que son pequeños y que poseen una pantalla tipo texto (sin gráficas, monocromática). Estos dispositivos generalmente tienen solo los servicios de SMS (mensajería) y WAP (Wireless acces protocol, o portocolo de acceso a internet). 2. Dispositivo móvil de datos básico: Dispositivos con una pantalla mediana, y con la posibilidad de navegar a través de un cursor por un menú visualizado en la pantalla. Prestan los mismos servicios que el dispositivo limitado, más otros como y un navegador básico de internet. En este grupo se pueden incluir los blackberrys y los smartphones o teléfonos inteligentes. 3. Dispositivos móviles de datos mejorados: Son aquellos dispositivos que poseen las mismas funcionalidades que el básico, pero poseen un sistema operativo autónomo y aplicaciones complejas como office móvil, entre otros. Aunque existen muchas variedades de dispositivos móviles, nos concentraremos en estos 3 grupos, e iremos cerrando la brecha mientras veamos las aplicaciones más comunes, hasta llegar a un dispositivo objetivo. 2

3 Características de los dispositivos móviles del mercado Los dispositivos móviles actuales se han vuelto muy robustos, presentando diversas funcionalidades como la lectura de código de barras, procesamiento de texto, almacenamiento de datos, reconocimiento facial, lectura de mail, e incluso, posibilidad de escoger diversas redes para transmitir sus datos. Sin embargo, las características de dichos productos pueden reducirse a un conjunto determinado de estructuras que permiten prestar los servicios anteriormente mencionados. Cuáles son estas características? Si bien existen muchas, solo nombraremos las que consideramos importantes para el desarrollo de nuestro curso: 3 Pantalla: Todo dispositivo móvil tiene una pantalla. Esta es la puerta de salida del aparato, la forma en la que se comunica con nosotros. Y estas pantallas pueden posibilitar solo la visualización de letras, imágenes sencillas, menús, y en los últimos años, fotos, videos y todo tipo de contenido digital. Incluso, se han visto pantallas táctiles que requieren un nuevo modelo de programación de aplicaciones, que son muy avanzadas para este curso. Teclas: Estas son las entradas del dispositivo, por donde accedemos a sus servicios o información. En los dispositivos clásicos, las teclas son un teclado numérico con algunas otras teclas de control. En casos actuales, las teclas han crecido hasta incluir un teclado alfanumérico completo (se le llama teclado qwerty ), y en los dispositivos más modernos, ha desaparecido para integrarse con la pantalla misma. Conexión a red: Para transferir la información que se procesa a otro dispositivo o a un operador, el aparato debe tener la posibilidad de conectarse a una red de datos, sea celular, de internet por demanda, de wifi, o de corto alcance.

4 Memoria: Para almacenar determinados datos (sean números de teléfono, nombres, o incluso los propios datos del programa que dirige el dispositivo), es necesaria una memoria en la que se puedan localizar para usarlos. Estas memorias pueden variar, desde valores realmente pequeños (5 o 6 Kbytes) hasta incluso varios Gigabytes con tarjetas de expansión (Existen Iphones con memorias de 16 Gbytes, y este valor seguirá aumentando con el tiempo) Capacidad de procesamiento: Si el dispositivo no puede procesar los datos que tiene guardados en la memoria, difícilmente podrá prestar servicios, o no lo hará en absoluto. Es por esto que los dispositivos, independiente de su uso, siempre tendrán una capacidad interna de procesamiento de información. Si vemos todas estas partes como un todo, podemos percibir que son, en suma, un computador de aplicación específica, ya que tiene puertos de entrada, de salida, memoria y capacidad de procesamiento. Esta es la imagen central que debemos recordar de un dispositivo móvil: Es un pequeño computador, que está diseñado para una o un número muy reducido de funciones. Plataformas usadas en los dispositivos móviles Actualmente existen 2 grandes plataformas para programar aplicaciones en dispositivos móviles, una desarrollada por Windows, y otra desarrollada por Sun Mycrosystems. La primera, desarrollada por Windows, se hace llamar.net framework y permite la escritura del código fuente del programa en diversos lenguajes de programación, que luego mediante el mismo framework, es traducido en un código intermedio que será, finalmente, el que se ejecutará en el procesador del dispositivo móvil. La segunda plataforma, se hace llamar J2ME, y es una pequeña porción del lenguaje JAVA, dirigida a dispositivos 4

5 con limitada capacidad de memoria y procesamiento, como lo son los dispositivos móviles. En el resto del curso, nos centraremos únicamente en esta plataforma. Freeware Versus Licencias Por qué JAVA y no.net para programación? La respuesta es corta y sencilla: JAVA es gratis. Al hacer una aplicación en.net, esta primero debe escribirse en un lenguaje de programación como Visual Basic,C#, J#, o cualquier otro. Pero para usarlo en el framework, debemos hacerlo a través de programas licenciados, como los incluídos en el paquete de Visual Studio. En contraste con esto, J2ME necesita solo el lenguaje JAVA para ser escrito (que es gratis) y ejecutarlo sobre la plataforma (que también es gratis). El hecho de que J2ME sea freeware, frente al.net que es licenciado, le ha dado un gran impulso; es tal la difusión que ha tenido el J2ME que en la mayoría de aplicaciones para dispositivos móviles con pantalla táctil, se lee en un Aplicaciones JAVA como un sinónimo de Aplicaciones para dispositivos móviles. Por el precio y cobertura, escogeremos esta plataforma. PLATAFORMAS DE JAVA JAVA es un lenguaje de programación lanzado por la empresa Sun Microsystems a inicios de los años 90 para controlar de manera robusta electrodomésticos, ya que era independiente de que plataforma ejecutara el código. También se empezó a usar en aplicaciones web y en aplicaciones independientes, que fueron llamados Applets 5

6 Debido a la aplicabilidad que ha encontrado este lenguaje de programación en todos los ámbitos, Sun ha desarollado diversas versiones para cada segmento tecnológico que lo usa. Es así como han aparecido 3 versiones que, si bien usan el mismo lenguaje, no se dirigen a los mismos fines. Dichas versiones son: Java 2 Enterprise edition (J2EE): Software dirigido al entorno empresarial. Se ejecuta no sobre un computador particular, sino sobre una red de computadores, por lo que debe integrar datos que provienen de entornos no compatibles. Debido a que las necesidades empresariales son diferentes a las de un usuario casero, se ha creado una extensión de JAVA para solucionar las necesidades de los empresarios. Java 2 Standar edition (J2SE): Es la edición original de JAVA, dirigida principalmente a computadores de uso personal, con herramientas básicas para desarrollar Applets, y con los aplicativos para realizar interfaces gráficas para los usuarios, redes, multimedia, etc. Java 2 Micro edition (J2ME): Esta es la versión de JAVA diseñada para ser ejecutada en pequeños dispositivos con limitadas capacidades de memoria y de procesamiento. Nociones Básicas de J2ME Bueno, queremos programar un dispositivo móvil, y ahora qué? Antes que nada, debemos conocer ciertas generalidades de JAVA para poder empezar a programar. Para poder empezar a crear un código que podamos ejecutar en un dispositivo móvil, debemos entender el proceso de compilación y las herramientas usadas para tal fin. Es por esto que agruparemos todas esas cosas en un entorno de 6

7 ejecución. Nuestro entorno de ejecución debe tener entonces los siguientes elementos: Una máquina virtual Una configuración Un perfil Unos paquetes opcionales. Qué son cada uno de estos elementos? Veamos: Una máquina virtual: Qué es una máquina virtual? Cuando escribimos un código o un programa para determinado sistema, las palabras usadas en el mismo no son entendidas por las máquinas. Es por esto que debe haber un intermediario o traductor, que convierta el código escrito por el programador, en un código que entienda la máquina. Esta es la labor de la máquina virtual. En java, la máquina virtual es llamada Java virtual machine o JVM, y esta máquina presenta una ventaja evidente con respecto a otros lenguajes: Independencia de la plataforma. Por qué? Porque cada dispositivo tiene su propia máquina virtual, lo cual hace que, no importa donde escribamos el código, siempre correrá en cualquier plataforma. Así, podemos decir que el código es independiente de la plataforma. Otro aspecto importante en las máquinas virtuales es la cuestión del tamaño. La JVM es una aplicación que se debe instalar en el dispositivo a programar, y por tanto, requiere un espacio en memoria. Las máquinas virtuales varían de tamaño de acuerdo a su funcionamiento, por lo que JAVA cuenta con diferentes máquinas virtuales para determinados dispositivos. 7

8 De qué depende el tamaño de una máquina virtual si todas hacen lo mismo? Acá debemos hacer una anotación de JAVA como lenguaje, que responde esa pregunta. Este programa, como muchos otros, trabaja con el concepto de librerías o paquetes. Dichas librerías contienen los comandos que se deben usar para hacer determinadas operaciones en el programa. Es así como una biblioteca puede contener todos los comandos para hacer operaciones aritméticas, otro paquete para hacer operaciones lógicas, etc. El traductor debe entender estos comandos al tener esas bibliotecas en su banco de memoria, y es por eso que determinadas JVM tienen tamaños diferentes, porque algunas soportan unas bibliotecas y otras no. La máquina virtual típica de JAVA mide unos 20Mbytes, lo cual es muy grande para muchos dispositivos. Es por esto que SUN creó su máquina más pequeña para dispositivos muy limitados, llamada la KVM. La K viene de Kilobyte, pues esta máquina pesa alrededor de Kbytes. Su tamaño la hace muy portable, rápida y pequeña, pero al mismo tiempo, limita bastante algunas características del lenguaje. Esto lo veremos con más detalle luego. Existe otra máquina virtual, llamada la CVM (Compact virtual machine) que ha sido creada para dispositivos de mayor gama, por lo que soporta las mismas prestaciones que la KVM, aunque posee mayor cantidad de librerías. Configuración: Una configuración se define como el número mínimo de APIs de Java que permiten desarrollar aplicaciones para diferentes dispositivos. Y, qué es un API? Una API es, simplemente, una interfaz (API: Aplication Programming Interface). Esta interfaz contiene un conjunto de funciones y procedimientos que le permiten a una biblioteca ser usada por otro programa, siendo una especie de intermediario entre la biblioteca y el programa que usa la aplicación. Un ejemplo particular es la posibilidad de escribir Hola en la pantalla de un computador. Puede, mediante lenguaje ensablador (el lenguaje que entienden 8

9 todas las máquinas), indicar 1s y 0s en ciertas partes de la memoria del computador, y luego volcar esta memoria en la pantalla para observar la palabra deseada. O también puede, mediante una aplicación (API), escribir en html la orden de mostrar la frase Hola, y la misma se podrá observar desde cualquier navegador de internet. En JAVA existen 2 configuraciones típicas, la CDC y la CLDC. Veamos cada una: CDC (Conected device configuration): Es la configuración dirigida a dispositivos con cierta capacidad computacional. Usa la CVM como máquina virtual, que es muy similar a la máquina virtual usada por J2SE. Los paquetes que posee esta configuración se pueden observar a continuación: Cada uno de estos paquetes son las librerías que permite la CVM usar a través de las APIs correspondientes. CLDC (Conected limited device configuration): Es la configuración dirigida a dispositivos con muy pocas capacidades de procesamiento, y usa la 9

10 máquina KVM. Las librerías admitidas para esta configuración son las siguientes: Perfiles: Digamos que tenemos un conjunto de dispositivos que sirven para cocinar. Algunos son muy básicos tecnológicamente, con temporizadores y opciones sencillas. Otros, mucho más complejos, permiten guardar configuraciones propias, como estilos de cocina, temperaturas secuenciales, tipos de platos a cocinar, entre otras cosas. Si bien estos dispositivos tienen un nivel tecnológico distinto, todos cumplen con un mismo propósito: cocinar. Esto hace que aplicaciones como la posibilidad de conectarse con otros dispositivos, o aplicaciones para dibujo, para tipologías de letras y otras, no sean muy necesarias en este tipo de dispositivos. Esto, en suma es un perfil : Un conjunto de APIs 10 que se encuentran orientados a determinado tipo de actividades o tareas. A través de un perfil, se puede identificar la funcionalidad de un dispositivo, pues las APIs que contiene lo hacen pertenecer a un grupo de dispositivos con una aplicación similar. Mientras que un perfil define las características de un dispositivo predeterminado, una configuración lo hace pertenecer a una familia de dispositivos. Esto significa que cuando nos proponemos la creación de una aplicación, tenemos tanto las APIs de perfil como las de configuración. Acá lo importante es que los perfiles no son aislados, sino que dependen primordialmente de la configuración. Es decir, una configuración carece de funcionalidad si no tiene asignado un perfil determinado. Podemos decir

11 entonces que un perfil es un conjunto de APIs que dotan a una configuración de una utilidad y una funcionalidad. Este conocimiento nos da las bases para saber cómo es un entorno de ejecución de Java Micro Edition. Sabemos que cada dispositivo debe tener una máquina virtual en su memoria que traduzca el código JAVA en lenguaje de máquina. Sabemos que determinados dispositivos soportan algunos tipos de máquinas virtuales dependiendo de sus capacidades de hardware. Que los dispositivos con limitadas capacidades de hardware deben usar la KVM por su tamaño, y que dispositivos con mayores prestaciones pueden usar la CVM. Ya sabemos también que sobre cada máquina virtual se debe incorporar una configuración específica: la CDC se configura sobre CVM y la CLDC se configura sobre la KVM. Esto mismo sucede con los perfiles. Hay perfiles que solo pueden ser ejecutados sobre la CDC y otros sobre la CLDC. Veremos entonces cuáles son estos perfiles y cuáles son las características de cada uno de estos perfiles. Para entender la configuración de capas del entorno de ejecución, vale la pena estudiar el siguiente diagrama: 11

12 Ahora, veamos con más detenimiento cuáles son los perfiles que se ejecutan sobre las configuraciones, y cuáles son sus características básicas Perfiles de la configuración CDC: Foundation profile Personal profile RMI profile. Perfiles de la configuración CLDC: PDA profile Mobile information Device Profile (MIDP) En este caso es necesario anotar algo: si bien podemos construir un perfil sobre otro perfil en un dispositivo, dicho dispositivo solamente puede tener una configuración. Veamos ahora los perfiles: Foundation profile: Este perfil está dirigido a dispositivos que, aunque usen las características robustas de la configuración CDC, no requieren de su interfaz gráfica. Es por esto que el conjunto de paquetes que contiene este perfil excluyen los paquetes usados por java para crear ventanas, interfaces gráficas, entre otras cosas. Algunos aparatos que usan este perfil son, por ejemplo, los decodificadores de televisión digital. Si alguno de estos aparatos necesitara una interfaz gráfica (también llamada GUI o graphic user interface ) necesitaría usar otro 12

13 perfil. Los paquetes que contiene este perfil se muestran en la tabla siguiente. Personal profile: este perfil es el encargado de proporcionar un entorno gráfico completo y funcional a un dispositivo. Le proporciona capacidades web, soporte de Applets de java y, sobre todo, es un entorno con soporte gráfico AWT, que permite mediante coordenadas, dibujar objetos en la pantalla del dispositivo. Para la ejecución de este perfil, debe implementarse anteriormente el foundation profile. Los paquetes que contiene la personal profile se muestran en la siguiente gráfica: 13

14 RMI profile: Este perfil es un subconjunto de un perfil de J2SE, con diversas limitaciones debido a las capacidades computacionales de los dispositivos móviles que implementan la CVM. Debido a que esa configuración no está en los objetivos del curso entenderla, simplemente comentaremos que la RMI profile es un subconjunto del perfil RMI para J2SE, que necesita el foundation profile, y que no posee las siguientes propiedades del RMI de J2SE: o Java.rmi.server.disableHTTP. o Java.rmi.activation.port. o Java.rmi.loader.packagePrefix. o Java.rmi.registry.packagePrefix. o Java.rmi.server.packagePrefix. Ahora veamos con más detenimiento los perfiles de la configuración CLDC. Se insta al lector a prestar especial atención a estos perfiles, en especial al último, pues en él basaremos el estudio del resto de nuestro curso. 14

15 PDA profile: Como su nombre lo indica, es un perfil construido para PDAs, sobre todo las de gama baja, como palms con una pantalla y un puntero. En sus inicios, soportaba una resolución de al menos pixeles de pantalla y la presencia de un puntero, todo esto sobre CLCD. Actualmente es una configuración dirigida al manejo de información personal, como agendas, y accede al calendario y a la base de datos de contactos para hacer aplicaciones con ella. Mobile Information Device Profile (MIDP): Este es nuestro perfil más importante. La primera configuración definida para J2ME fue la CLDC, y sobre esta, el primer perfil generado fue el MIDP. Esto hace que sea uno de los perfiles más completo y desarrollado hasta la fecha. Está dirigido a un conjunto de dispositivos con características muy específicas, que nombraremos a continuación: o Reducidas capacidades de memoria y de computación o Capacidades gráficas muy limitadas (a lo sumo un display de 96x54 pixeles, sin colores) o Conectividad limitada (aproximadamente de 9600bps, Bits per second o Bits por segundo) o Pocos datos alfanuméricos permitidos. o Al menos 128 Kb de memoria no volátil (es decir, memoria que no se borra cuando es apagado el dispositivo, También es conocida como ROM) para instalar los componentes MIDP o Al menos 8Kb de memoria no volátil para datos de aplicaciones o 32 Kb de memoria volátil (aquella que se borra cuando el dispositivo es apagado. También es conocida como RAM) para la pila JAVA. 15 A partir de estas características, podemos definir un conjunto de dispositivos entre los cuales podemos incluir a los teléfonos móviles, los

16 buscapersonas, PDAs de gama baja con conectividad, entre otros dispositivos móviles. Este perfil determina las capacidades de los dispositivos en los que está instalado. Estas capacidades están relacionadas directamente con las APIs que especifica, y son: - Semántica de las aplicaciones - Interfaz con el usuario - Almacenamiento repetitivo o persistente. - Conexión y trabajo entre dispositivos en red. - Temporizadores de aplicaciones Los paquetes que posee esta configuración se pueden observar en la siguiente tabla: 16 Al crear una aplicación usando un API, la llamamos Applets. Estos applets son los usados principalmente como aplicaciones estándares de java, y se pueden descargar de muchas páginas. Si en nuestro computador necesitamos un programa en java que haga determinada labor, usamos o programamos un Applet. En los dispositivos móviles, es diferente. Por similitud, las aplicaciones creadas con MIDP son llamadas MIDlets. Es así como podemos decir que un MIDlet es una aplicación creada usando el perfil MIDP sobre una configuración CLCD. Como el

17 perfil de los dispositivos móviles más usados (los celulares) cabe en este perfil de java, de ahora en adelante nos centraremos en el perfil MIDP, pero sabiendo que, para crear una aplicación en otro dispositivo, solo basta con configurar la máquina JAVA, el perfil y la configuración apropiada, y empezar a programar la aplicación. J2ME Y LA COMUNICACIÓN Una de las características de los dispositivos móviles que se soportan en la configuración MIDP es que deben tener una conexión limitada. Es cierto que muchos dispositivos tienen conexión similar a la explicada en el perfil, como los GPS, y algunas palms, pero no se puede negar que los dispositivos que más provecho le están sacando a las comunicaciones son los celulares. Esta es otra de las razones por las cuales nos centraremos en el desarrollo de aplicaciones para celulares, porque últimamente estos dispositivos han tenido un desarrollo vertiginoso en cuanto a aplicaciones que usan la comunicación (no solo de voz) para mejorar, por ejemplo, la productividad de las empresas, o para simplemente entretener a los usuarios de estos dispositivos. Cuáles son los protocolos de comunicación que se han creado y que han sido aplicados en MIDlets de java? Cómo pueden afectar estos protocolos el desarrollo de la tecnología J2ME? Veamos entonces los protocolos de comunicación que han surgido para entender el efecto que han tenido sobre la tecnología JAVA. Anteriormente, los celulares se habían creado con el único propósito de comunicar a las personas entre sí. Eran una extensión de la telefonía inalámbrica, convirtiéndola en ubicua para todos los individuos. Tal vez la primera aplicación vital que dio pie a la creación de toda una gama de protocolos y librerías, fue la agenda telefónica. Tener una agenda, implicaba ingresar datos al celular, que éste los almacenara incluso luego de apagar el 17

18 dispositivo, y que el mismo celular los desplegara en pantalla al buscarlos a través de un navegador. Esta interactividad básica dio pie a los programadores para pensar en aplicaciones más complejas que usaran los datos del celular con algún propósito diverso. Agendas con varios teléfonos para una misma persona aparecieron, y algunos incluso daban la posibilidad de incluir tonos particulares a cada nombre. Luego surgió la necesidad de comunicación de datos. Mi celular, con memoria para almacenar contactos, ya tenía más de la necesaria, y por tanto, esta misma se podía aprovechar para personalizar el celular y hacerlo una herramienta mucho más propia. Sin embargo, De dónde puedo adquirir la información que deseo, y sobre todo, cómo puedo conectarme al lugar en el que se encuentra esa información? Viendo los operadores de telefonía celular esta oportunidad como una posibilidad de ampliar sus negocios, impulsaron la consolidación de estudios universitarios en redes inalámbricas y protocolos de comunicación inalámbricos. Es así como nace la primera tecnología de comunicación, la tecnología WAP. WAP es la sigla de Wireless Application protocol, o protocolo de aplicación inalámbrica. Este protocolo surgió para dotar a los celulares de la posibilidad de conectarse con un servidor remoto, o varios servidores remotos, con el objeto de intercambiar información entre el cliente y servidor. Esta conexión se hacía a través de un elemento que ya había estado siendo trabajado y actuallizado en computadores de escritorio: Un navegador. Se dotó entonces de un navegador básico al dispositivo móvil con el objeto de conectarlo con el servidor. Obviamente este desarrollo requirió todo un trabajo más profundo en protocolos de comunicación, como un traductor entre el código HTTP del internet y las peticiones WAP, la creación de una puerta de enlace, o Gateway que sirviera como intermediaria entre la red y el celular, entre otras cosas. Aunque WAP fue un gran avance en cuanto a conectividad, no resultó ser el mejor medio de conexión, ya que la navegación no era para nada amigable, la introducción de páginas de internet era demasiado incómoda por el usuario, y el costo de navegación se daba por tiempo, a lo que se podía 18

19 sumar el problema de que, si la red estaba muy saturada y uno estaba conectado, uno no intercambiaba información pero la factura de cobro llegaba a la orden del día. Finalmente, podemos anotar que, el costo de la tecnología era muy elevado para la capacidad de conectividad que tenía la plataforma, que en conclusión, no era la mejor. Aprovechando la plataforma usada para WAP, otra nueva tecnología tomó auge, la SMS. La SMS o Short Message System, es una tecnología que permite enviar mensajes de texto (o cadenas de caracteres) entre los Gaps o huecos usados para transferir la información de la red. Esta comunicación resultó ser muy rápida y muy barata en comparación con la WAP. También, al poder enviar y recibir mensajes de manera rápida, se gestaron las aplicaciones de mensajería instantánea o Chat. Java permitió crear plataformas que aprovecharan la tecnología SMS para hacer aplicaciones de chat que se instalaron en los teléfonos celulares, y que ahora son la base de la comunicación por Blackberry. La comunicación siguió tomando auge, y los operadores implementaron tecnologías que aumentaban tanto la banda como la velocidad de las conexiones, generándose así tecnologías conocidas como generaciones. La generación 2 y la 2`5 son conocidas por otras 2 nuevas tecnologías de comunicación, como lo son la GSM y la GPRS Mientras que GSM es una conexión telefónica que permite el intercambio de datos entre clientes, la comunicación GPRS se basa en una red únicamente de datos, que mantiene una conexión entre el servidor y el cliente, en la que se corrige el error de WAP, y se le cobra a los navegantes por cada Kbyte transferido, en vez del cobro por tiempo de navegación. Actualmente nos movemos en plataformas de conexión que se basan en la 3ra generación, con tecnologías como UMTS, EDGE y 3.5g. En Japón, por ejemplo, se está 19

20 probando una plataforma montada sobre la 4ta generación, que permite la transmisión de datos, voz y video en tiempo real a través del propio celular, vislumbrando la videoconferencia como la tecnología del futuro en la comunicación, y a JAVA como una de las herramientas más importantes para aprovechar las capacidades de conectividad de las redes de telefonía celular. Otras de las tecnologías de comunicación, no basada en cliente - servidor sino en cliente cliente, son las conocidas como redes PAN (personal area network) y WAN (wireless area network), creadas por tecnologías usadas actualmente por muchos celulares: La tecnología bluetooth, la Wifi y la IRDa. La bluetooth es una tecnología que permite transferencias de información entre dispositivos móviles en un radio de metros, y que permite crear redes adhoc, o redes temporales. La Wifi permite conectar un celular a internet con velocidades similares a las de un computador personal, y finalmente, la IRDa, o red infrarroja, permite transferir información entre 2 elementos que posean este protocolo. Todas estas tecnologías favorecen, entonces el uso y distribución de aplicaciones en JAVA y, sobre todo, MIDlets en JAVA. OTA Cuando uno necesita descargar una aplicación para un dispositivo móvil, gracias a las redes existentes en la actualidad, lo primero en que se piensa es en una descarga de internet. Esto debido a que la tecnología actual se basa en el medio inalámbrico para transmitir contenidos (a pesar de que existan otro tipo de medios de transmisión, como los cableados, y los inalámbricos dirigidos). Este medio que permite garantizar la descarga de contenidos es llamado OTA (Over The Air), es decir, OTA es el nombre que se le da al medio aéreo necesario para descargar contenido. 20

21 A través de este medio, e bajan los componentes de una aplicación para dispositivos móviles. Cuáles son esos componentes? Una aplicación en J2ME tiene 2 componentes fundamentales para su funcionamiento: Un archivo con extensión.jar, que contiene la aplicación como tal, y un archivo.jad, que contiene algo similar a un manual de la aplicación, es decir, contiene información sobre la misma (No debemos confundir estos archivos. Pongamos un ejemplo: Digamos que a su casa llega un paquete de un familiar suyo, un televisor empacado. El televisor como tal, es equivalente a la aplicación, y es el archivo.jar. El manual de instrucciones, que dice la marca del televisor, el tamaño, las especificaciones técnicas y de más, es el archivo.jad. A este archivo.jad se le llama Descriptor ). Para descargar los MIDlets Over the air, se debe seguir un proceso organizado de pasos, y se deben tener en cuenta unos requerimientos específicos, tanto funcionales como técnicos de los dispositivos que llevan a cabo estas descargas. Veamos entonces cuáles son estos requerimientos. Requerimientos funcionales Si voy a descargar un MIDlet OTA, mi dispositivo debe tener alguna herramienta que me permita encontrar el MIDlet buscado. Los dispositivos cuentan con varias herramientas para esto. Anteriormente habíamos comentado que la comunicación WAP requería un navegador que sirviera como enlace (Puerta de enlace) entre el celular y la red. Pues este navegador WAP es una de las opciones con las que cuentan los dispositivos móviles para poder descargar los MIDlets. Otros celulares tienen aplicaciones propias, diferente de los navegadores WAP, para identificar y descargar MIDlets (anteriormente, los celulares contaban con una herramienta que le permitía al dispositivo conectarse con una base de datos del proveedor de MIDlets, que generalmente era el operador, y a través de un menú en pantalla, descargar las aplicaciones deseadas. Esto ha venido desapareciendo, ya que los celulares actuales poseen altas capacidades y pueden ejecutar navegadores complejos 21

22 como el Internet Explorer, Google Chrome, entre otros). También, como lo habíamos comentado antes, no todos los medios de transmisión de información deben ser inalámbricos o relacionados con el internet. También se pueden usar cables de datos, redes Ad Hoc (BlueTooth), redes infrarojas, etc. Sin embargo, siempre debe haber un software que permita manejar la descarga y el ciclo de vida de los MIDlets. Este software es llamado el gestor de aplicaciones o AMS (Application Management Software) Lo anterior significa que nuestro dispositivo móvil, encargado de bajar un MIDlet, debe tener la posibilidad de incorporar un AMS que localice el fichero y lo baje a la memoria no volátil del móvil. Qué pasa si, para descargar el fichero se debe usar contraseña? Pues que el gestor de aplicaciones debe permitir enviar información a la plataforma donde se encuentra la aplicación, con el nombre de usuario y la contraseña pedida. Para el envío de información OTA, se deben usar protocolos específicos de comunicación de datos, como HTTP 1.1, pero eso no lo abordaremos en este curso. Basta con saber que la aplicación debe enviar mensajes si el servidor lo requiere. Sin embargo, con el MIDlet en el dispositivo, no hacemos nada, debemos instalarlo y, luego de eso, ejecutarlo en nuestro celular. Y si nos aburrimos de la aplicación? Pues el dispositivo móvil debe darnos la posibilidad de eliminarlo. Es así como podemos definir las especificaciones de un dispositivo móvil con perfil MIDP, ya que el mismo debe cumplir los siguientes requerimientos: 22 a) Localización de archivos JAD y JAR en la red a través del AMS b) Descarga del JAD y el JAR desde un proveedor de servicios, un servidor, u otro dispositivo con la aplicación (sea por medio inalámbrico o alámbrico) c) Envío de nombre de usuario y contraseña en caso de que sea necesario. d) Instalación del MIDlet descargado.

23 e) Ejecución del MIDlet instalado f) Borrado o desinstalación del MIDlet instalado. Veamos ahora con más detenimiento cada uno de estos requerimientos: a. Localización de la Aplicación Lo primero que un dispositivo móvil debe hacer es localizar un MIDlet a través de la AMS. A este proceso se le llama descubrimiento. El descubrimiento se realiza cuando el navegador muestra al usuario el enlace en la red que permite bajar el MIDlet deseado, y que una vez seleccionado, permite descargar e instalar el MIDlet. Recordemos que un MIDlet está compuesto por un archivo.jar y por un.jad. Si el enlace que encontramos en la red es un.jar, el archivo y su URL se envían al AMS para empezar el proceso de instalación del MIDlet. Sin embargo, si el enlace está referido a un archivo.jad, se deben llevar a cabo los siguientes pasos: A través del navegador, se transfiere el archivo.jad y su dirección URL al AMS, que es el que empieza la instalación del MIDlet. Acá hay que hacer una anotación importante: No todos los MIDlets pueden ser instalados en cualquier equipo, por lo que el AMS debe determinar si el MIDlet bajado puede ser tanto instalado como ejecutado de manera satisfactoria en el dispositivo móvil. El descriptor, escrito en JAVA, debe ser entendido por el AMS, que no necesariamente es una aplicación de JAVA. Es por esto que para ser entendido, debe ser traducido a formato Unicode antes de ser usado. Veamos algo en este punto: un archivo.jad es un conjunto de datos relacionados con el.jar, por lo que podemos decir que el.jad es una 23

24 clase. Todas las clases tienen atributos de clase, y estos atributos, en la.jad, deben ser compresibles de acuerdo a la sintaxis del perfil MIDP. Como el perfil MIDP es el que corre el MIDlet, los atributos requeridos por este perfil deben estar presentes en el.jad para que pueda usarlo. Cuando la dirección llega a la AMS, se inicia la instalación del MIDlet. Sin embargo, por seguridad, el AMS debe tener la opción de indicarle al usuario si de verdad desea instalar dicha aplicación. Y no solo eso, debe estar en capacidad de saber si existe una versión similar o desactualizada del mismo MIDlet instalado en el equipo, o si éste tiene problemas para instalar MIDlets por falta de memoria. De esta manera, el AMS puede ejecutar una herramienta para liberar memoria, e instalar la aplicación correspondiente. b. Instalación del MIDlet Ya tenemos el.jad en nuestro AMS con la respectiva dirección URL de donde se descargará el MIDlet para ser instalado, ahora Qué sigue? La etapa de instalación. Esta etapa no es intervenida por el usuario, ya que la genera internamente el dispositivo. Sin embargo, se deben tener en cuenta varios mensajes que pueden salir en el proceso de chequeo que se genera al instalar el MIDlet. Primero, debemos entender que la instalación de un MIDlet comprende el estado en el que el MIDlet es descargado y puede ser usado por el cliente. También debemos saber que un MIDlet puede estar dentro de un paquete, y que este paquete puede tener diversidad de MIDlets internos. Es decir, cuando tenemos la dirección URL y deseamos bajar una aplicación, esta puede estar compuesta de varios MIDlets. El AMS debe indicar esta situación y debe darle la posibilidad al usuario de cancelar el proceso de instalación en cualquier momento, dejando al dispositivo como se encontraba antes de pasar por el proceso de instalación. Qué hace el AMS cuando se procede a instalar una 24

25 aplicación? Verificar si el paquete contiene varios MIDlets internos e indicarle al usuario el proceso de instalación de los componentes, el número de componentes a instalar, y la opción de cancelar la instalación. También debe llevar a cabo las siguientes actividades: Si el archivo que se descargó inicialmente fue el.jad, la URL de la que se descarga el MIDlet, contenida ahora por el AMS (recordemos que ya hallamos la aplicación a instalar, y en ese proceso, se le asigna una URL al AMS para la instalación de la aplicación) debe coincidir exactamente con la URL que posee el.jad Si el servidor pide nombre de usuario y contraseña para autentificar al usuario, el AMS debe enviar las credenciales correspondientes (los datos correspondientes) El MIDlet debe ser chequeado para saber si se puede instalar en el dispositivo móvil. Este chequeo se extiende a todo el proceso de instalación, ya que pueden surgir una serie de errores que no permitan que el MIDlet se instale. El AMS debe indicar todos estos errores durante el proceso de instalación de la aplicación. Cuáles son esos errores? Veámoslos: o Si no hay memoria suficiente para instalar el MIDlet, se devuelve el código de estado 901 o Si el.jar no se encuentra disponible en la URL que contiene el JAD,, se develve el código 907 o Si al descargarse el.jar, este no coincide con el descrito en el.jad, se devuelve el código 904 o Si no se pueden extraer los archivos necesarios para instalar el.jar, se devuelve el código 907. o Si los atributos del.jad no coinciden con los que tiene el.jar, se devuelve el código de error

26 o Si no se puede llevar a cabo la autenticación del usuario (nombre de usuario y contraseña) se devuelve el error 909 o Si falla por un motivo diferente al cualquiera de los anteriores, debe devolver el error 911. o Si mientras se descarga el MIDlet para instalarlo, se pierde la conexión a internet, debe devolver el error 903 La instalación finaliza en 2 casos: cuando tenemos el MIDlet exitosamente instalado en nuestro dispositivo móvil, o cuando ha ocurrido un error irrecuperable y no se ha podido instalar la aplicación. Puede darse el caso en que estemos instalando un MIDlet y ya tengamos una versión previa del mismo. En ese caso, decimos que estamos actualizando el MIDlet correspondiente, ya que estamos pasando de una versión anterior a una versión más reciente del mismo. El AMS debe indicarle al usuario si la versión que desea instalar es menor, igual o mayor a la instalada en el dispositivo, y debe obtener verificación del usuario a la hora de ser instalada. Todo programa a instalar posee una firma digital que indica su autenticidad y su validez como archivo oficial y no modificado por terceros. Los archivos con firmas digitales priman sobre aquellos que no la tengan, y nunca un dispositivo móvil debe permitir instalar un MIDlet sin firma como reemplazo de una aplicación que si la tenga. c. Ejecución del MIDlet Vamos a ejecutar el MIDlet en nuestro equipo. Al momento de ejecutarlo, lo primero que se debe llevar a cabo es la carga de las clases referentes al perfil CLDC y la configuración MIDP. Recordemos que estamos cargando una aplicación de JAVA en un dispositivo móvil, y esto requiere tanto el perfil como la configuración para poder ser ejecutada. Es por esta razón que un dispositivo 26

27 debe tenerlas incluidas, porque si no las posee, no puede ejecutar ningún MIDlet. Y recordemos también que dijimos que un paquete o una aplicación pueden tener diversos MIDlets. En caso de tenerlos, el dispositivo debe permitirle al usuario escoger el MIDlet que desea ejecutar. d. Eliminación del MIDlet. El proceso final que se puede llevar a cabo con un MIDlet es su eliminación. Para hacerlo, el usuario debe elegir la posibilidad de borrar la aplicación seleccionada. Cualquier cosa que ocurra en el proceso de instalación debe ser indicada al poseedor del dispositivo móvil, y en caso de que la aplicación tenga varios MIDlets incorporados, debe indicársele al usuario que todos quedarán eliminados. Hemos visto hasta ahora todos los pasos por los que un MIDlet puede pasar a través de un dispositivo móvil. Ahora, veremos cuáles son las herramientas que se necesitan para construir los MIDlets a diseñar, pero antes, debemos ver cuál es el proceso de creación general de un MIDlet. Proceso de creación de un MIDlet. Todos los MIDlets a desarrollar llevan a cabo casi el mismo proceso de creación, con algunos casos particulares. Veremos entonces cuales son los pasos que hacen parte de ese proceso: 1. Desarrollo: en este estado, creamos el código en JAVA de nuestro MIDlet. 2. Compilación: Nuestro código es traducido a lenguaje de máquina a través de un compilador J2SE 27

28 3. Preverificación: Examinamos el código de JAVA para observar si no se viola ninguna restricción de seguridad de la plataforma en la cual se va a ejecutar (J2ME). 4. Empaquetamiento: Se crea el archivo.jar y el.jad de nuestra aplicación. 5. Ejecución: Se monta el MIDlet en un simulador o en un dispositivo móvil para probar su funcionamiento. 6. Depuración: Al observar la ejecución del MIDlet, pueden observarse fallos en su funcionamiento, la depuración consiste en eliminar esos fallos para corregir nuestra aplicación. El empaquetamiento y la preverificación, al evaluarse violaciones de seguridad en la plataforma J2ME y crearse archivo.jar y.jad, son pasos exclusivos en el desarrollo de MIDlets. El resto de pasos, son generales para la creación de cualquier aplicación en cualquier otro programa o lenguaje de programación HERRAMIENTAS DE DESARROLLO Cómo se crea un MIDlet?, básicamente a través de 2 formas: - A través de líneas de comando. Esto significa que copiaremos el código sin ningún tipo de ayuda adicional, aparte de la prestada por el compilador para traducir el código. - A través de un entorno visual. Esto implica el uso de diversas herramientas que facilitan la creación de MIDlets, como veremos más adelante 28

29 En nuestro caso, usaremos un elemento visual para ejecutar nuestros MIDlets. Este elemento se llama Dispositivo MID (Móbile information device). Esto significa que no ejecutaremos nuestros códigos directamente en máquinas físicas, sino en un simulador que ejecutará nuestra aplicación. El emulador a usar puede ser tanto un dispositivo genérico como un modelo MID específico (Por ejemplo, si queremos desarrollar aplicaciones JAVA para el Iphone, debemos bajar un emulador que nos permita ejecutar nuestras aplicaciones en este dispositivo.) En este punto, entraremos de lleno en la forma de crear un MIDlet, y nos iremos por ambas formas de construcción, abordando una primero, y luego la otra. Se debe tener muy en cuenta el proceso de creación de un MIDlet, porque llevaremos a cabo manualmente cada uno de esos pasos. En este caso, abordaremos el método de línea de comando INSTALACIÓN DE COMPONENTES. Qué componentes necesitamos para el desarrollo en línea de comando? Requerimos básicamente los siguientes: a) Un editor de texto para copiar el código del MIDlet. b) Un compilador estándar de JAVA. El compilador es proporcionado gratuitamente por JAVA en la siguiente dirección: c) Las APIs de la configuración CLDC y del perfil MIDP que se pueden descargar de la página 29

30 html En el enlace anterior del SDK de JAVA, bajamos el archivo j2sdk-1_4_1_04- windows-i586.exe (pueden variar las versiones. Actualmente existe una versión mucho más moderna, pero trabajaremos con esta) y lo instalamos. Suponemos en este momento que, como se pide en los requerimientos del curso, el aprendiz tenga conocimientos en JAVA y manejo de computadores de manera intermedia, ya que se llevará a cabo un procedimiento que, de no realizarse correctamente, puede desconfigurar el acceso a algunos programas del sistema operativo. NOTA: Si no posee conocimientos de JAVA y/o de computadores, ASESÓRESE DE ALGUIEN QUE SI LOS TENGA para llevar a cabo lo siguiente. Cuando descarguemos el archivo, le damos doble click y lo instalamos en una carpeta específica del computador. Esta ruta en la que fue instalado, debe copiarse en un documento de texto o en el block de notas. Luego de instalado el programa, añadiremos esta ruta a nuestro Path. 30

31 Qué es el Path? Esta es una variable del sistema que contiene la ruta de acceso a los programas que el usuario del computador usa con más frecuencia. Es por esto que a veces podemos escribir el programa que necesitemos en la barra de direcciones, y Windows inmediatamente lo encuentra, gracias a la información del Path. Existe otra variable, llamada el Classpath, que contiene la información de donde el JDK (Java development kit, o kit de desarrollo de JAVA) o en nuestro caso el SDK, debe buscar los archivos a ejecutar o compilar. Necesitamos cambiar nuestro Path para poder ejecutar el SDK de JAVA de manera correcta. Cómo lo cambiamos? Realizando los siguientes pasos: a. Abrimos el Símbolo del sistema, al que se puede acceder por la carpeta Accesorios presente en la barra de inicio de Windows (Inicio/todos los programas/accesorios/símbolo del sistema) 31

32 b. Escribimos lo siguiente: Path, quedando más o menos así C:/ path Este comando te muestra los accesos directos presentes en la variable. c. Buscamos el archivo autoexec.bat y lo abrimos con un procesador de texto (Block de notas o Wordpad), poniendo la dirección que guardamos anteriormente donde instalamos el SDK, separada por un ;. Es recomendable ponerlo al inicio de las direcciones, para evitar conflictos con programas que queramos ejecutar en el SDK y que se llamen igual que algunos contenidos en las otras direcciones del Path. d. Descargamos los API de la configuración MIDP y CLDC, las descomprimimos en una carpeta específica. Esta ruta también debe agregarse al Path e. Creamos 2 variables de entorno a través del comando SET en el símbolo del sistema. Una de ellas se debe llamar JAVA_HOME, con el valor de la dirección donde se instaló el SDK, y otra llamada MIDP_HOME, con el valor de la ruta donde se descomprimieron las APIs correspondientes. Para saber si llevamos a cabo correctamente estos pasos, hacemos lo siguiente: - Abrimos el Símbolo del sistema y escribimos Java Version Y debe aparecer algo similar a lo siguiente: 32

33 - Luego escribimos: Midp version Viendo algo como lo siguiente Con esto claro, procedemos a llevar a cabo las fases de desarrollo de una MIDlet por línea de comando 33

34 Fases de Desarrollo Recordemos que el desarrollo de un MIDlet tiene varias partes, como lo vimos en el apartado superior. Veamos cómo se llevan a cabo esos pasos a través de desarrollo en línea de comando. Desarrollo de código: Acá usamos un editor de texto cualquiera. En el momento en que terminemos de escribir nuestro código en el archivo de texto, lo guardaremos con el nombre de la clase principal y con la extensión.java Compilación: En línea de comandos (símbolo del sistema), buscamos la carpeta en la que guardamos nuestro archivo.java, para crear el archivo.class (es decir, el archivo compilado). Luego de encontrar esta carpeta, escribimos lo siguiente: javac bootclasspath c:\midp2.0fcs\classes <fuente>.java Donde el archivo <fuente>.java fue el que guardamos anteriormente en el procesador de texto. Preverificacion: En este caso, nos movemos ahora donde quedó la clase que compilamos anteriormente, y escribimos lo siguiente: preverify classpath c:\midp2.0fcs\classes <fuente>.java 34

35 Esta preverificación genera un fichero.class en la carpeta /output/, es decir en la carpeta llamada output encontrada en el lugar donde se instaló el SDK. Empaquetamiento: En esta etapa, crearíamos el archivo.jar y.jad de la clase compilada. Así, crearemos el paquete definitivo que ejecutaremos sobre nuestra MIDlet. Anteriormente hemos dicho que el.jar es el archivo que contiene los elementos que conforman el MIDlet, y que el.jar es el archivo descriptor de la aplicación. Esto significa que el.jad describe una aplicación, y no precisamente un MIDlet (aunque pueden haber aplicaciones de un solo MIDlet), pero generalmente una aplicación posee múltiples MIDlets. A estos múltiples MIDlets se les llama Suite de MIDlets. Describiremos el proceso para empaquetar un solo MIDlet, extensivo para una suite. Antes que nada, debemos conocer la escructura de un archivo.jar para saber cómo empaquetarlo. Un archivo.jar tiene varios componentes, a saber: - Un archivo manifiesto (Manifest), describiendo el contenido del archivo JAR - Las clases de JAVA que conforman el MIDlet propiamente dicho - Los archivos de los recursos que usa el MIDlet Veremos las características del archivo manifiesto. 35

36 Archivo manifiesto: creación. El archivo manifiesto describe el contenido del archivo.jar, y no es obligatorio crearlo. Se puede crear a través de un procesador de texto simple, y su estructura de atributos es de la forma atributo:valor. Un archivo manifiesto tiene la siguiente forma en modo texto: MIDlet-1: Saludo, saludo.jpg, Saludo MIDlet-Name: Hola MIDlet-Vendor: SENA MIDlet-Version: 1.0 Microedition-Configuration: CLDC-1.0 Microedition-Profile: MIDP-1.0 En la siguiente tabla podemos observar los atributos que debe tener el archivo manifiesto: Y en la siguiente tabla podemos observar otros atributos adicionales que puede tener el archivo. 36

37 Digamos que queremos crear una suite de MIDlets con varios MIDlets incluídos. Para crear el archivo manifiesto de una suite de MIDlets, usamos el siguiente atributo para definir cada uno de los MIDlets: MIDlet-1: Saludo, saludo.jpg, Saludo MIDlet-2: Despedida, adios.png, Despedida Y es así como, mediante modo texto, creamos nuestro archivo manifiesto. Proseguimos entonces con el.jar Archivo.JAR, creación Para crear el archivo.jar, nos movemos nuevamente a línea de comandos y escribimos lo siguiente: jar cmf <archivo manifiesto> <nombrearchivo>.jar -C <clases java>. C <recursos> Con esta línea de comando, y reemplazando cada uno de los comodines (los nombres encerrados en < >) por su correspondiente elemento, creamos nuestro archivo.jar. Ahora basta con crear el archivo.jad Archivo.JAD, creación 37

38 Este archivo es usado por el AMS o gestor de aplicaciones para verificar descargas, nombres de archivo, elementos del archivo manifiesto, autenticación, entre otros. Este archivo es opcional, pero si es creado, debe contener los siguientes elementos de manera obligada: Se le puede, como al archivo manifiesto, incluir atributos opcionales. Estos atributos se ven en la siguiente tabla: Existen otros atributos adicionales, que el desarrollador de a suite puede agregarle al archivo.jad, que sirven para crear aplicaciones adicionales y de mayor complejidad. Estos atributos pueden ser investigados por el estudiante en la sección de documentos de apoyo. 38