Está en la página 1de 37

Son J2ME y WAP competidores?

Una idea muy comn y errnea es que J2ME y WAP son competidores, es decir, ambos sirven para lo mismo y simplemente son dos filosofas diferentes para resolver un nico problema. Podemos ver que esta creencia es totalmente falsa simplemente prestando atencin a las definiciones de ambos conceptos.

Wireless Application Protocol (WAP) es un protocolo de comunicaciones diseado para permitir que dispositivos wireless con pantallas pequeas y conexiones de baja velocidad puedan acceder a Internet y aplicaciones de intranets. J2ME es una tecnologa que permite desarrollar aplicaciones genricas para este tipo de dispositivos. Vemos por tanto que son cosas muy diferentes y que no pueden competir entre s, incluso son tecnologas complementarias, pues expande el uso de las aplicaciones que disponen de posibilidad de acceso a redes sin cable. As, un usuario de PDA, por ejemplo, puede bajarse una aplicacin que desea instalar mediante un navegador WAP estndar.

Tipos de dispositivos mviles

Antes de entrar detalladamente a describir algunos de los dispositivos mviles, vamos a concretar detalladamente el concepto de dispositivo que estar subyacente en el resto del curso. En ingls existe una amplia gama de trminos para referirse a este tipo de aparatos: "information device", "information appliance", "consumer electronic", "embedded device" o "small device", por ejemplo. En definitiva:

son aparatos pequeos, con algunas capacidades de procesamiento, mviles o no,

con conexin permanente o intermitente a una red, con memoria limitada, diseados especficamente para una funcin, pero que pueden llevar a cabo otras ms generales. Normalmente se asocian al uso individual de una persona, tanto en posesin como en operacin, el cual puede adaptarlos a su gusto. La mayora de estos aparatos pueden ser transportados en el bolsillo del propietario y otros estn integrados dentro de otros mayores, controlando su funcionalidad (como puede ser el ordenador integrado en una lavadora). Sigamos con la descripcin genrica de los mismos. Una caracterstica importante es el concepto de movilidad: los dispositivos mviles son aquellos suficientemente pequeos para ser transportados y empleados durante su transporte. Normalmente se sincronizan con un sistema de sobremesa para actualizar aplicaciones y datos. Un PDA es mvil, pero por ejemplo, un telfono con pantalla para Internet, no sera mvil. Una aplicacin de estos dispositivos es un vendedor que carga en su PDA, en su despacho, antes de salir de la oficina, los datos de los clientes que tiene que visitar. Durante su visita actualiza o modifica la informacin y, una vez termina su ruta, ya en la oficina, actualiza los datos en la aplicacin corporativa. Otro concepto importante es el trmino ingls "wireless" (en espaol, optaremos por inalmbrico). Un dispositivo inalmbrico es aquel que es capaz de comunicarse o acceder a una red sin cables. Por ejemplo, un telfono mvil, paginadores, comunicadores de bolsillos o PDAs. Este tipo de dispositivos se comportan como si estuvieran directamente conectados a una red mediante un cable, dando la impresin al usuario que los datos estn almacenados en el propio dispositivo. Por ejemplo, el mismo vendedor puede cambiar a un telfono mvil y emplearlo para consultar algn dato de un cliente justo antes de visitarlo. Los conceptos de mvil y sin cables muchas veces se confunden. Por ejemplo, un PDA con datos en l y aplicaciones para gestionarlos puede ser mvil, pero no tiene por qu ser wireless, ya que puede necesitar un cable para conectarse al ordenador y obtener o enviar datos y aplicaciones. Veamos otro ejemplo. Un telfono mvil equipado

con un pequeo navegador puede navegar por Internet. En este caso, se considera wireless, pero no se considerar mvil si no dispone de un valor aadido en forma de aplicaciones que aporte alguna funcin cuando no est conectado a otros sistemas. Si el PDA es capaz de conectarse a una red para obtener datos "en medio de la calle", entonces tambin ser wireless. Algunas de las caractersticas que hacen que estos dispositivos sean diferentes de los ordenadores de sobremesa son los siguientes:

Funcionalidad limitada. No necesariamente extensible y actualizable. En pocos aos el usuario deber cambiarlo. Ms barato. Menos complicado en su manejo. Fcil de aprender su operacin. No se requieren usuarios expertos. Algunos de estos dispositivos son los siguientes:

Paginadores. Comunicadores de bolsillo. Telfonos con pantalla para Internet (Internet Screen Phones). Sistemas de navegacin de automviles. Sistemas de entretenimiento. Sistemas de televisin e Internet (WebTV). Telfonos mviles. Organizadores y asistentes personales digitales (Personal Assistant ).

Digital

Veamos a continuacin de una forma ms detallada los dispositivos que mayormente trataremos en este curso: el telfono mvil y el PDA.

Tipos de dispositivos mviles - El telfono mvil


Los telfonos mviles son de los aparatos sofisticados que encontramos en nuestro cotidiano quehacer. Para comprimir y descomprimir seales digitales codificadas, tienen que procesar millones de clculos por segundo. No obstante, se componen de apenas algunos componentes. Son estos:

Un micrfono microscpico. Un altavoz.

Una pantalla de cristale lquido o plasma. Un teclado. Una antena. Una batera. Una placa de circuitos. El mvil posee un microprocesador que realiza clculos a gran velocidad, llamado DSP, o Digital Signal Processor (Procesador Digital de Seales). Este procesador har toda la compresin y descompresin de los datos a la velocidad de 40 MIPS (Millones de Instrucciones Por Segundo). El microprocesador trata todas las tareas del teclado y de la pantalla, gestiona los comandos y controla las seales de la estacin de base, adems de coordinar las dems funciones. Las ventajas que presenta un telfono mvil como tipo de dispositivo mvil son varias:

Muy extendido. Ligeros y transportable. Econmico. Poseen prestaciones de comunicacin innatas. Por el contrario, tambin muestran algunos inconvenientes:

Poca potencia de proceso. Poca memoria. Capacidades de visualizacin limitada. Interaccin avanzada difcil. En verdad, un telfono mvil no es realmente un telfono, pero s un aparato de radio. Un telfono mvil utiliza dos frecuencias diferentes: una para hablar y otra para escuchar, permitiendo una conversacin normal. Un aparato de radio tiene 40 canales, un telfono mvil comunica a travs de millares. No obstante, como los telfonos mviles funcionan en un sistema de clulas, y una radio transmite directamente para otro aparato, es decir, la radio tiene que ser mucho ms potente, a pesar de tener un alcance de poco ms de seis kilmetros.

Cmo se produce la comunicacin?


La operadora de telefona mvil correspondiente reparte el rea en varios espacios, en varias clulas, normalmente

hexagonales (forma geomtrica que permite ocupar todo el espacio y se aproxima mucho a la circunferencia), compuesto de una inmensa red de hexgonos. En cada clula existe una estacin base transmisora, tpicamente, una simple antena. Cada clula consigue utilizar varias decenas de canales, lo que da la posibilidad que varias decenas de personas se comuniquen simultneamente por ella. Cuando una persona se mueve de una clula para otra, pasa a utilizar la frecuencia de la nueva clula, dejando libre la clula anterior para ser usada por otra persona. Como las distancias de transmisin no son muy grandes, los telfonos mviles pueden transmitir con poca energa, luego, con pequeas bateras que permiten un tamao y un peso reducido. Son, por tanto, las clulas, que tornan posibles los telfonos mviles como los conocemos hoy. Por ello la expresin: telfonos celulares.

Sistemas de telefona mvil


En cuanto a los sistemas de telefona, el primero de ellos es GSM, que fue diseado originalmente para transmitir voz, pero con el tiempo la tecnologa les posibilit tambin operar en modo de transferencia de datos. Los terminales operan por conmutacin de circuitos, pudiendo sta ser visualizada como dos interruptores que necesitan estar encendidos para que exista transmisin de informacin. Esto lleva a que el establecimiento de conexin conlleva tiempos de espera, debido a la necesidad de los dos mdems estar conectados uno con el otro simultneamente y que la llamada est siempre abierta, an cuando no existe transferencia de datos. Esta forma de transmisin es extremamente limitada en trminos de capacidad, a pesar de estar a ser desarrollada tecnologa como el HSCSD (High Speed Circuit Switched Data) que permitir una velocidad mxima de 56 Kbps. Otro problema es el hecho de no ser posible a esta tecnologa soportar el IP (Internet Protocol), lo que impide el acceso directo a Internet. El estudio de las limitaciones de GMS origina la necesidad de un sistema basado en la transmisin de datos por paquetes (IP). En 1998 el ETSI (European Telecommunications Standards Institute), la entidad reguladora de las telecomunicaciones europeas, concluy sus estudios sobre la definicin de las normas de un nuevo sistema, el GPRS, que permite una mayor capacidad de transmisin de datos. GPRS permitir una velocidad mxima terica de 177.2 Kbps, en caso de que utilice todos los recursos del sistema. Finalmente, el GPRS permitir toda una nueva serie de aplicaciones dentro de los mviles, apenas accesibles hasta ahora a

