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

Semana 1
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.

Semana 1
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.

Semana 1
 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

Semana 1
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”

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

Semana 1
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.

Semana 1
¿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

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

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

Semana 1
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:

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

Semana 1
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:

Semana 1
 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.

Semana 1
 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

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

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

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

Semana 1
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á

Semana 1
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.

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

Semana 1
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.

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

Semana 1
“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

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

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

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

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

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

Semana 1
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.

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

Semana 1
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:

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

Semana 1
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.0fcsclasses <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.0fcsclasses <fuente>.java

Semana 1
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.

Semana 1
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.

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

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

Semana 1
 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.

Semana 1
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.

Semana 1
- 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.

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (14)

Ähnlich wie Introducción a dispositivos_móviles

Ähnlich wie Introducción a dispositivos_móviles (20)

Mehr von CESAR A. RUIZ C

Mehr von CESAR A. RUIZ C (20)

Introducción a dispositivos_móviles