Introducción a dispositivos_móviles

1 Programación de dispositivos móviles Semana 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.”


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 e-mail 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.


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:

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.


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


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”


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


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.


¿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 40-80 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


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


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 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


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:


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


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:


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.


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 20000

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.

A partir de estas características, podemos definir un conjunto de

dispositivos entre los cuales podemos incluir a los teléfonos móviles, los


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:

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


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


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


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á


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 0-100 metros, y que permite crear redes ad-

hoc, 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.


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


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:

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.


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


“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


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 905


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


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


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


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:

http://java.sun.com/products/archive/j2se/1.4.1_07/

c) Las APIs de la configuración CLDC y del perfil MIDP que se

pueden descargar de la página

http://java.sun.com/products/archive/j2se/1.4.1_07/


http://www.oracle.com/technetwork/java/javame/downloads/index.

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.

http://www.oracle.com/technetwork/java/javame/downloads/index.html

http://www.oracle.com/technetwork/java/javame/downloads/index.html


¿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)


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:


- 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


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


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.


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.


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


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”.


Ejecución-depuración: La ejecución, como se dijo anteriormente, se

debe llevar a cabo sobre un simulador. El simulador que nosotros

usaremos se llama “Wireless Toolkit 2.0”, y la explicaremos en breve. La

depuración solo es cuestión de observación y de reescritura del código

para volver a compilarlo, preverificarlo y empaquetarlo.

Llegando hasta este punto, conocemos la forma general de crear un MIDlet en

JAVA. De acá en adelante, veremos herramientas que nos facilitan

enormemente la labor de creación de MIDlets, como lo son los programas de

desarrollo en entorno visual.

DESARROLLO EN ENTORNOS VISUALES

Existen una gran variedad de aplicaciones que pueden ayudarnos a crear

MIDlets de una manera más rápida y eficaz. Nosotros veremos 2 de estas

herramientas, las cuales explicaremos a continuación:

Sun One Studio Mobile Edition: Esta herramienta es un entorno de

desarrollo completamente integrado, similar al Sun One, pero con un

emulador que nos permite ver la ejecución de nuestro MIDlet. Aparte de

eso, posee las APIs propias de la configuración CLDC y el perfil MIDP.

Actualmente existe la herramienta

J2ME wireless toolkit V2.0: Es un emulador que recibe las clases JAVA

creadas en el desarrollo de línea de comandos y nos permite ver el

MIDled ejecutándose. Actualmente existe la SUN JAVA Wireless toolkit,

que reemplaza la J2ME Wireless toolkit.


Ambas plataformas, luego de la integración entre ORACLE y SUN, fueron

fusionadas en la herramienta “Java Plataform Micro Edition Software

Development Kit” el cual se puede descargar de la siguiente dirección:

http://www.oracle.com/technetwork/java/javame/downloads/sdk30-jsp-

139759.html

Para esta aplicación se debe haber instalado el JAVA SE Development Kit

JDK, que es la versión actualizada del JAVA 2 SDK instalado anteriormente.

Esta versión actualizada se puede descargar de la siguiente dirección:

http://www.oracle.com/technetwork/java/javase/downloads/index.html?ssSource

SiteId=otncn

Desarrollo de aplicaciones en el JAVA plataform micro edition software

development kit

Una vez instalado el Sun One Studio Mobile Edition, nos aparecerá un entorno

basado en ventanas donde podremos desarrollar y compilar nuestro MIDlet.

Esta herramienta da una gran cantidad de características, como:

- Editor de texto integrado, en el cual se puede escribir el código de

nuestra aplicación.

- Compilación inmediata del código, gracias a que la plataforma

posee todas las librerías necesarias para llevar a cabo este

trabajo.

http://www.oracle.com/technetwork/java/javame/downloads/sdk30-jsp-139759.html

http://www.oracle.com/technetwork/java/javame/downloads/sdk30-jsp-139759.html

http://www.oracle.com/technetwork/java/javase/downloads/index.html?ssSourceSiteId=otncn

http://www.oracle.com/technetwork/java/javase/downloads/index.html?ssSourceSiteId=otncn


- Preverificación realizada de manera directa, igual que la

compilación.

- Posibilidad de empaquetar el MIDlet en un solo paquete o hacer

una suite de MIDlets.

- Nos permite emular los MIDlets en plataformas virtuales o MIDs,

ya que al estar integrada la plataforma de SUN y la de J2ME,

contiene integrados los simuladores necesarios y apropiados para

llevar a cabo la visualización de los MIDlets en ejecución.

Es esta entonces una herramienta completamente global, que nos permite

crear MIDlets de manera fácil y rápida, sin tener que usar los pasos anteriores

explicados en línea de comandos.


Es necesario que el aprendiz explore esta plataforma y lea los tutoriales

presentes en la página de SUN, ya que si bien la herramienta nos permitirá

crear MIDlets, no se abarcarán sus capacidades, ya que no es objetivo del

curso.

Otros emuladores

Cuando creamos un MIDlet, queremos que esta aplicación sea soportada por

uun amplio número de dispositivos. Es por esto que cada fabricante de

dispositivos móviles, en sus páginas de desarrolladores, posee MIDs que

permiten probar nuestros MIDlest en sus plataformas. Es cuestión del aprendiz

buscar plataformas adicionales para simular aplicaciones, o usar los MIDs

incorporados en el software explicado en el apartado superior.

Introducción a dispositivos_móviles

Documents

Transcript of Introducción a dispositivos_móviles