quien posea un ordenador personal, tales como la visualizacin de pginas de la Web, FTP, IRC, animacin, etc. En resumen, el GPRS traer consigo los siguientes beneficios:

Conexin a Internet permanente (siempre "on-line"). Establecimiento instantneo de la conexin. Posibilidad de que la facturacin del servicio sea realizada segn la cantidad de informacin transmitida / recibida, al envs de ser contabilizado el tiempo que se est conectado. Una mayor velocidad de transmisin de datos. El UMTS (Universal Mobile Telecommunication System) es el nuevo protocolo que ser utilizado en Europa por la 3 generacin de telfonos mviles. Integrado en el proyecto de crear un estndar que pueda ser utilizado mundialmente (al revs de la 2 generacin, cuyos sistemas americano y europeo son incompatibles), el UMTS deber alterar la forma de como los mviles son utilizados actualmente, al permitir capacidades multimedia y un acceso sin lmites a Internet. Con los adelantos tecnolgicos de los ltimos aos dentro de Internet y de la telefona mvil, se asiste ahora a una convergencia cada vez mayor entre estos dos medios de comunicacin. El UMTS representar la unin de ambos en una nica plataforma. Tambin designado de 3G, o tercera generacin de telfonos mviles, este sistema permitir que el usuario pueda acceder a imgenes y vdeos, as como a Internet de manera veloz, calidad de voz casi igual a la de las redes fijas, y una larga lista de otras funciones diversas. El UMTS resulta de la necesidad de implantar una nueva generacin de telfonos mviles debido al aumento del nmero de usuarios de este medio de comunicacin. El xito del sistema GSM, dentro de Europa, conllev la saturacin de las frecuencias de radio que le fueron originalmente atribuidas. Tal problema cre la necesidad de lanzar una nueva generacin y, a travs de sta, ampliar el espectro electromagntico disponible as como permitir el acceso a nuevos servicios. La tecnologa UMTS no ser limitada a las redes mviles, estando prevista su utilizacin por otras redes. La tecnologa digital utilizada por el UMTS se denomina de WCMDA (Wide Code Multiple Division Access). Los datos son transmitidos en banda ancha, siendo divididos en paquetes antes de la transmisin, los cuales

son despus reunidos por el terminal antes de presentar la informacin en la pantalla. Este sistema est basado en el protocolo americano de los telfonos mviles de segunda generacin (el CMDA), no siendo compatible con el GSM. Adems de las funciones bsicas a que estamos habituados en nuestro mvil, como simplemente telefonear a alguien o enviar / recibir mensajes, el UMTS permitir acrecentar una nueva serie de caractersticas hasta ahora casi inaccesibles o apenas presentes en las pelculas de ciencia-ficcin. El sistema permitir el acceso a Internet a una velocidad ms rpida que los mdems normales, as como la transmisin de faxes, imgenes, vdeos y datos. Al mismo tiempo que estaremos telefoneando ser posible visualizar en la pantalla, en tiempo real, la persona con quien comunicamos, en caso de que sta tambin posea un mvil UMTS. El acceso a Internet ser bastante ms rpido y sin limites, pudindose acceder a cualquier tipo de informacin, en cualquier lugar en que estemos. Informacin, comercio y entretenimiento multimedia estarn disponibles en pantalla, en un sistema que integrar las redes de telecomunicaciones mviles, fijas y por satlite. Adems del "roaming" a escala mundial, el UMTS permitir la convergencia de los varios tipos de redes existentes. Segn la Comisin Europea, los servicios UMTS debern poseer las siguientes caractersticas:

Capacidad multimedia y una gran movilidad. Acceso eficiente a Internet. Alta velocidad. Portabilidad entre los varios ambientes UMTS (permitiendo el acceso a las redes UMTS terrestres y de satlite). Compatibilidad entre el sistema GSM y el UMTS, debiendo los terminales poseer "dual band" o funcionar en ambos los sistemas. Esta nueva tecnologa deber alterar radicalmente la manera como utilizamos los telfonos mviles. Las personas tendrn el mvil ms tiempo delante de los ojos que pegado a la oreja, debido a que este pasar a ser un dispositivo multimedia, como la televisin o la computadora. Al mismo tiempo, la transmisin de datos ocupar una parte mayor del tiempo de utilizacin del telfono mvil, debido a todas las posibilidades existentes (enviar faxes, e-mails,...). La calidad de voz ser semejante a la de los telfonos fijos y la velocidad de transmisin de datos superior a la de un mdem normal, lo que podr significar que las personas usen

apenas el mvil, en sustitucin del telfono fijo y del acceso a Internet a travs del ordenador. Adems, se tendr la posibilidad de tener Internet en la palma de la mano.

Tipos de dispositivos mviles - El Personal Digital Assistant (PDA)


Un Personal Digital Assistant, o ms conocido como PDA, es como su propio nombre indica un organizador digital. Bsicamente ofrece calendarios, blocks de notas y agendas para telfonos, como caractersticas comunes, por lo que en un futuro no muy lejano reemplazarn las agendas clsicas. Tambin permiten descargar correo electrnico y otros materiales desde un ordenador, o con aquellos que ya estn equipados con un mdem, acceder a Internet. Normalmente consisten en una pantalla, que suele ser tctil (utilizando un lpiz especial el usuario realiza la entrada de datos, eliminando la necesidad de un teclado, lo que facilita el transporte en el bolsillo. Adems, reconocen la escritura sobre su pantalla), un procesador, memoria y un sistema operativo. Adems, permiten, como ya hemos dicho, conectividad con el ordenador de sobremesa, lo que posibilita salvaguardar los datos y exportarlos a bases de datos o a aplicaciones ms elaboradas, o transferir nuevas aplicaciones al asistente. Hay una amplia variedad de asistentes personales. Si nos fijamos en la pantalla, los hay desde los que son monocromos o como mucho presentan una escala de colores, hasta los que poseen ms de 65.000. El tamao tambin cambia de un modelo a otro y el tipo: los basados en matrices activas, presentan una mejor calidad que los basados en pasivas, los cuales consumen menos energa. Con respecto a esto, las bateras suelen ser recargables y removibles. La memoria vara entre los 2 y los 64 Mbytes. La primera cantidad es suficiente para aplicaciones bsicas de block de notas, calendario, agenda y varias utilidades ms. Si lo que se desea es almacenar ficheros grandes como fotos, bases de datos o programas de gran tamao es imprescindible una memoria de mayor capacidad. Como ejemplo, citar que los PDAs de ltima generacin son excepcionales para jugar y entretenerse, leer

libros, ver fotos, escuchar msica e incluso reproducir pelculas. La memoria se puede ampliar mediante tarjetas. Inicialmente la conexin al PC se realizaba mediante un cable, pero actualmente sta se puede efectuar sin l, de manera inalmbrica. La sincronizacin se lleva a cabo mediante infrarrojos o radio (como es el caso de Bluetooth). De esta manera, a los usuarios se les permite intercambiar informacin como entradas de una agenda o correos electrnicos simplemente situndolo prximo al ordenador de sobremesa. Pero la conexin inalmbrica va ms all an, pues los PDAs pueden tener conectividad a una red "wireless" de rea local o usar un mdem CDPD (Cellular Digital Packet Data) para acceder a Internet, lo que aumenta sus posibilidades, como son las de navegacin por la World Wide Web o el envo y recepcin de correo electrnico, entre otras. Un PDA, con respecto a un mvil, presenta algunas ventajas en general:

Las pantallas son ms grandes y la visualizacin se mejora. La interaccin con el usuario es ms fcil (fundamentalmente por ser la pantalla tctil). Es ms potente, desde el punto de vista computacional. Sin embargo, tambin presentan algunos contras:

Necesita accesorios para comunicarse El precio es mayor que el de un telfono mvil.

Tipos de dispositivos mviles - Sistemas Operativos


La familia Windows
Windows CE es el Sistema Operativo que Microsoft ha desarrollado a partir de Windows 95, para dispositivos mviles, y sirve de base para el desarrollo de los sistemas especficos de cada dispositivo. Lo que los usuarios finales disfrutan, no es Windows CE tal y como ha sido desarrollado. En cada tipo de dispositivo se implementa, desde las posibilidades que permite la versin de Windows CE disponible, una interfaz y las funcionalidades requeridas. As, el Pocket PC 2000, 2002 y 2003 se han desarrollado

especficamente para los PDAs. Windows CE naci como un sistema operativo de fcil programacin, slido, transparente y que poda implantarse desde un ordenador a una lavadora, nevera, microondas incluso videoconsolas (DreamCast). De hecho, se pens en integrarlo en todo lo que no fuera un PC. Windows CE .NET, es la evolucin de Windows CE 3.0 bajo la filosofa distribuida de .NET. Es pues, un escenario de trabajo que deber ser adaptado a cada dispositivo. Esta nueva versin tiene muchas ventajas, que pueden ser aplicadas a cada uno de los sistemas operativos derivados. Segn Microsoft, Windows CE .NET, incorporar la posibilidad de manejar las conexiones Bluetooth, Microsoft Internet Explorer, Windows Media 8 y DirectX y ser compatible con una amplio rango de procesadores como Xscale, ARM, MIPS, SH o x86. Cada sistema operativo derivado, tomar las propiedades que le competan. Para obtener ms informacin sobre esta familia de sistemas, vase el sitio de Microsoft. Los dispositivos PDA que disponen de Pocket PC son dispositivos con una magnfica pantalla de 240 x 320 pxeles a todo color. Son muy potentes, con procesadores de entre 133 y 206 Mhz y 16, 32 64 Mbytes de RAM, por lo que son capaces de reproducir vdeo o msica y ejecutar aplicaciones multimedia con gran rapidez. Tambin disponen de altavoz y salida de audio para auriculares. Adems incluyen diversos tipos de ranuras o slots de expansin, que permiten insertar tarjetas de diversos formatos (Multimedia, CompactFlash o PCMCIA) para aumentar memoria o incorporar mdems, discos duros, tarjetas de red, etc.

Palm OS
La primera versin fue desarrollada por el fabricante de los DCM Palm para el modelo Pilot en 1996. Actualmente son muchos los fabricantes como Oracle, Nokia, Handspring, Symbol y Sony que utilizan diversas variantes y versiones de este Sistema Operativo que en conjunto representan el 66 % de todos los sistemas instalados en computadores de mano. Segn la filosofa de Palm, se intenta tratar a la computacin mvil no como versiones en miniatura de los sistemas de sobremesa, sino como dispositivos y aplicaciones dedicados a tareas y usos que tienen su propia identidad y reclaman sus propios recursos y soluciones.

En los ltimos aos, la versin ms extendida ha sido la 4.1 que entre sus principales caractersticas, presenta el soporte "terico" de 65.000 de colores as como la gestin de tarjetas de memoria externa. Recientemente Palm Computing se dividi en dos empresas distintas, una de hardware y otra de software, Palm Source la cual ha presentado Palm OS 5 que es realmente un sistema diferente a los anteriores aunque esto se refiera ms al funcionamiento interno que a lo relativo a su utilizacin externa. Para mantener la compatibilidad con la generacin anterior del sistema operativo, la nueva versin incluye un emulador llamado PACE que permite ejecutar las ms de 50.000 aplicaciones existentes. Adems, cualquiera que sea la norma considerada, WiFi Lan, Bluetooth, GSM/GPRS, o CDMA, el sistema Palm OS 5 integra las APIs necesarias. O sea, que los dispositivos equipados con Palm OS 5 pueden comunicarse fcilmente con todos los dispositivos existentes que estn basados en esas normas tales como telfonos mviles, impresoras, mdems, etc. Las normas de seguridad incorporadas en el sistema, permiten que las transacciones sean hechas de forma segura, considerando tambin, el uso de firmas digitales homologadas. Tambin ofrece servicios de encriptacin para las conexiones. El sistema incluye asimismo un navegador para Internet, el NetFont que suporta entre otras normas, HTML 4.01, XHTML, los GIFs animados, el modo seguro de acceso a la red VPN (Virtual Private Network) y la interpretacin de cdigo JavaScript. Estas normas ya utilizadas en los sistemas de los computadores de sobremesa se introducen por vez primera en los equipos de mano. En cuanto a los dispositivos que contiene Palm OS, la caracterstica ms llamativa es su reducido tamao y ligereza: pesan entre 120 y 170 gr, y son en general ms pequeos que los Pocket PC. Todos tienen una pantalla de 160x160 pxeles, normalmente monocroma. Usan procesadores de 1633 Mhz que son suficientes para que el dispositivo funcione con rapidez, y disponen de 2 u 8 Megabytes de memoria RAM.

Linux

LINUX es un sistema operativo compatible UNIX. Dos caractersticas muy peculiares lo diferencian del resto de los sistemas ms extendidos en el mercado, la primera, es que es libre, esto significa que no hay costos por sus licencias, la segunda, es que el sistema viene acompaado del cdigo fuente. LINUX se distribuye bajo la licencia pblica del proyecto GNU que fue lanzado en 1984 para desarrollar el Linux de libre distribucin. El sistema ha sido diseado y programado por multitud de programadores alrededor del mundo. El ncleo del sistema sigue en continuo desarrollo. En los ltimos tiempos, ciertas casas de software comercial han empezado a distribuir sus productos para Linux y la presencia del mismo en empresas aumenta rpidamente por la excelente relacin calidad-precio que se consigue. En los ltimos aos, algunos fabricantes de dispositivos mviles han incorporado Linux a sus productos. Se estn desarrollando versiones de Embedded Linux que constituyen la tercera alternativa a Palm OS y Windows CE para los computadores de mano. As, LinuxDevices.com, ha creado ha creado una gua de referencia para computadores de mano basados en Linux, con la que pretende mantener actualizados de manera permanente los productos Linux para pequeos dispositivos. Si bien el modelo Sharp Zaurus SL-5x00 fue el primer computador de mano con Linux pre-instalado, hay actualmente versiones de Embbeded Linux para casi todas las marcas.

Epoc
El sistema operativo de Psion se llama EPOC, nombre del ncleo del antiguo sistema operativo de la Psion serie 3. Hasta 1997 Psion no comenz a licenciar el EPOC32, la versin de 32 bytes para la serie 5. Permite realizar multitarea y pretende competir con Windows CE. El recibimiento fue fro y slo Philips mostr algo de inters. Pero Psion reaccion y a mediados de 1998 cre la alianza Symbian -junto con Ericsson, Nokia, Motorola y Matsushita- con el propsito de hacer de EPOC un sistema operativo nico. El premio de esta apuesta es elevado: los 600 millones de usuarios de dispositivos mviles en ao 2002.

Un vistazo ms profundo a la arquitectura J2ME: CLDC

Como ya hemos visto, J2ME se sustenta en dos bloques principales: la configuracin y el perfil. Volviendo a repasar estos conceptos, una configuracin define la plataforma mnima necesaria para un grupo de dispositivos que tienen similar memoria y capacidades de procesamiento. Se compone de una mquina virtual, unas caractersticas del lenguaje Java y un conjunto mnimo de clases que soporta ese grupo de dispositivos. Por otro lado, un perfil extiende una configuracin y completa las necesidades especficas para una cierta familia de dispositivos. Un perfil tiene asociado un conjunto especfico de bibliotecas mnimas.

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

CLDC
Veamos ms detalladamente algunas caractersticas de CLDC, ya que es la configuracin en la que nos centraremos en este curso. Comencemos por las propiedades mnimas requeridas a un dispositivo para poder desarrollar con esta configuracin:

De 160 a 512 Kbytes de memoria disponible para el entorno de Java. Un procesador de 16 o 32 bits. Consumo de energa bajo (generalmente utilizan bateras). Permiten algn tipo de conectividad a una red (lo normal, es una conexin intermitente, con un ancho de banda bajo -sobre 9600 bps- y a menudo inalmbrica. Al tener como objetivo dispositivos con prestaciones reducidas, CLDC elimina una gran cantidad de caractersticas que

s aparecen en J2SE, tanto en el propio lenguaje Java como en la mquina virtual, como por ejemplo:

Interfaz nativo de Java (Java Native Interface -JINI) (Mquina virtual). Cargadores de clases definidas por el usuario (Mquina virtual). Grupos de hilos e hilos demonios (Mquina virtual). Finalizacin (lenguaje Java). Referencias dbiles (Mquina virtual). Reflexin (Mquina virtual). Tipos de datos de punto flotante (lenguaje Java). Algunos aspectos de seguridad y APIs (Mquina virtual). Verificacin de ficheros de clases (Mquina virtual). Posee algunas limitaciones en las gestiones de errores (lenguaje Java). Pero qu razones se consideraron para eliminar esas prestaciones? Por supuesto, una de ellas se basa en cuestiones de ahorro de memoria, ya que el tamao general del API queda reducido. Aunque otras tambin han sido quitadas por cuestiones de aligerar el procesador, como es el caso de las operaciones en punto flotante, o la verificacin de las clases. Concretamente, esta operacin, que identifica y rechaza ficheros de clases invlidas, se realizaba en la mquina virtual en la edicin J2SE, pero en ese caso aumenta su tamao. Por esta razn, en J2ME la verificacin se hace en dos partes: la primera, la preverificacin, en un ordenador distinto; la segunda s se lleva a cabo en el propio dispositivo, pero en este caso es mucho ms simple y rpida. Ms adelante estudiaremos de manera ms detallada el proceso de verificacin. Con respecto a la seguridad, al no definir CLDC completamente el sistema de seguridad de Java deben eliminarse prestaciones que s figuran en el J2SE (por ejemplo, JINI, que permite la utilizacin de una biblioteca de clases escrita en otros lenguajes -enlazado en tiempo de ejecucin) y que haran muy vulnerables las aplicaciones. Por ejemplo, sin este modelo de seguridad, un cargador de clases definido por el usuario podra alterar la forma en que el camino de las clases fuera recorrido, pudiendo una aplicacin sustituir trozos de las bibliotecas del ncleo de Java y ganar acceso al dispositivo de tal forma que pudiera daarlo.

Tambin se considera la simple conveniencia como criterio: algunas clases pueden ser desarrolladas por los programadores basadas en otras que s se mantienen. Igual ocurre con algunos mtodos de clases. Por otro lado, otras clases se eliminan por que no tiene razn de ser: java.io.File tiene sentido si se trabaja en un sistema de ficheros, pero muchos dispositivos no disponen de l. En su lugar, CLDC utiliza las propias prestaciones del dispositivo. Otro ejemplo en este sentido son la finalizacin de objetos, ya en el J2SE puede ocurrir que nunca se lleve a cabo. La eliminacin de gestin de errores, por ltimo, va en la linea de la utilidad de la accin, y del tiempo consumido en ello. Una excepcin es un error que puede ser recuperable; un error, por el contrario, representa problemas muy serios y generalmente dependientes directamente del dispositivo, por lo que no merece la pena hacerlo. En cuanto a la mquina virtual de CLDC, KVM, requiere entre 40 y 80 Kbytes dependiendo de las opciones de compilacin y el tipo de dispositivo para el que se compile. Esto implica que se podrn ejecutar aplicaciones con un total de 128 Kbytes. Aparte de esto, se necesitan otros 32 Kbytes para memoria dinmica de la aplicacin a ejecutar. KVM est implementada en C y est diseada para ser tan completa y rpida como sea posible. De hecho, puede ejecutarse de un 30 a un 80% de la velocidad de la JVM. Volviendo a la verificacin de clases, la mquina virtual de Java estndar efecta un proceso en tiempo de ejecucin que se denomina verificacin de clases, el cual se lleva a cabo antes de cargar ninguna clase en memoria. El objetivo es asegurar la integridad de los ficheros donde se almacena una clase Java y que el cdigo en ella no intente acceder a memoria fuera de su espacio de nombres, eliminando la posibilidad de que pueda sustituir alguno de los paquetes del ncleo de Java (java.* o javax.*), y poniendo as en juego la seguridad del sistema. Esta etapa juega un papel muy importante en el modelo de seguridad de Java. Para que nos hagamos una idea, J2SE verifica, entre otros, estos puntos:

Inicializacin de todas las variables locales antes de su uso. El constructor de un objeto debe ser llamado justo seguidamente de la creacin del mismo, y antes de que se use.

Cada constructor tiene que comenzar con una llamada al constructor de su superclase. Las variables locales y miembros estticos deben contener referencias a objetos que sean asignables legalmente. Si nos trasladamos a CLDC, este proceso ser muy costoso en trminos de uso de recursos, ya que requiere mucha memoria, procesador y espacio para cdigo binario. Es por esto por lo que los diseadores de KVM decidieron hacer la verificacin de clases de manera diferente a como se hace con JVM. As, antes de que la clase se llegue a emplear en el dispositivo, sta es modificada externamente por una utilidad "preverificadora". La idea es aadir al fichero clase generado por javac nuevo cdigo que identifique la clase como vlida (pasa a ser una clase verificada). Seguidamente, se transfiere al dispositivo y la KVM slo tiene que comprobar si esta informacin est o no presente o contiene o no la informacin correcta. En cualquiera de los dos casos negativos, el proceso de carga se interrumpe y se lanza una excepcin. Esta comprobacin se puede hacer justo cuando se carga la clase o como parte del proceso de instalacin de la aplicacin. En cualquier caso es un proceso ms rpido que la preverificacin y requiere menos memoria. Pasando seguidamente a los perfiles, stos suministran un interfaz de usuario, mtodos de entrada y mecanismos de persistencia, as como un entorno de desarrollo completo para un conjunto especfico de dispositivos, soportando sus caractersticas concretas. Los perfiles son necesarios porque las configuraciones no presentan ninguna de estas prestaciones. La razn principal para crear diferentes perfiles es el hecho de que, por ejemplo, un telfono mvil tiene diferentes funcionalidades y conductas que una lavadora (al primero se le requerir envo y recepcin de correo electrnico, pero no funciones de inicio y parada programadas, como a la lavadora). As, J2ME oferta al programador el concepto de perfil, el cual define una plataforma comn para un grupo determinado de dispositivos, los cuales comparten caractersticas y funciones. Un dispositivo puede cubrir ms de un perfil. Los perfiles se asentan sobre una configuracin dada y utilizan los servicios que ofrece, aunque es la parte de la arquitectura J2ME que ms cerca se encuentra del aparato fsico. Para el caso de CLDC, su nico perfil es MIDP (Mobile

Information Device Profile), el cual cubre el mercado de dispositivos mviles, que comparten caractersticas como memoria limitada, pantalla pequea, conexin a algn tipo de red inalmbrica y mediante banda ancha limitada y alimentados normalmente por bateras . El software desarrollado con MIDP se ejecuta en el KVM suministrado por CLDC.

MIDP - MIDlets
Las aplicaciones MIDP se denominan "MIDlets", las cuales pueden utilizar tanto las facilidades aportadas por MIDP como las APIs que MIDP hereda de CLDC, pero nunca acceden directamente al sistema operativo subyacente, por lo que no seran portables. Un MIDlet consiste en una clase Java, como mnimo, derivada de la clase abstracta MIDP, y que se ejecutan en un entorno de ejecucin dentro de la mquina virtual, la cual provee un ciclo de vida bien definido controlado mediante mtodos de la clase MIDlet que cada MIDlet debe implementar. Tambin estas aplicaciones usan mtodos de esta clase abstracta para conseguir servicios de su entorno. Un grupo de MIDlets que estn relacionados se suelen agrupar en un MIDlet suite. Todos estos MIDlet se empaquetan, instalan, desinstalan y borran como una nica entidad y comparten recursos tanto en tiempo de ejecucin (se ejecutan en la misma mquina virtual, lo que implica que compartirn instancias de de todas las clases de Java cargadas en la mquina virtual), como estticos (el almacenamiento persistente se gestiona en el nivel de suite). Veamos seguidamente algunos detalles sobre los dispositivos que soportan MIDP. Comenzando con los requerimientos de memoria, MIDP necesita 128 KB de RAM disponible para la implementacin correspondiente. A esta cantidad debemos sumarle la que necesita CLDC y como mnimo 32 Kbytes para almacenar la pila de la aplicacin, tamao que obliga al programador a tener bastante cuidado a la hora de disear las aplicaciones. Adems, los dispositivos MIDP cuentan con 8 Kbytes como mnimo de memoria no voltil que se utiliza como almacenamiento persistente, que no se borra tras apagar el aparato (salvando el problema del cambio de batera).

Sobre las pantallas de los dispositivos, la especificacin MIDP indica que sta requiere 96 pixels de ancho por 54 de alto y que debe soportar al menos dos colores (como es el caso de muchos telfonos mviles, en contraposicin con algunas PDAs que tienen pantallas de 160 pixels en ambas direcciones y 65.536 colores diferentes). Con respecto a los tipos de entradas del dispositivo, el rango es muy amplio: desde los que tienen un teclado alfanumrico completo, hasta aquellos que permiten escribir en ciertas reas de la pantalla, pasando por los teclados de los telfonos mviles. La especificacin mnima requiere un teclado que permita marcar los nmeros del 0 al 9, junto con el equivalente a las teclas del cursor y un botn de seleccin. MIDP no asume que los dispositivos estn permanentemente conectados a una red, ni siquiera que soportan TCP/IP, pero que s tienen algn tipo de acceso a una red. En este sentido, la especificacin s establece que soporte HTTP 1.1, bien mediante una pila de protocolos o una pasarela WAP. Tambin los sistemas operativos de los dispositivos tienen restricciones con respecto a MIDP. Por ejemplo, deben ofrecer un entorno de ejecucin protegido donde la mquina virtual pueda correr, o algn tipo de apoyo para el acceso a una red, como puede ser el caso de un API para programar sockets, sobre el cual el protocolo HTTP se pueda implementar. Es el sistema operativo el que ofrecer acceso al teclado y al posible dispositivo puntero, entregando los correspondientes eventos que surjan. Adems, ser el encargado de abstraer al MIDP la pantalla, ya que ser visto por l como una matriz de pixels, y de ofrecer un interfaz para el acceso al almacenamiento persistente. Un aspecto muy importante a tener en cuenta es el de la seguridad. J2SE ofrece un modelo de seguridad potente y flexible, y a la vez, costoso en trminos de memoria, razn por la cual CLDC y MIDP no incluyen ningn tipo de prueba en las llamadas al API de las que incluye J2SE. Para un usuario de un dispositivo mvil esto puede suponer un peligro, porque el MIDlet no est limitando en ningn sentido. Es por esto por lo que el usuario debera ser bastante cuidadoso a la hora de instalar nuevas aplicaciones.

Los MIDlets necesitan empaquetarse antes de que sean trasferidos a un dispositivo para su instalacin: tanto la subclase MIDlet correspondiente como las clases que requiera y el resto de ficheros necesarios (como pueden ser ficheros de imgenes) constituirn un nico fichero JAR, incluyendo el conocido como manifiesto del JAR (contiene informacin de empaquetado que indica qu se almacena en el fichero JAR). Adicionalmente se emplea otro segundo fichero conocido como Java Application Descriptor (JAD). El manifiesto del JAR almacena el dispositivo, el nombre y la versin del MIDlet suite en el JAR correspondiente, as como qu ficheros de clase se corresponde con cada MIDlet, informacin til para instalar los MIDlets. El segundo es un fichero de texto que contiene una lista de atributos junto con su valor correspondiente. Algunos atributos estn tambin contenidos en el manifiesto del JAR, ya que ste puede ser grande y su transferencia lenta debido a la baja velocidad del acceso a la red que suelen tener estos dispositivos, en vez de descargar el JAR completo, se descarga el fichero JAD, el cual es mucho ms pequeo y rpido de transferir, se muestra por la pantalla del dispositivo y se decide si se instala o no.

El desarrollo de aplicaciones destinadas a dispositivos mviles, desde el punto de vista de la Ingeniera del Software, no debe diferir sustancialmente de los pasos a dar cuando se construyen aplicaciones para ordenadores de sobremesa o estaciones de trabajo. As, podramos establecer los siguientes pasos previos:

Anlisis de requerimientos.
El analista de turno deber determinar, normalmente con varias entrevistas con los usuarios, las necesidades que estos tienen y los requerimientos que se les pedirn a la aplicacin. Por ejemplo, en el caso de un anlisis para una aplicacin que se ejecutar en un dispositivo mvil, algunos de estos requerimientos generales pueden ser la facilidad de uso, que se pueda ejecutar en telfonos mviles, PDAs y paginadores, que permita una conexin a una entidad mayor para obtener datos actualizados o devolver otros, o tambin, que sea capaz de almacenar cierta informacin de manera persistente.

Diseo de la aplicacin.
Es muy importante en este tipo de aplicaciones el crear programas separados por cada uno de los posibles usos que se le d a la aplicacin. De esta manera cada programa ser ms pequeo y se adaptar mucho mejor a las caractersticas de los dispositivos mviles. Por tanto, a la hora del diseo nos plantearemos esta tarea seriamente, pues finalmente sern varias las ventajas de hacerlo as. Ya en la fase de implementacin se tendr que establecer un mecanismo que controle las diferentes aplicaciones. En cuanto al diseo del interfaz de usuario, debemos decidir la correspondencia entre la aplicacin y la pantalla. Los diseadores en esta fase no deben considerar cmo los usuarios operarn con el dispositivo para llevar a cabo una tarea, o cmo se notificar a la aplicacin las acciones del usuario. Se deben concentrar slo en el objetivo de la pantalla y en la tarea que permitir llevar a cabo. Sun recomienda en esta etapa que se haga un "story board" conteniendo en cada vieta los requerimientos para la pantalla correspondiente. En otra fase se decidir qu tipo de controles vamos a utilizar para realizar entradas de datos y cmo vamos a presentar la informacin. En este punto, las caractersticas generales en cuanto a pantalla del dispositivo pueden marcar claramente el tipo de diseo de interfaz: lo que en uno se puede disponer en una nica pantalla, en otro podremos necesitar varias. El almacenamiento persistente es un aspecto a tener en cuenta en nuestro diseo. La pregunta a responder es: qu datos deben sobrevivir a la finalizacin de la aplicacin y estar disponibles para la siguiente vez que se vaya a ejecutar? Otra cuestin, que no se debe plantear en esta fase sino en la de implementacin es qu utilizar para realizar ese almacenamiento. Una primera respuesta es aquel formato que se emplee para enviar y recibir datos entre el dispositivo J2ME y el sistema externo. Con esto evitamos una fase de conversin de formatos. Si el dispositivo posee sistemas de ficheros, entonces podemos optar por la creacin de un fichero con una estructura ms o menos compleja y usar las bibliotecas de Java para acceder a ellos. Otra alternativa tambin puede ser emplear sistemas de gestin de bases de datos relacionales, aunque en el caso de tener que tener que

almacenar un gran volumen de datos y realizar gran cantidad de accesos. Finalmente, debemos tener en cuenta dentro del diseo aspectos relacionados con la conectividad y con la entrada / salida, ya que son puntos muy importantes que van a determinar la portabilidad de la aplicacin. Por tanto, en este momento deberemos tomar decisiones en un nivel de abstraccin alto, que luego se concretarn cuando determinemos claramente el tipo de dispositivo y sus prestaciones.

Implementacin de la aplicacin.
Esta etapa vendr marcada por la eleccin del lenguaje, plataforma y herramientas de desarrollo (depuradores, entornos integrados,...). Con J2ME, teniendo en cuenta tipo de dispositivo con el que vamos a trabajar, decidiremos la configuracin y perfil ms adecuados. Los pasos a seguir en esta fase hasta instalar el programa en el dispositivo seran los siguientes: 1. Escritura del cdigo. 2. Compilacin de la aplicacin. 3. Eliminacin de informacin de clases innecesaria (obfuscate). Esta etapa es opcional y en ella se renombran clases, mtodos, interfaces, con objeto de hacerlo ambiguo. Un paquete obtenido de esta fase lo protege de la descompilacin y de la ingeniera inversa. Adems, reduce el tamao de los ficheros de clase, dando lugar a ficheros JAR ms pequeos. 4. Ejecucin del preverificador para aadir la informacin de "clase verificada" a los ficheros de clase. 5. Empaquetamiento de la aplicacin: creacin del fichero JAR y JAD. 6. Ejecucin en un emulador apropiado. 7. Instalacin en el dispositivo y ejecucin. En este caso existen dos modos de hacerlo: en el primero, se descargar la aplicacin a travs de una conexin de red, se cargar en memoria, se ejecutar la aplicacin, y finalmente se eliminar

cualquier traza de sta en el dispositivo; en la segunda, y siempre que el dispositivo lo permita, se instalar fsicamente. En el entorno J2ME, Java Application Manager (JAM) es un gestor que controla la descargar, instalacin, lanzamiento y desinstalacin de aplicaciones en el dispositivo.

Consejos para el desarrollo


Algunos consejos para desarrollar aplicaciones con J2ME pueden ser los siguientes: 1. Evite ejecutar tareas computancionalmente intensivas en el dispositivo. Cuando sea posible, la alternativa ms sencilla es hacer que una posible aplicacin servidora en una mquina servidora sea la haga el clculo y que la aplicacin que corre en el dispositivo slo se encargue de la gestin del interfaz y de mnimas operaciones.Simplifique la aplicacin, es decir, dejarla tan simple como sea posible, eliminando caractersticas superfluas. Esta decisin bsicamente debe realizarse en tiempo de diseo. Si se va la necesitar un requerimiento slo de vez en cuando, entonces lo mejor es desarrollar una segunda aplicacin auxiliar que la contenga, dando la oportunidad a los usuarios a que puedan eliminar dicha aplicacin si no la necesitan. 2. Escriba aplicaciones ms pequeas (Smaller is better) ya que consumir menos memoria, requerir menos tiempo de instalacin y de inicializacin al ser ejecutada. Un aspecto para alcanzar este fin es el de reducir el nmero de clases de la aplicacin. 3. Utilice menos memoria en tiempo de ejecucin. Para ello podemos considerar el uso de tipos escalares en sustitucin de objetos ms complejos siempre que sea posible, como son int y boolean, por ejemplo, ya que cada vez que construimos un tipo, el constructor entra en funcionamiento reservando el espacio de memoria requerido para alojarlo. Tambin otro consejo en este sentido es alojar objetos cuando realmente sea necesario (lazy instantiation). As, cuando vayamos a utilizar un objeto podemos preguntar previamente si ha sido creado o simplemente apunta a null. 4. Libere los recursos del programa tan pronto como se acaben de utilizar. Una vez que se finalice el uso de

5.

6.

7.

8.

9.

conexiones a bases de datos, a la red, a ficheros, etc., liberarlos, ya que dejaremos libre la memoria que implica su gestin y se pondrn a disposicin de otras aplicaciones. Reutilice objetos en lugar de continuamente crearlos y abandonarlos. La idea, por tanto, es escribir mtodos de inicializacin de objetos y tambin de dejarlos en un estado neutro para posteriormente poder emplearlos en otros menesteres. Evite excepciones cuando se pueda, ya que redundar en la reduccin del tamao de los ficheros de clase y el nmero de objetos que se alojen en memoria. Siempre que se pueda solventar el problema de otra forma es mejor. Utilice variables locales, ya que es ms lento acceder a un miembro de una clase que a una variable local. Por ejemplo, si accedemos a una variable miembro dentro de un bucle una y otra vez, ser conveniente asignar el miembro a una variable local, que se almacenar en la pila, y acceder continuamente a ella. Tambin es til esta tcnica para operar con elementos de un vector en vez de acceder directamente por medio del vector. Evite concatenacin de cadenas de caracteres debido a que se emplea un par de llamadas a mtodos de la clase String ms la del constructor correspondiente. Esto lo tenemos que tener ms en cuenta, an si cabe, si se hace en un bucle. Emplee hilos. Por norma general, todas aquellas operaciones que lleven ms de una dcima de segundo deberan ejecutarse en un hilo separado, de tal forma que no se bloquee el interfaz de usuario, aspecto muy importante en los dispositivos mviles.

Breve descripcin de los principales entornos integrados


Un entorno de desarrollo integrado (las siglas en ingls son IDE) tiene como objetivo mejorar la productividad del desarrollador ofrecindole un conjunto de herramientas totalmente cohesionadas entre s, a travs de un inferfaz grfico de usuario. Como mnimo, un IDE estar compuesto por un editor, un gestor de proyectos, un entorno de ejecucin y un

depurador. Si nos centramos en aquellos que soportan J2ME, stos deberan contemplar las siguientes herramientas:

Gestor de proyectos (ficheros fuente y atributos de los MIDlets). Editor (de cdigo y recursos). Construccin de ficheros de clases (compilacin, eliminacin de informacin necesaria y preverificacin del cdigo fuente). Generacin de paquetes (empaquetado de MIDlets en ficheros JAR y JAD). Emulacin (ejecucin de MIDlets en un emulador de dispositivo). Depurador de MIDlets. Documentacin y tutoriales, ya que al ser el desarrollo de aplicaciones J2ME un proceso complejo que integra muchos aspectos de Ingeniera del software, cualquier ayuda es poca en ese sentido.

Algunas otras caractersticas adicionales que pueden ser interesantes son:

Apoyo a la entrega de aplicaciones. J2ME Over-the-air (OTA) estandariza el proceso de bsqueda, descarga, autenticacin, verificacin y ejecucin de una aplicacin Java para un dispositivo mvil. Desarollo completo de aplicaciones, no slo la parte del dispositivo, que actuarn como clientes, sino los propios servidores que se ejecutarn en ordenadores de sobremesa. Herramientas RAD (Rapid Application Development), que permiten construir visualmente interfaces de usuario.

Hay que tener en cuenta que en el mercado de dispositivos mviles, cada vendedor tiene su propias herramientas de desarrollo, emuladores de dispositivos y aplicaciones para el anlisis del rendimiento. Algunos de los IDEs principales son:

J2ME Wireless ToolKit (J2MEWTK)

Contiene una implementacin de referencia de J2ME (MIDP) y mltiples emuladores de dispositivos. Este entorno de Sun se encuentra disponible para sistemas operativos de la familia Windows y Unix/Linux. En realidad no es un IDE como tal, pues no posee prestaciones de edicin y depuracin, que son imprescindibles. S contiene un mnimo entorno de desarrollo con un interfaz grfico para compilar, empaquetar y ejecutar aplicaciones MIDP.

JBuilder 7 Enterprise con MobilSet3

JBuilder es ya un entorno clsico dentro del desarrollo con Java para varias plataformas. Posee tres ediciones, de las cuales la ms completa es la Enterprise. Es precisamente sobre esta donde se fundamenta su uso con J2ME, ya que para desarrollar en este lenguaje para mviles hay que instalarse un mdulo adicional llamado MobileSet. Una vez instalado, aade prestaciones adicionales a JBuilder, como entornos de compilacin y ejecucin y ayudantes especficos.
Sun ONE Studio 4 Mobile Edition

Este entorno ofrece tres posibilidades: Community, Mobile y Enterprise. Las dos primeras son gratuitas. La versin Mobile tiene pocas prestaciones como IDE, aunque su diseo modular permite que terceros puedan desarrollar e integrar nuevos componentes.
Metrowerks CodeWarrior Wireless Studio 7

La edicin profesional incluye desde un Java 2 SDK hasta un gran nmero de emuladores de dispositivos y compiladores.

jVise from S5 System

Est basado en el proyecto Eclipse, el cual ofrece un conjunto de funcionalidades como IDE en un motor de ejecucin. Tanto vendedores como desarrolladores individuales pueden aadir caractersticas adicionales al entorno.

Entrega e instalacin de MIDlets


La entrega e instalacin de aplicaciones en dispositivos, as como su desinstalacin y eliminacin del sistema no viene determinada por la especificacin MIDP, ya que son muy especficas de cada dispositivo, aunque s hace referencia a un software llamado Application Management Software (AMS Software de gestin de aplicaciones), que es el que se encarga de estas tareas. Tanto el Wireless Toolkit como la edicin MIDP para PalmOS tiene sus propias implementaciones del gestor, permitiendo que el software se instale de dos formas diferentes:
Desde un ordenador local, por medio de una conexin de velocidad relativamente alta.

Esta forma es la tpica para los PDAs, pues normalmente viene asociadas a un ordenador porttil o de sobremesa con el que peridicamente se sincronizan. Este proceso consiste en trasladar los datos del usuarios desde el aparato al ordenador y enviar copias de software y tambin datos en la direccin contraria. El MIDP de PalmOS permite la instalacin de MIDlets suites durante la sincronizacin. Una vez que se han instalado, pueden ser se pueden ejecutar en el PDA como cualquier otra aplicacin.
Desde una red de ordenadores a la cual est el dispositivo conectada.

Este es el mtodo ms comn para telfonos mviles y dispositivos inalmbricos similares, aunque tambin la utilizan PDAs con conectividad a una red. Este proceso es el ya conocido como entrega Over-The-Air (OTA), lo que permite hacer la instalacin desde servidores HTTP. El proceso bsico es la instalacin de los MIDlet suites en un servidor web, ofreciendo hiperenlaces a ellos. Desde un telfono, el usuario activa ese enlace para bajrselo va WAP o

un micronavegador de Internet. Es decir, el que suministra el MIDlet escribe un a pgina como la siguiente y la cuelga en su web: <html> <body> <a HREF="miMIDPletSuite.jad"> pincha aqu </a> para bajarte el fichero. </body></html> El usuario del mvil se conecta a la pgina donde el fichero JAD se ha dejado y se lo baja. El fichero miMIDPletSuite.jad contendra algo parecido a esto: MIDlet-Name: miMIDPletSuite MIDlet-Jar-URL: http://miempresa.com/miMIDPletSuit.jar MIDlet-jar-Size: 8592 Una vez descargado en el mvil, el control pasa al software de gestin de aplicaciones del aparato, el cual muestra al usuario el contenido y ste decide si instalarlo o no. En este momento slo se ha descargado un fichero JAD de tamao pequeo. Si se decide instalar, la aplicacin AMS localiza el URL donde est el fichero JAR y la pide al servidor. Seguidamente pasa a instalarla. El AMS enva, una vez finalizado el proceso, un cdigo al servidor indicando si ha habido algn error o no, y en caso de haberlo, el tipo. El programa AMS tambin se encarga de realizar la actualizacin de MIDlet suites ya existentes. Como el fichero JAD tambin contiene la versin del software que se va a instalar, el gestor de aplicaciones determinar si es una versin ms moderna que la que ya hay en el dispositivo, en cuyo caso pide permiso al usuario para llevar a cabo su instalacin. Adems, debe permitir la seleccin de MIDlets y su posterior ejecucin. Por ltimo, tambin es el encargado de realizar la eliminacin del software a peticin del usuario. Los MIDlets no se pueden borrar individualmente, sino que se debe

liberar el almacenamiento persistente que se le asign al MIDlet suite.

Existen otras tecnologas Java, guiadas por sus propias especificaciones, que estn fuera de J2ME, para desarrollar aplicaciones en dispositivos distintos a los que se dedica J2ME. Veamos brevemente algunas de ellas.
JavaCard

La tecnologa JavaCard tiene por objeto permitir el desarrollo de aplicaciones en Java que puedan ser usadas en tarjetas inteligentes. Las principales complicaciones tienen que ver con lo limitado de los recursos de hardware, mientras que las ventajas se relacionan con la posibilidad de ocupar un lenguaje de alto nivel en un ambiente en que lo usual es programar en algn tipo de ensamblador difcil de depurar. Algunas tarjetas del estilo a las de crdito se les est dotando de un microprocesador o un chip de memoria. Algunas de estas tarjetas inteligentes "smart cards" poseen la capacidad de procesar, por s mismas, datos almacenados en ella. Otras necesitan la asistencia de un lector, pero contienen un repertorio de instrucciones para manipular los datos. Adems, no necesitan acceder a sistemas remotos, como es el caso de las de banda magntica. Tpicamente, las tarjetas tiene 1 Kbyte de memoria RAM, 16 Kbyte de EEPROM y 24 Kbytes de ROM. Las aplicaciones de estas tarjetas se estn extendiendo velozmente, ya que por ejemplo las estn utilizando ya varias entidades bancarias, gobiernos para sustituir tarjetas de identificacin o carnets de conducir o empresas de transporte para sustituir los sistemas actuales de tarjetas magnticas. JavaCard fue diseado para ofrecer una solucin fiable a la proteccin de datos y recursos mediante Java. Teniendo en cuenta el reducido entorno para el que ha sido pensado, JavaCard elimina ciertas construcciones de Java consideradas como demasiado complejas o no aplicables para la programacin de tarjetas inteligentes no son incorporadas y por otro lado se agregan facilidades especficas para el manejo

de transacciones con tarjetas inteligentes (atomicidad de un grupo de operaciones, objetos persistentes, etc.). Las polticas de seguridad de Java (conocidas como el sandbox model) que prohben cualquier interaccin entre objetos de diferentes applets fueron modificadas, y en algunos casos, debilitadas: JavaCard, por ejemplo, permite que un objeto sea compartido por diferentes applets. Cuando una tarjeta que contiene uno o varios applets se inserta o presenta de alguna forma a un lector de tarjetas, la mquina virtual de esta plataforma identifica el applet con el que se quiere comunicar y el lector le enva una serie de mandatos a ejecutar. La tecnologa JavaCard est compuesta por tres componentes: la mquina virtual (JCVM), el entorno de ejecucin (JCRE) -que acta como sistema operativo- y el API. La mquina virtual la forman un conversor, es decir, una mquina virtual fuera de la tarjeta (residente en un PC, por ejemplo) y otra intrprete que reside en la tarjeta. La primera convierte ficheros de clases de Java en los conocidos como Converted Applets, que son ejecutados por el intrprete.
EmbeddedJava

Este tipo de Java est dirigido a desarrollar aplicaciones relacionadas con el acceso a red, concretamente con la entrega de servicios bajo demanda. Para conseguirlo, un servidor de Java embebido se integra en cualquier dispositivo de red especfico, como por ejemplo, una pasarela, mquinas de venta en la calle, dispensadores de gasolina, automviles, de tal forma que el servicio se efecte a travs de la red. La mquina virtual no requiere ms de 500 Kbytes.
JavaPhone

Es un API desarrollado para dos tipos nuevos de telfonos: los telfonos inteligentes y los telfonos con pantalla para Internet. Los primeros conjugarn comunicaciones por voz, fax, correo electrnico, comunicacin va radio, paginacin, acceso a Internet, planificacin de tareas al estilo de los PDAs y muchas otras funciones que los telfonos mviles, PDAs y paginadores presentan. Los segundos, son pantallas de vdeo y opcionalmente teclados que permiten comunicaciones personales en Internet.

JavaPhone ofrece una biblioteca de clases para desarrollo de aplicaciones en estos telfonos futuristas.
Java TV

El API de Java para la televisin digital interactiva ofrece una plataforma para escribir programas Java para controlar la televisin y los "set-top boxes" creados para el entretenimiento digital, de manera que sean independientes de la tecnologa subyacente de emisin. Entre algunas de las aplicaciones podemos destacar la posibilidad de seleccionar la cmara desde la que queremos ver un partido de ftbol o una jugada concreta, o seleccionar vdeos o juegos bajo demanda. Java TV se compone de una mquina virtual Java estndar y varias bibliotecas del propio lenguaje Java y especficas.

Otras alternativas a la programacin con Java


Cuando la portabilidad, una de las principales requerimientos que nos hace elegir Java como plataforma de programacin de dispositivos mviles, no es primordial, entonces podemos utilizar otras alternativas. Otros motivos que nos pueden inducir a no tomar Java como la plataforma idnea para nuestros desarrollos es que los desarrolladores tienen que esperar en ocasiones a que se desarrolle la mquina virtual y un API para el dispositivo con el que tenemos que trabajar, y unas veces podremos esperar, pero otras no. Tambin tenemos que tener en cuenta el rendimiento que debe ofrecer nuestra aplicacin porque con Java, la mquina virtual tiene que interpretar realmente un programa en byte-code en tiempo de ejecucin, con la consiguiente prdida de velocidad. Si necesitamos mxima velocidad de ejecucin, quiz Java no sea la mejor opcin y tenemos que buscar alguna otra alternativa. Entre estas destacamos:
WAP y WML

Cuando no se necesite ningn procesamiento ni almacenamiento en el dispositivo una buena opcin es el empleo del Wireless Application Protocol (WAP) junto con el Wireless Markup Language (WML). WAP es un conjunto de especificaciones para construir aplicaciones basadas en web para redes inalmbricas. WML es la parte de WAP que

especifica el formato de la informacin para que pueda ser transferida entre dispositivos. WAP se basa en parte en Internet para trasladar la informacin a las pantallas de los telfonos mviles o PDAs, dotados estos con navegadores WAP.
Otros lenguajes

La mayora del software escrito hoy en da no emplea Java, sino que lenguajes como C++, C o Visual Basic se presentan como los ms populares para estas tareas. Las compaas han desarrollado completos entornos integrados para estos lenguajes en diferentes sistemas operativos como Windows CE o Palm OS. Otro lenguaje que est teniendo bastante xito es SuperWaba, tambin dedicado a la programacin de dispositivos pequeos. Define un lenguaje, una mquina virtual, un formato de ficheros .class y un conjunto de clases base. SuperWaba desciende de Waba y es compatible con esta. La sintaxis de los programas escritos para SuperWaba es un subconjunto del lenguaje Java, lo que permite que los desarrolladores que estn familiarizados con Java puedan comenzar rpidamente a utilizar el SuperWaba. El formato de los ficheros clase (.class) de SuperWaba son tambin subconjuntos del formato Java. Sin embargo, SuperWaba no deriva de Java ni tiene que ver con Sun Microsystems. El lenguaje definido por SuperWaba, su mquina virtual y el formato de los ficheros clase han sido diseados de forma tal que sean ptimos para su uso en PDAs. Las caractersticas de Java que usaban mucha memoria o que eran innecesarias para los PDA's han sido omitidas en el diseo del lenguaje y su mquina virtual.

En el resto del curso


Breve descripcin de cada una de las partes.
Herramientas y entornos de desarrollo

En este tutorial se considerarn las herramientas bsicas de desarrollo de aplicaciones JAVA para dispositivos mviles. Comenzaremos dando una visin de las herramientas bsicas, para considerar, en ltimo lugar, algunas de las herramientas

integradas disponibles para los desarrolladores. Analizaremos, en primer lugar, la programacin de ms bajo nivel, interactuando con la mquina virtual de CLDC. A continuacin estudiaremos la programacin de MIDlets, mediante MIDP. En ambos casos, se estudiar inicialmente la forma de operar desde comandos, para describir, a continuacin, la operativa mediante entornos de desarrollo de libre disposicin.

Introduccin a Java

En seccin 1, se hace una breve introduccin al lenguaje Java, haciendo referencia a su origen, historia, relacin con Internet, el significado del bytecode, y sus caractersticas ms importantes. Se sigue con una introduccin al paradigma de la programacin orientada a objetos en que se basa Java. Se termina presentado como crear el primer programa con CLDC, que es la configuracin en la que se basan los dispositvos mviles de menor capacidad. En seccin 2 presentamos los tipos de datos bsicos del lenguaje Java, analizando como se definen variables y arrays o matrices de estos tipos bsicos. En seccin 3 presentamos brevemente los operadores de Java, prcticamente iguales a los de C++. En seccin 4 presentamos las estructuras de control disponibles en Java, de nuevo prcticamente iguales a las de C++. En la seccin 5 estudiamos el concepto de clase en Java, analizando como se construyen, los constructores, las variables de clase, los mtodos, como se crean objetos de la clase, etc. En la seccin 6 analizamos puntos importantes en la definicin de los mtodos de una clase, como la sobrecarga, el paso de parmetros de los mtodos (por valor, por referencia), los especificadores de control de acceso (public, private, etc), as como los modificadores static y final. Se hace tambin una breve introduccin de la clase java.lang.String. En la seccin 7 se estudia la herencia, estudiando concepto asociados como la sobreescritura de mtodos, polimorfismo en tiempo de ejecucin, clases abstractas, el especificador de control de acceso protected. En la seccin 8 se estudia el tema de la definicin de paquetes de clases y el de la creacin de interfaces, que son algo similar a las clases, pero en donde los mtodos no tienen cuerpo, slo su definicin. La seccin 9 trata del tema de la gestin de excepciones. Se analiza las principales excepciones existentes en CLDC, como capturarlas,

como lanzar excepciones explcitamente, y como crear nuestros propios tipos de excepciones. La seccin 10 estudia el tema de la programacin multihebra. Veremos como crear programas con ms de una hebra de ejecucin, y aprender a usar los principales mtodos de la clase Thread, as como otros mtodos de la clase Object (wait(), notify(), notifyAll()) que se usan para que dos hebras puedan comunicarse. Aprenderemos tambin a sincronizar hebras.
CLDC

Comenzaremos a implementar un programa con la biblioteca de CLDC, que corresponde al famoso juego de la serpiente (Snake o nibbles). El interfaz grfico de este juego se construir cuando se estudie el perfil MIDP. La seccin 11 retoma el concepto de CLDC, que como hemos dicho antes es la configuracin disponible para pequeos dispositivos. Se har un repaso a la biblioteca de clases que contiene CLDC haciendo nfasis en las clases que no se han visto anteriormente. La biblioteca de clases de CLDC se divide en los paquetes: java.lang, java.util, java.io y javax.microedition.io.

MIDP

En este parte del curso enpezaremos a ver la Interfaz de Programacin de Aplicaciones (API) de MIDP, explicando las clases ms importantes de su jerarqua. Primero nos centraremos en el ciclo de vida de un Midlet y como tratarlo, adems de unas cuantas generalidades de la programacin de los mismo. Posteriormente veremos cmo realizar el interfaz de nuestros Midlet, tanto en el manejo de la pantalla, como en el manejo de las entradas de usuario. Veremos que la parte de interfaces de usuario de MIDP se puede distinguir en dos partes claramente diferencias, cada uno con su estilo y finalida propios: La primera parte es el API de alto nivel para interfaces de usuario que nos va a permitir desarrollar Midlets utilizando clases para el interfaz, es una forma de programar muy fcil y rpida, pero no tenemos apenas control sobre la pantalla del dispositivo o las entradas que se produzcan. En la segunda parte estudiaremos el API de bajo nivel para interfaces de usuario, que nos va a permitir programar Midlet

con un control total de la pantalla y entrada de datos del dispositivo. Esta forma de trabajar ser ms compleja, pues nos tendremos que preocupar a nivel de detalle de pixel o de tecla pulsada, sin embargo, nos permite un control mayor del dispositivo.

MIDP (Continuacin)

En este mdulo trataremos la gestin de la conexin a redes en J2ME. Hay tres formas de realizar transmisin de informacin contempladas en CLDC y MIDP: por sockets, datagramas y por HTTP. Veremos un resumen de las tres con sus ventajas e inconvenientes, centrandonos finalmente en la conexin por HTTP, que es el tipo que est completamente contemplado en los estndares. Finalmente se estudiar el almacenamiento persistente en J2ME. MIDP nos proporciona APIS para crear y manejar almacenes de registros. Una especie de bases de datos especialmente creadas para las caractersticas de los dispositivos mviles -escasos recursos-. Veremos como dentro de un almacn (tabla de una BD) podemos crear y manejar los registros (tuplas).

Aplicaciones

Finalmente, se pondrn en prctica los conocimientos adquiridos en el curso, realizando una aplicacin para telfono mvil o PDA.

Java Micro Edition


La plataforma Java Micro Edition (Java ME), o anteriormente Java 2 Micro Edition (J2ME), es una especificacin de un subconjunto de la plataforma Java orientada a proveer una coleccin certificada de APIs de desarrollo de software para dispositivos con recursos restringidos. Est orientado a productos de consumo como PDAs, telfonos mviles o electrodomsticos. Java ME se ha convertido en una buena opcin para crear juegos en telfonos mviles debido a que se puede emular en

un PC durante la fase de desarrollo y luego subirlos fcilmente al telfono. Al utilizar tecnologas Java el desarrollo de aplicaciones o videojuegos con estas APIs resulta bastante econmico de portar a otros dispositivos. Java ME fue desarrollado mediante el Java Community Process bajo la especificacin JSR 68. La evolucin de la plataforma ha propiciado el abandono de las Java Specification Request (peticiones de especificacin para Java) en favor de JSRs separadas para las distintas versiones de Java ME.

Qu es J2ME o Java ME?


Java Platform, Micro Edition (Java ME) ofrece un entorno flexible y slido para aplicaciones que se ejecutan en dispositivos mviles e integrados: telfonos mviles, TDT, reproductores Blu-ray, dispositivos multimedia digitales, mdulos M2M, impresoras y mucho ms. La tecnologa Java ME se cre originalmente para paliar las limitaciones asociadas a la creacin de aplicaciones para pequeos dispositivos. Con este fin Oracle ha definido los fundamentos de la tecnologa Java ME para adaptarse a entornos limitados y hacer posible la creacin de aplicaciones Java que se ejecuten en pequeos dispositivos con memoria, visualizacin y potencia limitadas.

Java Platform, Micro Edition


From Wikipedia, the free encyclopedia Jump to: navigation, search

Java Editions

Java Card

Micro Edition (ME)

Standard Edition (SE)

Enterprise Edition (EE)

JavaFX

PersonalJava (discontinued)

Java Platform, Micro Edition, or Java ME, is a Java platform designed for embedded systems (mobile devices are one kind of such systems). Target devices range from industrial controls to mobile phones (especially feature phones) and set-top boxes. Java ME was formerly known as Java 2 Platform, Micro Edition (J2ME). Java ME was designed by Sun Microsystems, acquired by Oracle Corporation in 2010; the platform replaced a similar technology, PersonalJava. Originally developed under the Java Community Process as JSR 68, the different flavors of Java ME have evolved in separate JSRs. Sun provides a reference implementation of the specification, but has tended not to provide free binary implementations of its Java ME runtime environment for mobile devices, rather relying on third parties to provide their own. As of 22 December 2006, the Java ME source code is licensed under the GNU General Public License, and is released under the project name phoneME. As of 2008, all Java ME platforms are currently restricted to JRE 1.3 features and use that version of the class file format (internally known as version 47.0). Should Oracle ever declare a new round of Java ME configuration versions that support the later class file formats and language features, such as those corresponding JRE 1.5 or 1.6 (notably, generics), it will entail extra work on the part of all platform vendors to update their JREs. Java ME devices implement a profile. The most common of these are the Mobile Information Device Profile aimed at mobile devices, such as cell phones, and the Personal Profile aimed at consumer products and embedded devices like settop boxes and PDAs. Profiles are subsets of configurations, of

which there are currently two: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC).[1] There are more than 2.1 billion Java ME enabled mobile phones and PDAs.[2] Although it not used on some of today's newest mobile platforms (e.g. iPhone, Windows Phone 7, BlackBerry 10, Android), it continues to be very popular in sub $200 devices such as Nokia's Series 40. It is also used on new Bada operating system and on Symbian OS along with native software.