SIGATEX Móvil
SIG para dispositivos móviles
de la Junta de Extremadura
Alumno: Alberto Romeu Carrasco ([email protected])
Director: Miguel Montesinos – Prodevelop ([email protected]) Tutor: Vicente Pelechano – DSIC (UPV) ([email protected])
1. Presentación del proyecto
1.1 Introducción
Para comprender mejor el proyecto que nos ocupa es conveniente situarlo dentro del marco del sistema de información geográfica de la Consejería de Cultura y Turismo de la Junta de Extremadura, describir brevemente cuáles son los componentes del mismo y la relación entre ellos.
1.2 Sistemas de información geográfica
Un Sistema de Información Geográfica (SIG o GIS, en su acrónimo inglés) es una integración organizada de hardware, software y datos geográficos diseñado para capturar, almacenar, manipular, analizar y desplegar en todas sus formas la información geográficamente referenciada con el fin de resolver problemas complejos de planificación y gestión. También puede definirse como un modelo de una parte de la realidad referido a un sistema de coordenadas terrestre y construido para satisfacer unas necesidades concretas de información.
En el sentido más estricto, es cualquier sistema de información capaz de integrar, almacenar, editar, analizar, compartir y mostrar la información geográficamente referenciada. En un sentido más genérico, los SIG son herramientas que permiten a los usuarios crear consultas interactivas, analizar la información espacial, editar datos, mapas y presentar los resultados de todas estas operaciones.
1.3 Adaptación del SIG de la Consejería de Cultura yTurismo
El proyecto actual forma parte de la adaptación del sistema de información geográfica de la Consejería de Cultura y Turismo de Extremadura, que tiene como objetivo principal difundir el conocimiento sobre los recursos e infraestructuras turísticas de Extremadura a través del software libre.
El sistema de información geográfica consta de varios subsistemas, uno de los cuales es el proyecto que se describe en este documento.
1.4 Descripción informal del subsistema móvil
El subsistema móvil consiste en una aplicación para dispositivos móviles (en general, teléfonos), dirigida a turistas que visiten la comunidad de
Extremadura y que permitirá visualizar y navegar por la cartografía de la comunidad, establecer rutas entre varios puntos, visualizar y obtener información sobre puntos de interés cultural para el visitante y localizar al visitante sobre el mapa mediante GPS.
1.5 Organización del documento
El documento se divide en los siguientes capítulos:
• Componentes del sistema de información geográfica: Se describen los distintos subsistemas de que consta el sistema de información geográfica de la Junta de Extremadura y el papel del subsistema móvil.
• Análisis de requisitos: Utilizando casos de uso UML describiremos la funcionalidad de la aplicación móvil.
• Arquitectura de la aplicación: Se utilizará un diagrama de bloques informal para describir los distintos componentes de la arquitectura diseñada y que guiará la narración durante el resto del documento.
• Tecnología para el desarrollo de aplicaciones para dispositivos móviles: Se hace un repaso a la tecnología J2ME, qué perfil y qué configuración son necesarios para teléfonos móviles, cuáles son las principales ventajas e inconvenientes de esta tecnología y una recopilación de buenas prácticas para el desarrollo de aplicaciones para dispositivos móviles.
• Desarrollo de interfaces de usuario para dispositivos móviles: Un reto importante a superar durante el desarrollo es la fragmentación de dispositivo en cuanto a interfaces de usuario, para ello se estudiará y aplicará LWUIT (Light Weight User Interface Toolkit), como solución libre a este problema.
• Desarrollo de la aplicación: Se analizará el diseño de los distintos casos de uso, apoyándonos en el diagrama de la arquitectura de la aplicación y estudiando para cada caso de uso, qué tecnología se adecúa mejor a las necesidades concretas de los dispositivos móviles.
• Despliegue de la aplicación: En este capítulo se explicará el proceso de obtención de archivos binarios ejecutables sobre un teléfono móvil a partir del código fuente desarrollado.
• Manual de usuario: Se describe la funcionalidad de la aplicación a nivel de usuario.
• Manual de instalación: Cómo instalar la aplicación sobre un teléfono móvil, una BlackBerry o una PDA con Windows Mobile.
• Requisitos del teléfono y testing: Cuáles son los requisitos mínimos que un dispositivo debe cumplir para poder utilizar la aplicación y cuál ha sido el resultado de probar la aplicación sobre diferentes dispositivos.
• Conclusiones y ‘future work’: Tras la experiencia adquirida en el desarrollo de aplicaciones para teléfonos móviles se comentan las conclusiones extraídas y cuál es el siguiente paso en cuanto al desarrollo de sistemas de información geográfica para teléfonos.
• Apéndices e índices: Por último, se adjuntan varios apéndices con información extra y varios índices de tablas, diagramas, etc.
2. Componentes del Sistema de Información Geográfica
2.0 Introducción
En este capítulo se sitúa el proyecto dentro del contexto del Sistema de información geográfica de la Junta de Extremadura, explicando los distintos componentes que lo forman.
2.1 Descripción de componentes
El SIG de la Consejería consta de 5 subsistemas:
Cartografía: Toma de datos y adaptación de la cartografía a utilizar en el proyecto.
Inventario: Repositorio de información (base de datos), y aplicación de acceso a esos datos alfanuméricos.
Visor Web: Cliente ligero de mapas embebible en cualquier aplicación Web del Portal de la Consejería.
Rutas: Sistemas de cálculo de rutas, que sirve peticiones al visor Web y al subsistema móvil.
Móvil: Aplicación visor de mapas en teléfonos móviles.
Así pues, nuestro proyecto se corresponde con el subsistema móvil.
2.2 Diagrama de componentes
A continuación se muestra un diagrama con la relación existente entre los distintos componentes del sistema de información.
Diagrama 1 - Componentes del sistema de información geográfica de la Junta de Extremadura
El subsistema Visor Web se divide en Visor Web propiamente dicho (la aplicación cliente Web de mapas) y el Servidor de Mapas para clarificar la interacción entre este subsistema y el subsistema Móvil.
Se añade como componente la Base de Datos utilizado por diferentes subsistemas. Cartografía será responsable de configurar y cargar la base de datos cartográfica del sistema.
2.3 Interacción y dependencia con otros subsistemas
Como podemos ver en el diagrama de componentes de la figura 1, el subsistema móvil depende directamente del servidor de mapas (para acceder a cartografía) y del subsistema de rutas que nos permitirá acceder al cálculo de rutas. De nuestra aplicación no depende ningún otro subsistema.
3. Análisis de requisitos
3.1 Introducción
Para el análisis de requisitos de la aplicación se utilizan diagramas de casos de uso UML, adjuntando para cada uno una plantilla textual donde se explica su funcionalidad.
3.2 Diagrama UML de casos de uso
Diagrama 2 - Diagrama UML de casos de uso
Como podemos ver en el diagrama de casos de uso la aplicación consta de quince casos de uso, que se podrían agrupar en tres grupos:
1. Casos de uso de rutas: Son los que tienen que ver con el cálculo de rutas, selección de puntos e indicaciones.
2. Casos de uso de cartografía: Son visualizar mapa, centrar en mapa, obtener localización y detener GPS.
3. Casos de uso de puntos de interés: Buscar POI y Consultar información.
3.3 Actores
La aplicación sólo tendrá un actor, pero es importante conocer el perfil de éste para adecuarla a sus necesidades. Se trata de personas que
visitan la comunidad de Extremadura y generalmente, se descargarán la aplicación desde Internet. Por ello, es importante que el proceso de instalación sea sencillo.
Dada la naturaleza de los usuarios es posible que utilicen la aplicación en contadas ocasiones, quizás una única vez durante su visita, así pues, es importante liberar al usuario de cualquier proceso de configuración o entrada de datos complejos que haría que perdiera el interés. Toda la información deberá estar accesible de manera cómoda y rápida.
Al mismo tiempo, el usuario va a estar familiarizado con el uso de su dispositivo móvil, por tanto, la aplicación deberá adecuarse al máximo a las características de su dispositivo y el acceso a las funcionalidades ha de ser intuitivo.
3.4 Descripción de casos de uso
3.4.1 Caso Uso Anular Ruta
Descripción
El turista, desde su aplicación solicita anular una ruta existente, o bien la aplicación detecta que ésta ha de anularse.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
• Una ruta ha sido calculada y representada en la aplicación.
Post-condiciones
• No existe ruta calculada y la aplicación se encuentra (desde el punto de vista de las rutas) como al iniciarse.
Escenario principal
El turista, desde la aplicación, selecciona la opción Anular Ruta. El estado de la ruta finaliza, eliminándose también cualquier punto establecido (partida, destino o paso) lo que es equivalente a restablecerse a Ruta Vacía (ver Máquina de Estados de Ruta).
La ruta se elimina de la pantalla limpiando gráficamente.
3.4.2 Caso Uso Consultar Información
Descripción
El turista, desde su aplicación consulta información alfanumérica sobre un elemento mostrado en pantalla.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
• El turista debe encontrarse en un nivel de zoom sobre el mapa, en el cual se muestren puntos de interés.
Post-condiciones
• Se muestra una lista con los atributos alfanuméricos del (los) elemento(s) cercano(s) al centro de la pantalla. Además se mostrará un icono representativo de la categoría correspondiente a cada punto de interés.
Escenario principal
El turista, desde la aplicación, accede al menú de consultar información. La aplicación comprueba si se encuentra en un nivel de zoom en el que se pueda consultar información y recupera los datos de los puntos de interés cercanos al centro (a un radio de 50 píxeles).
Una vez realizada la búsqueda, la aplicación muestra un mensaje indicando el número de elementos encontrados y a continuación una ventana con una lista de todos aquellos elementos encontrados mostrando un icono representativo de la categoría, la descripción del punto de interés y la distancia al centro. El listado deberá aparecer ordenado por distancia al centro de la pantalla, de más cercano a menos cercano y contendrá como máximo los 50 primeros elementos encontrados.
Excepciones
• Si el usuario se encuentra en un nivel de zoom en el que no aparecen puntos de interés se le informará de que no se ha encontrado información.
• Si el resultado de la petición de información es nulo (no se ha encontrado ningún elemento a una distancia pixel solicitado), se
le mostrará un mensaje descriptivo al usuario, recordándole que la petición se realiza sobre el centro de la pantalla, y recomendándole que se desplace hasta situar el elemento a consultar en el centro de la pantalla.
• En caso de que la consulta de información devuelva más de 50 elementos, se mostrará un mensaje al usuario indicando que se muestran únicamente los 50 primeros resultados.
3.4.3 Caso Uso Eliminar Punto de Paso de Ruta
Descripción
El turista, desde su aplicación elimina un punto de paso de ruta.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
• Se deben haber establecido previamente puntos de paso de ruta. El usuario había dado la orden de eliminar un punto de paso en el caso de uso Selección de Puntos para Ruta
Post-condiciones
• Se actualiza el conjunto de puntos de paso y el estado de la ruta si se ve afectado.
• No se calcula una nueva ruta. Se hará cuando el usuario expresamente así lo indique.
Escenario principal
Tras recibir la orden de eliminar un punto de paso, se borra del conjunto de puntos de paso y se actualiza el estado de la ruta si ha cambiado.
3.4.4 Caso Uso Establecer Punto de Paso de Ruta
Descripción
El turista, desde su aplicación define un punto de paso intermedio de una ruta. Por punto intermedio se entiende aquél que no es necesariamente el origen o fin de la ruta. Utilizado para el cálculo de ruta pasando por N puntos.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
Post-condiciones
• Se dispone de un punto de paso de ruta en memoria, y se actualiza el estado interno de la ruta.
Escenario principal
El turista, desde la aplicación, selecciona la opción de menú Ruta pasando por aquí y la aplicación obtiene las coordenadas locales (X, Y) y muestra un icono representativo de punto de paso sobre el centro de la pantalla.
No se llama a Selección de Puntos para Ruta. Lo deberá hacer posteriormente de forma manual el usuario cuando haya finalizado de establecer todos los puntos de paso.
Escenario alternativo 1
El usuario, estando consultando un elemento con X-Y, como una ficha de información de un POI (Punto de Interés), selecciona la opción de menú Establecer como paso de ruta. La aplicación realiza el mismo proceso que en el caso de seleccionar el punto central de la pantalla.
Escenario alternativo 2
El usuario, estando en la ventana de Seleccionar Puntos para Ruta, había seleccionado la opción Añadir punto de paso. La aplicación le muestra el mapa habilitando una opción del teléfono Seleccionar, para que el usuario navegue (zooms, pans) y ejecute dicha opción seleccionándose el punto central de la pantalla (ojo, debe haber icono
Una vez seleccionado el punto, se debe mostrar un icono representativo de punto de paso sobre el centro de la pantalla, y automáticamente se volverá a abrir la ventana de Seleccionar Puntos para Ruta, con el Punto de Paso ya añadido.
En este escenario se deberá controlar que no se produzca re-centrado por nuevas posiciones del GPS hasta que el usuario seleccione la posición.
3.4.5 Caso Uso Establecer Punto Fin de Ruta
Descripción
El turista, desde su aplicación define el punto de destino (fin) de una ruta.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
Post-condiciones
• Se dispone de un punto destino de ruta en memoria, y se actualiza el estado interno de la ruta.
Si ya se disponía de Punto de Partida, el resultado de actualizar el estado interno de la ruta será realizar una llamada a Selección de Tipo de Ruta.
Escenario principal
El turista, desde la aplicación, selecciona la opción de menú Ruta hasta aquí y la aplicación obtiene las coordenadas locales (X, Y) y muestra un icono representativo de punto de destino sobre el centro de la pantalla.
Si ya se había establecido previamente un punto de partida (tanto si no había punto de destino, como si ya lo había -y por tanto ruta calculada- ), se calcula automáticamente la ruta llamando al caso de uso de Selección de Tipo de Ruta.
Escenario alternativo 1
El usuario, estando consultando un elemento con X-Y, como una ficha de información de un POI (Punto de Interés), selecciona la opción de menú Establecer como fin de ruta. La aplicación realiza el mismo proceso que en el caso de seleccionar el punto central de la pantalla.
Escenario alternativo 2
El usuario, estando en la ventana de Seleccionar Puntos para Ruta (ver caso de uso Selección de Puntos para Ruta), había seleccionado la
aplicación le muestra el mapa habilitando una opción del teléfono Seleccionar, para que el usuario navegue (zooms, pans) y ejecute dicha opción seleccionándose el punto central de la pantalla (ojo, debe haber icono en el centro).
Una vez seleccionado el punto, se debe mostrar un icono representativo de punto de destino sobre el centro de la pantalla, y automáticamente se volverá a abrir la ventana de Seleccionar Puntos para Ruta, con el Punto de Destino ya seleccionado.
3.4.6 Caso Uso Establecer Punto Inicio de Ruta
Descripción
El turista, desde su aplicación define el punto de partida (inicio) de una ruta.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
Post-condiciones
• Se dispone de un punto origen de ruta en memoria, y se actualiza el estado interno de la ruta.
• Si ya se disponía de Punto de Destino, el resultado de actualizar el estado interno de la ruta será realizar una llamada a Selección de Tipo de Ruta.
Escenario principal
El turista, desde la aplicación, selecciona la opción de menú Ruta desde aquí y la aplicación obtiene las coordenadas locales (X, Y) y muestra un icono representativo de punto de inicio sobre el centro de la pantalla.
Si ya se había establecido previamente un punto de destino (tanto si no había punto de partida, como si ya lo había -y por tanto ruta calculada- ), se calcula automáticamente la ruta llamando al caso de uso de Selección de Tipo de Ruta.
Escenario alternativo 1
El usuario, estando consultando un elemento con X-Y, como una ficha de información de un POI (Punto de Interés), selecciona la opción de menú Establecer como inicio de ruta. La aplicación realiza el mismo proceso que en el caso de seleccionar el punto central de la pantalla.
Escenario alternativo 2
El usuario, estando en la ventana de Seleccionar Puntos para Ruta (ver caso de uso Selección de Puntos para Ruta), había seleccionado la
le muestra el mapa habilitando una opción del teléfono Seleccionar, para que el usuario navegue (zooms, pans) y ejecute dicha opción seleccionándose el punto central de la pantalla (ojo, debe haber icono en el centro).
Una vez seleccionado el punto, se debe mostrar un icono representativo de punto de inicio sobre el centro de la pantalla, y automáticamente se volverá a abrir la ventana de Seleccionar Puntos para Ruta, con el Punto de Partida ya seleccionado.
En este escenario se deberá controlar que no se produzca re-centrado por nuevas posiciones del GPS hasta que el usuario seleccione la posición.
3.4.7 Caso Uso Obtener Indicaciones Ruta
Descripción
El turista, desde su aplicación solicita las instrucciones de una ruta ya obtenida.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
• Previamente se ha solicitado un cálculo de ruta (entre 2 puntos o pasando por N puntos), con resultado positivo. Como resultado de ese cálculo, el servidor ha devuelto un identificador de la ruta.
Post-condiciones
• Se muestran al usuario las instrucciones de la ruta en pantalla.
Escenario principal
El turista, tras haber calculado un ruta (ver caso de uso Selección de Puntos para Ruta), y verla gráficamente en pantalla, con el menú activa la opción de Obtener indicaciones. La aplicación obtendrá las indicaciones de la ruta a partir de los atributos de las geometrías de la ruta que se obtienen al solicitar la ruta al servidor.
Una vez calculadas las indicaciones, se mostrará una ventana indicando el origen y destino de la ruta, los pasos intermedios y su coste.
Excepciones
La ruta ha sido anulada previamente. En este caso, la opción de menú debería estar desactivada, y no se debería permitir entrar en este caso de uso
3.4.8 Caso Uso Obtener Localización
Descripción
El turista, con su teléfono móvil obtiene su posición actual utilizando el receptor GPS interno del teléfono.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación en funcionamiento en su teléfono móvil y un receptor interno GPS.
Post-condiciones
• Se centra el mapa en la localización del usuario.
Escenario principal
El turista tiene la aplicación abierta. Activa desde un menú la opción de Obtener localización. La aplicación se conecta al GPS, indica el estado de la conexión mediante un icono, y cuando se ha fijado posición (se tienen coordenadas), se re-centra el mapa y, en su caso, se solicitan los mapas necesarios de fondo al servidor.
La localización se muestra mediante un símbolo (tipo cruz o similar), y se mantiene activa hasta que el usuario desactiva la conexión con el GPS.
De forma periódica, la posición se va actualizando, realizando desplazamientos sobre el mapa con las sucesivas posiciones.
Excepciones
Si el teléfono no cuenta con un receptor GPS interno o no es posible establecer la conexión por motivos de hardware, mostrar un mensaje al usuario advirtiendo de tal situación.
3.4.9 Caso Uso Mostrar POIs
Descripción
El turista, desde su aplicación al navegar sobre el mapa puede visualizar los iconos representativos de las categorías de los puntos de interés sobre su posición real sobre el mapa.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación en funcionamiento en su teléfono móvil.
Post-condiciones
• Se muestran en el mapa iconos representativos de cada categoría de puntos de interés.
Escenario principal
El turista tiene la aplicación abierta. Al hacer zoom sobre el mapa o navegar desplazándolo, se encuentra en el nivel máximo o el nivel anterior al máximo. La aplicación realiza una búsqueda de puntos de interés contenidos en la extensión de la pantalla. Si encuentra puntos de interés los pinta en la pantalla.
3.4.10 Caso Uso Buscar POIs
Descripción
El turista, desde su aplicación solicita buscar puntos de interés (POIs - Points Of Interest-) cercanos a la posición central del mapa.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación en funcionamiento en su teléfono móvil.
Post-condiciones
• Se muestran un listado con los 50 primeros puntos de interés encontrados.
Escenario principal
El turista tiene la aplicación abierta y solicita buscar puntos de interés. Se le muestra una pantalla donde puede seleccionar la categoría por la que quiere filtrar o todas y una caja de texto donde introducir la descripción a buscar. En caso de dejarla en blanco se buscará cualquier descripción. Los puntos de interés encontrados se mostrarán en un listado.
Excepciones
Si no se encuentran puntos de interés que cumplan con el filtro se mostrará un mensaje informando al usuario.
3.4.11 Caso Uso Selección de Puntos para Ruta
Descripción
El turista, desde su aplicación solicita la opción de menú selección puntos de ruta.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
Post-condiciones
• Se muestra una ventana con todos los puntos seleccionados para formar parte de una ruta.
Escenario principal
Al turista se le muestra automáticamente una pantalla con una lista de 3 elementos:
• Punto de partida/inicio. Si ha marcado previamente el punto de inicio, aparece un icono representativo y las coordenadas del punto. Si no, aparece un botón con un texto para que el usuario seleccione el punto de inicio.
• Puntos de paso. Si ha definido uno o más puntos de paso, se le muestra una lista donde para cada punto de paso marcado le aparece un icono representativo y las coordenadas de cada punto.
• Punto de destino/fin. Si ha marcado previamente el punto de destino, aparece un icono representativo y las coordenadas del punto. Sino, aparece un botón con un texto para que el usuario seleccione el punto de destino.
Esta pantalla debe contener opciones de menú para añadir/eliminar puntos de ruta, de acuerdo a los casos de uso relacionados con rutas.
Es decir, si por ejemplo el punto de partida está vacío, se le muestra al usuario el texto Selecccionar ubicación, siendo éste un texto seleccionable (con puntero o botón central). Al ordenar (seleccionar el texto) Seleccionar ubicación se llamará al caso de uso Establecer Punto Inicio de Ruta o Establecer Punto Fin de Ruta, según se haya
En el caso de los puntos de paso, cuando se coloque el foco sobre alguno, se habilitará el comando ‘Eliminar punto de paso’ que llamará al caso de uso Eliminar Punto de Paso de Ruta.
Hay que comprobar el cumplimiento de la máquina de estados de una ruta.
A modo de resumen, las combinaciones que debe permitir la aplicación para permitir cálculo de ruta entre dos puntos o pasando por N puntos son:
La ventana debe contener bajo la lista de puntos un selección del tipo de ruta:
• A pie (valor por defecto).
• En coche.
A continuación la aplicación realizará la solicitud de cálculo de rutas al servidor, pasando los puntos y el tipo de ruta, y le indicará la usuario que la solicitud está en curso (mediante un icono animado, un mensaje...).
El tipo de cálculo de ruta solicitado será uno de los dos siguientes:
• Ruta entre 2 puntos. Cuando existan el punto de partida y el de destino. O bien cuando exista el punto de partida y sólo uno de paso.
• Ruta pasando por N puntos. Cuando exista el punto de partida y al menos dos puntos de paso.
Las 2 opciones de menú activas en esta pantalla son:
• Calcular. Llama a calcular la ruta.
• Volver. Vuelve a la pantalla de Selección de puntos de ruta.
Excepción
Si al dar la orden de Calcular, no hay un conjunto de puntos suficiente, tal como se ha descrito arriba (punto partida + destino/paso, o punto partida + n puntos de paso), se informará de que no hay puntos suficientes para calcular la ruta, volviendo a la pantalla con la lista de puntos.
3.4.12 Caso Uso Calcular Ruta
Descripción
El turista, desde su aplicación solicita calcular ruta.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación instalada y en funcionamiento.
• Previamente se han seleccionado un número suficiente de puntos para poder calcular una ruta.
Post-condiciones
• Se obtiene del servidor la ruta solicitada y se pinta en pantalla.
Escenario principal
El turista, desde la aplicación, marca el punto de inicio y al menos otro punto de ruta. La aplicación muestra una pantalla para que el usuario seleccione el tipo de ruta:
• A pie.
• En coche.
A continuación la aplicación realizará la solicitud de cálculo de rutas al servidor, pasando los puntos y el tipo de ruta, y le indicará la usuario que la solicitud está en curso (mediante un icono animado, un mensaje...).
Excepciones
• Si el usuario no ha seleccionado al menos el punto de inicio y un punto más, no se permitirá el cálculo de ruta.
• Si pasado un tiempo (time-out) no se recibe respuesta del servidor, se informará al usuario.
• Si se recibe respuesta del servidor indicando que la respuesta no ha podido ser calculada, se informará al usuario de ello.
3.4.13 Caso Uso Visualizar Mapas
Descripción
El turista, con su teléfono móvil puede navegar por la cartografía, puntos de interés y consultando información alfanumérica asociada.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación descargada e instalada en su teléfono móvil, así como acceso a Internet (GPRS/UMTS) para cargar mapas y datos.
Post-condiciones
• Se visualizan mapas y fichas de datos.
Escenario principal
El turista abre la aplicación. Se le muestra un mapa de Extremadura con cartografía base. El usuario puede realizar navegación gráfica sobre el mapa haciendo zoom más, menos, desplazamientos (pan).
3.4.14 Caso Uso Detener GPS
Descripción
El turista, con su teléfono móvil solicita detener el re-centrado del mapa desde la localización del GPS.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación descargada e instalada en su teléfono móvil, debe haber solicitado ‘Obtener localización GPS’.
Post-condiciones
• El mapa deja de obtener el centro desde el GPS.
Escenario principal
El turista desde la opción de menú ‘Detener GPS’ solicita detener el re- centrado desde el GPS.
Escenario alternativo 1
El turista desde la pantalla ‘Selección de puntos de ruta’, solicita establecer punto de inicio, punto de destino o punto intermedio. La aplicación automáticamente detiene el GPS, para que el usuario pueda navegar por el mapa libremente y seleccionar el punto que desee.
Escenario alternativo 2
El turista selecciona la opción ‘Centrar en mapa’ sobre cualquier entidad para que el mapa se centre sobre ella. La aplicación detendrá el re-centrado GPS.
Escenario alternativo 3
Mientras el usuario está en el menú principal de la aplicación o en cualquier formulario que no sea el del mapa, la aplicación detendrá el GPS.
3.4.15 Caso Uso Centrar mapa
Descripción
El turista, con su teléfono móvil puede solicitar centrar el mapa sobre cualquier entidad de un formulario sobre la que pueda colocar el foco y que disponga de coordenadas.
Actores
Turista usuario de la aplicación móvil.
Condiciones Precondiciones
• El turista debe tener la aplicación descargada e instalada en su teléfono móvil y encontrarse en un formulario con entidades con coordenadas.
Post-condiciones
• El mapa se re-centra sobre la entidad seleccionada.
Escenario principal
El turista coloca el foco sobre una entidad con coordenadas (por ejemplo, un punto de una ruta o un tramo de una ruta), solicita centrar el mapa y se muestra la pantalla del mapa con el centro en la entidad seleccionada.
4. Arquitectura de la aplicación
4.0 Introducción
En este capítulo se da un vistazo general a la arquitectura diseñada para la aplicación, cuáles son los distintos componentes y una breve explicación de cada uno de ellos.
4.1 Diagrama de bloques de la arquitectura
El siguiente diagrama informal nos ayudará a comprender la arquitectura general de la aplicación a lo largo de todo el documento, en él aparecen los distintos bloques que componen la aplicación en cuanto a funcionalidad, así como componentes tecnológicos que ayudan a resolver dicha funcionalidad y componentes utilizados a nivel de diseño (que serán descritos con detalles en próximos capítulos). A continuación, se explica cada una de las partes del diagrama y sus relaciones.
Diagrama 3 - Arquitectura de la aplicación
4.2 Descripción de bloques de la arquitectura
En la parte alta del diagrama tenemos la interfaz de usuario móvil que se implementará con la librería libre LWUIT que se explica con más detalle en el apartado 6. Sobre este componente será sobre el que interactúe el usuario y constará básicamente de formularios y menús, mediante los cuales accederá a la funcionalidad implementada.
El componente principal de la interfaz de usuario será el mapa. Tanto el mapa como la interfaz de usuario realizarán operaciones que consumen gran cantidad de recursos y que serán gestionadas con Multithreading (varios hilos de ejecución), para evitar que la aplicación quede ‘congelada’ y el usuario pueda continuar realizando operaciones o cancelando las que están en curso.
A continuación tenemos los 4 bloques funcionales de la aplicación y que han sido descritos en el apartado anterior mediante casos de uso:
• Localización GPS: Casos de uso obtener localización y detener GPS.
• Geometrías PDIs: Casos de uso buscar puntos de interés, mostrar puntos de interés y consultar información.
• Gestión de tiles: Casos de uso visualizar mapa y centrar mapa.
• Geometrías rutas: Casos de uso establecer punto de inicio de ruta, establecer punto de destino de ruta, establecer punto de paso de ruta, eliminar punto de paso de ruta, calcular ruta, anular ruta y selección de puntos de ruta.
Cada bloque funcional lleva asociado un componente tecnológico (bloques en verde en el diagrama) y que a su vez se relaciona con alguno de los subsistemas (bloques en rojo en el diagrama) del sistema de información geográfica de los que el subsistema móvil depende:
• Para la localización GPS se utilizará el componente tecnológico JSR-179, una librería que nos permitirá acceder a datos de posicionamiento y que se explicará en el apartado 7.
• Para los puntos de interés se usarán índices espaciales (estructuras de datos que facilitan la gestión de información geográfica) que serán alimentados por el subsistema de gestión de inventario.
• Para la gestión de tiles (mapas) se implementará un cliente WMS- c (estándar para consumir mapas remotos) relacionado con el subsistema servidor de mapas.
• Para las rutas se utilizará el componente tecnológico Web Services + GeoJSON (formato para codificar información geográfica) asociado al subsistema servidor de rutas.
De fondo tenemos la tecnología J2ME (Java Micro Edition) que es la que guiará todo el proceso de desarrollo y que explicaremos con detalle en el siguiente apartado.
5. Tecnología para el desarrollo de aplicaciones en dispositivos móviles
5.1 Introducción
Una vez definidos los requisitos que debe cumplir SIGATEX móvil, es conveniente realizar un estudio preliminar de la tecnología que se utilizará, dejando para posteriores capítulos un estudio más profundo de algunos aspectos de la tecnología, teniendo siempre en cuenta que un conocimiento exhaustivo de cualquier tecnología se consigue además a través de la experiencia.
En primer lugar, se hace un repaso a la arquitectura. El objetivo es adquirir el conocimiento suficiente y validar que las características de esta tecnología son suficientes para la realización del proyecto.
Tras comprobar desde un punto de vista teórico las grandes dificultades que se presentan hoy en día a los desarrolladores de aplicaciones para teléfonos móviles, se estudian y adoptan un conjunto de buenas prácticas para superar algunas de estas dificultades, llegando a la conclusión que la mejor práctica es la propia experiencia del desarrollador debido al inmenso número de dispositivos con diferentes características existentes en el mercado.
5.2 J2ME
5.2.1 Arquitectura de J2ME
La arquitectura JavaTM 2 Micro Edition está orientada a pequeños dispositivos y sistemas embebidos como son teléfonos móviles, PDAs, máquinas expendedoras y un largo etcétera de productos existentes o futuros.
Al igual que sucede con J2EETM, que está orientado a entornos corporativos o J2SETM, orientado a sistemas de sobremesa, la arquitectura J2ME está formada por un conjunto de APIs estándares que permiten que las aplicaciones desarrolladas se beneficien de las características multiplataforma de Java y que abren la puerta a la distribución de aplicaciones a millones de dispositivos.
Como podemos ver en el siguiente diagrama, la arquitectura J2ME se puede dividir en dos grandes bloques de arquitecturas que dependen
del tipo de dispositivo y las características de los mismos. En función de la familia de dispositivos tomaremos una u otra opción.
Diagrama 4 - Tecnologías JAVA
Para poder tener un entorno de ejecución Java para J2ME que cumpla los requisitos de un rango amplio de dispositivos y mercados objetivo es necesario que se componga de:
• configuración
• perfiles
• paquetes opcionales
Cada combinación de estos elementos se optimiza para la memoria, potencia de proceso y capacidades de E/S de una categoría de dispositivos.
5.2.2 Configuración
Las configuraciones se componen de una máquina virtual y un conjunto mínimo de bibliotecas de función. Proporcionan la funcionalidad básica para un conjunto de dispositivos que comparten características
similares, tales como gestión de memoria o conectividad a la red.
En la actualidad existen dos configuraciones J2ME:
• Connected Limited Device Configuration (CLDC)
• Connected Device Configuration (CDC) 5.2.2.1 CDC
Esta configuración está diseñada para dispositivos que tienen más memoria, procesadores más rápidos y un ancho de banda mayor, como Set-top boxes, pasarelas residenciales, asistentes personales de gran capacidad, etc. Incluye una máquina virtual Java completa (Java Virtual Machine, JVM) y un subconjunto de APIs de la arquitectura J2SE mucho mayor. Se orienta a dispositivos con CPU de 32 bits y un mínimo de 2 MB de memoria disponible para la plataforma Java y aplicaciones asociadas.
5.2.2.2 CLDC
Esta configuración está diseñada para dispositivos con conexiones de red intermitentes, procesadores lentos y memoria limitada: teléfonos móviles, asistentes personales (PDAs), etc. Es habitual que estos dispositivos tenga CPUs de 16 o 32 bits y un mínimo de entre 128 y 256 KB de memoria disponible para la implementación de la plataforma Java y sus aplicaciones asociadas. Está basada en la máquina virtual K (K Virtual Machine, KVM).
Parte de CLDC es un subconjunto de CDC, por lo que la portabilidad de aplicaciones se puede conseguir cuando nos movemos de un entorno más restringido a otro más rico. De la misma manera, y siguiendo en el hilo de la portabilidad, una aplicación en J2ME podrá ejecutarse en J2SE normalmente, salvo que se utilicen las bibliotecas específicas de J2ME.
Veamos más detalladamente algunas características de CLDC, ya que es la configuración en la que nos centraremos en este proyecto.
Comencemos por las propiedades mínimas requeridas a un dispositivo para poder desarrollar con esta configuración:
• Procesador: 16 bit/16 MHz o más.
• Memoria: 160-512 KB de memoria total disponible para la plataforma Java.
• Alimentación: Alimentación limitada, a menudo basada en batería.
• Trabajo en red: Conectividad a algún tipo de red, con ancho de banda limitado habitualmente.
La especificación CLDC se ha desarrollado dentro del Java Community Process (JCP) junto con 500 socios que representan a las industrias de fabricantes de dispositivos móviles, proveedores de servicios y terminales de venta.
Sun proporciona la implementación de referencia de CLDC (CLDC Reference implementation, CLDC RI) que incluye la máquina virtual K (K Virtual Machine, KVM).
La máquina virtual K toma la K de Kilobyte, haciendo referencia al poco tamaño que ocupa la plataforma, un mínimo de 70 KB.
Existen tres versiones de CLDC:
• CLDC 1.1 (JSR 139): CLDC 1.1 es una revisión de la especificación CLDC 1.0 e incluye nuevas características como son coma flotante o soporte a referencias débiles, junto con otras mejoras.
CLDC 1.1 es compatible con versiones anteriores y sigue soportando dispositivos pequeños o con recursos limitados.
Existen implementaciones de referencia.
• CLDC 1.0 (JSR 30).
• CLDC HotSpot ImplementationTM: Es una máquina virtual muy optimizada que presenta una diferencia de rendimiento muy alta frente a la KVM. Incluye características que soportan una ejecución más rápida de aplicaciones y una gestión de recursos más eficientes, manteniendo los requisitos en cuanto a plataforma de ejecución. Tiene la desventaja de que es una máquina virtual para aplicaciones comerciales.
5.2.2.3 Diferencias entre CLDC 1.0 y CLDC 1.1
• Se añade soporte para operaciones en coma flotante, permitiendo el uso de todos los byte code asociados al mismo.
• Se añaden las clases Float y Double.
• Se añaden métodos para la gestión de operaciones en coma flotante a otras librerías.
• Se añade soporte para referencias débiles.
• Se han rediseñado las clases Calendar, Date y TimeZone para adecuarse mejor a J2SE.
• La gestión de error se ha mejorado y se ha añadido una nueva clase de error, NoClassDefFoundError.
• En CLDC 1.1, los objetos Thread tienen nombre como los subprocesos en J2SE. Se ha introducido el método Thread.getName() y la clase Thread incorpora nuevos constructores heredados de J2SE.
• Se han cambiado bibliotecas y se han corregido algunos defectos, entre los que se incluyen los siguientes métodos y campos:
o Boolean.TRUE y Boolean.FALSE
o Date.toString()
o Random.nextInt(int n)
o String.intern()
o String.equalsIgnoreCase()
o Thread.interrupt()
• Se ha elevado el mínimo de memoria necesaria de 160 a 192 KB, debido principalmente a la adición de funcionalidad de coma flotante.
• Se ha mejorado y actualizado la especificación.
• Se ha detallado la especificación del verificador de byte code para CLDC (CLDC Byte Code Typechecker Specification).
5.2.3 Perfil
Para conformar un entorno de ejecución completo orientado a una categoría de dispositivos, las configuraciones se han de combinar con un conjunto de APIs de un nivel más alto, llamadas perfiles, que van un paso más allá en la definición del modelo de ciclo de vida de las aplicaciones, la interfaz de usuario y acceso a las propiedades específicas de los dispositivos.
Un perfil extiende una configuración y completa las necesidades específicas para una cierta familia de dispositivos. Un perfil tiene asociado un conjunto específico de bibliotecas mínimas.
En la actualidad existen los siguientes perfiles asociados a J2ME:
• Mobile Information Device Profile (MIDP)
• Personal Profile
Personal Profile (PP) El perfil Personal, es el perfil para CDC orientado a dispositivos que requieren una IGU completa o capacidad de ejecutar applets de Internet, como por ejemplo PDAs de gama alta, consolas de juegos, etc. Incluye todas las bibliotecas de funciones de la Java Abstract Window Toolkit (AWT) y ofrece fidelidad Web, permitiendo la ejecución de applets diseñados para utilización en entornos de sobremesa. PP reemplaza la tecnología PersonalJavaTM.
5.2.3.1 Mobile Information Device Profile
El perfil MIDP está diseñado para teléfonos móviles y PDAs con capacidades básicas. Ofrece la funcionalidad básica para las aplicaciones móviles, incluyendo la interfaz de usuario, conectividad a
redes, almacenamiento local de datos y gestión del ciclo de vida de las aplicaciones.
Al combinarlo con la configuración CLDC, MIDP proporciona un entorno de ejecución Java completo que incrementa la capacidad de los dispositivos móviles y que reduce el consumo de memoria y energía.
Los usuarios pueden seleccionar las aplicaciones MIDP situadas en un servidor web. El dispositivo comprueba si puede ejecutarla y la descarga, la verifica y compila a byte code para poder ejecutarla. Las aplicaciones instaladas se pueden ejecutar, actualizar y borrar de forma sencilla.
5.2.3.2 Características
Las aplicaciones MIDP permiten tener aplicaciones intuitivas y gráficas.
La IGU se ha optimizado para las pequeñas pantallas, mecanismos de introducción de datos y otras características de los dispositivos móviles.
Las aplicaciones MIDP se pueden instalar y ejecutar en local, trabajar en red o de forma desconectada y puede almacenar y gestionar de forma segura datos en local.
Diagrama 5 - J2ME = CLDC + MIDP + paquetes opcionales
5.2.3.3 Desarrollo con MIDP
Existen tres versiones de MIDP:
• MIDP 2.1: Consiste en una revisión de MIDP 2.0 con cambios menores.
• MIDP 2.0 (JSR 118): MIDP 2.0 es la versión revisada y mejorada de la especificación MIDP 1.0.
• MIDP 1.0 (JSR 37)
Los requisitos hardware mínimos que exige MIDP 1.0 son los siguientes:
• Pantalla: 96x54 con una profundidad de color por pixel de 1 bit.
• Introducción de datos. Se ha de permitir alguno de los siguientes mecanismos:
o teclado de una mano (teclado de teléfono IUT-T)
o teclado de dos manos (teclado QWERTY)
o pantalla táctil
• Memoria (exclusivamente para aplicaciones MIDP):
o 128 KB de memoria no volátil para las aplicaciones MIDP.
o 8 KB de memoria no volátil para los datos persistentes de la aplicación.
o 32 KB de memoria volátil para el entorno de ejecución Java (como por el Heap Java, por ejemplo).
• Trabajo en red: Ancho de banda limitado, bidireccional, sin cables, normalmente intermitente.
La arquitectura de las aplicaciones desarrolladas sobre dispositivos que incorporan la arquitectura MIDP coexiste con terceras aplicaciones que se desarrollan sobre las distintas capas de aplicación que existen sobre estos dispositivos, dando lugar a la posible coexistencia de distintos tipos de aplicaciones sobre un mismo dispositivo que se aprovechan de la tecnología existente:
Diagrama 6 - Arquitectura de aplicaciones para dispositivos móviles
Tipos de aplicaciones:
• MIDP: Una aplicación MIDP o MIDlet es aquella que sólo utiliza las APIs definidas por la arquitectura MIDP o CLDC.
• Específica OEM: Estas aplicaciones dependen de clases ajenas a las especificación MIDP (dependen de clases específicas de fabricante de dispositivos o a terceros). Estas aplicaciones normalmente no son portables a otros dispositivos.
• Nativa: Las aplicaciones nativas no están escritas en Java sino sobre el software nativo del dispositivo.
Centrándonos en las aplicaciones MIDP, los elementos necesarios para la ejecución de una aplicación se engloban dentro de lo que se conoce como MIDlet suite:
• Entorno de ejecución: El software de gestión de aplicación propio del dispositivo proporciona el entorno en el que el MIDlet se instala, inicia, detiene y desinstala, además de gestionar los errores que se producen durante la interacción con el usuario, en definitiva, la gestión de la aplicación y del entorno de ejecución Java preciso para ese MIDlet. Se precisa una máquina virtual para ejecutar las instancias del MIDlet y para gestionar el ciclo de vida de la aplicación. El intercambio de datos entre MIDlets depende de las APIs y la implementación realizada para el mismo.
El software de gestión de aplicación inicia las aplicaciones y hace que están disponibles para el servlet:
o Las clases y código nativo que implementa el CLDC,
o Las clases y código nativo que implementa el entorno de ejecución MIDP.
o Todas las clases del archivo JAR para su ejecución.
o Los archivos del JAR que no son clases como recursos.
o El contenido del archivo descriptor.
5.2.3.4 Diferencias entre MIDP 1.0 y 2.0
Requisitos de dispositivo (hardware)
Para poder ejecutar aplicaciones MIDP 2.0, los dispositivos deberían tener las siguientes características mínimas:
• Tamaño de Pantalla de 96x54 píxeles con un bit de profundidad de color.
• Entrada por teclado o pantalla táctil.
• Memoria de 256KB no volátil para la aplicación MIDP, 8KB no volátil para datos persistentes y 128KB volátil para el entorno de ejecución Java.
• Conexión a redes bidireccional con acceso inalámbrico posiblemente intermitente con ancho de banda limitado.
• Capacidad para reproducir sonidos.
Mejoras introducidas
El MIDP 2.0 mejora y amplia algunas características definidas en MIDP 1.0, entre las que podemos destacar las siguientes:
• Permisos y firma de código de aplicaciones.
• Mejoras en la seguridad de operaciones en red.
• Incorporación de capacidades multimedia.
• Interfaces de usuario mejoradas.
• Cadenas de conexión estandarizadas para acceso por puerto serie.
• Cadenas de conexión estandarizadas para datagramas, sockets y sockets de servidor.
• Registro de solicitudes (push registry) que permite que se ejecuten MIDlets en respuesta a conexiones de red entrantes.
• OTA como práctica recomendada (en MIDP 1.0 era un anexo, no formaba parte de la especificación).
• La clase MIDlet tiene un método platformRequest() que solicita que se muestre una URL a la plataforma subyacente.
• Los repositorios de registros se pueden compartir entre MIDlets.
5.2.3.5 Conectividad
Se definen seis interfaces básicos de conectividad:
Un dispositivo básico de entrada serie.
Un dispositivo básico de salida serie.
Un dispositivo de comunicaciones orientadas a datagrama.
Un dispositivo de comunicaciones orientadas a circuito (TCP, etc.).
Un mecanismo de notificación para informar a un servidor de conexiones cliente servidor.
Una conexión básica a un servidor Web.
El siguiente diagrama muestra la jerarquía de interfaces:
Diagrama 7 - Diagrama jerarquía de interfaces de conectividad en J2ME
5.2.3.6 Funcionalidad multimedia y de juego
MIDP incorpora un API de bajo nivel para la interfaz de usuario que complementa al API de alto nivel, permitiendo un control fino de gráficos e interfaz. El API de juegos incorpora funcionalidad específica para juegos, como son los sprites, y capas, aprovechando las capacidades gráficas nativas de los dispositivos. El audio incorporado permite tonos, secuencias de tonos y archivos WAV. Conectividad MIDP permite utilizar las capacidades de mensajería y redes nativas de datos de los dispositivos de información móviles. Soporta estándares de conectividad que incluyen:
• HTTP
• HTTPS
• datagramas
• sockets
• sockets de servidor
• comunicación serie
• servicio de mensajería (Short Message Service, SMS)
• servicio de multidifusión (Cell Broadcast Service, CBS) de las redes GSM y CDMA (mediante el paquete opciona Wireless Messaging API, WMA)
MIDP permite un modelo de servidor push, que mantiene la lista de aplicaciones registradas para recibir información de la red. Cuando llega la información por la red, el dispositivo decide qué aplicación emplear en función de las preferencias de usuario. Esta arquitectura incluye alertas, mensajería y multidifusión, mejorando las capacidades de gestión de eventos de los dispositivos y redes de comunicaciones.
5.2.3.7 Provisión OTA
MIDP permite desplegar y actualizar aplicaciones activamente (Over the air, OTA). La especificación MIDP define cómo se localizan, instalan, actualizan y eliminan en dispositivos móviles. Esto aplica también a los proveedores de servicios, que pueden acceder a los dispositivos para la consecuente actualización e instalación y que hayan adoptado el modelo.
5.2.3.8 Seguridad de extremo a extremo
MIDP proporciona un modelo de seguridad robusto que protege la red, aplicaciones y dispositivos móviles.
• HTTPS para la transmisión de datos cifrados.
• Dominios de seguridad para proteger del acceso no autorizado.
Las aplicaciones MIDP se han de asignar a dominios específicos definidos en los dispositivos móviles, cifrados adecuadamente mediante el estándar de seguridad PKI X.509 PKI.
• Paquete de la suite MIDlet, normalmente un archivo JAR: En un único archivo JAR se pueden almacenar uno o varios MIDlets.
Cada MIDlet tiene una o varias clases que heredan de la clase MIDlet y otras clases auxiliares. Los elementos que lo componen son:
o Un archivo de manifiesto que describe el contenido del JAR junto con atributos utilizados por el software de gestión de aplicación para identificar e instalar la MIDlet suite.
El manifiesto debe incluir algunos atributos obligatoriamente y otros de forma opcional:
Obligatorios:
MIDlet-Name: El nombre de la MIDlet suite que identifica los MIDlets al usuario.
MIDlet-Version: El número de versión de la MIDlet suite.
MIDlet-Vendor: Organización que proporciona la MIDlet suite.
MIDlet- for each MIDlet: Nombre, icono y clase del n- ésimo MIDlet del archivo JAR separados por comas. El valor mínimo de <n> será 1 y se deberán utilizar ordinales consecutivos.
1. El nombre se utiliza para identificar el MIDlet para el usuario.
2. El icono es el nombre de una imagen (PNG) dentro del JAR para el icono del n-ésimo MIDlet.
3. La clase es el nombre de la clase que extiende a la clase MIDlet para el n-ésimo MIDlet. La clase deberá tener un constructor público sin argumentos.
MicroEdition-Profile: El perfil J2ME requerido, que utiliza el mismo valor que la propiedad de sistema microedition.profiles (por ejemplo "MIDP-1.0").
MicroEdition-Configuration: La configuración J2ME requerida, que utiliza el mismo valor que la propiedad de sistema microedition.configuration (por ejemplo
"CLDC-1.0").
Optativos:
MIDlet-Description: Descripción de la MIDlet suite.
MIDlet-Icon: Nombre del archivo PNG dentro del JAR que se utiliza para representar la MIDlet suite. Debería utilizarlo el software de gestión de aplicación para mostrar un icono que identifique a la suite.
MIDlet-Info-URL: URL para información adicional que describa la MIDlet suite.
MIDlet-Data-Size: Número mínimo de bytes de datos persistentes que requiere el MIDlet. El dispositivo puede proporcionar almacenamiento opcional según su propia política. El valor predeterminado es cero.
o Clases java para el/los MIDlet/s y clases compartidas por éstos.
o Archivos de recursos empleados por el/los MIDlet/s.
• Descriptor de aplicación:
o Empleado por el software de gestión de aplicación para gestionar el MIDlet y por el propio MIDlet para la configuración de atributos específicos.
o La extensión del descriptor de aplicación deber ser jad.
o El tipo MIME del archivo descriptor de aplicación ha de ser text/vnd.sun.j2me.app-descriptor.
o El manifiesto debe incluir algunos atributos obligatoriamente y otros de forma opcional:
Obligatorios:
MIDlet-Name: El nombre de la MIDlet suite que identifica los MIDlets al usuario.
MIDlet-Version: El número de versión de la MIDlet suite.
MIDlet-Vendor: Organización que proporciona la MIDlet suite.
MIDlet-Jar-Url: URL desde la que se puede cargar el archivo JAR.
MIDlet-Jar-Size: Número de bytes del archivo JAR.
Optativos:
MIDlet-Description: Descripción de la MIDlet suite.
MIDlet-Icon: Nombre del archivo PNG dentro del JAR que se utiliza para representar la MIDlet suite. Debería utilizarlo el software de gestión de aplicación para mostrar un icono que identifique a la suite.
MIDlet-Info-URL: URL para información adicional que describa la MIDlet suite.
MIDlet-Data-Size:Número mínimo de bytes de datos persistentes que requiere el MIDlet. El dispositivo puede proporcionar almacenamiento opcional según su propia política. El valor predeterminado es cero.
Atributos específicos del MIDlet que no comienzan por "MIDlet-"
• Ciclo de vida de aplicación: Se gestiona a través del software de gestión de aplicación y la interacción con el usuario. La clase MIDlet permite el inicio, detención y liberación de recursos del MIDlet. Un MIDlet no tienen método public static void main(). El software de gestión de aplicación proporciona la clase inicial que necesita el CLDC para iniciar un MIDlet.
5.2.3.9 MIDlet y Ciclo de vida de un MIDlet
Las aplicaciones que se desarrollan con J2ME e implementan la especificación MIDP para dispositivos móviles se denominan MIDLETs. Los MIDLETS se deben agrupar en un fichero .JAR para que sea posible su distribución (a otros dispositivos, a través de Internet, por ejemplo).
En un fichero .JAR se pueden incluir varios MIDLETs y a este conjunto se le denomina MIDLETSuite.
Las clases definidas en la biblioteca de funciones javax.microedition.midlet son las que emplearemos a la hora de crear el código de nuestros propios MIDlets:
• MIDlet: Interfaz para un MIDlet, aplicación MIDP.
• MIDletStateChangeException: Clase de excepción para indica que un cambio de estado de un MIDlet ha fallado.
El ciclo de vida de un MIDlet define el protocolo entre el mismo MIDlet y su entorno mediante:
• Una máquina de estados simple
• Una definición concisa de los estados del propio MIDlet
• APIs para indicar los cambios de estados.
Por último se presenta la información que se incluye en un MIDLET.JAR:
• Clases MIDlet
• Clases soporte
• Recursos(imágenes,sonido,...)
• Fichero Manifiesto ( fichero .mf)
• Descriptor de aplicación (fichero .jad)
Los distintos estados en los que se puede encontrar un MIDlet son:
• Detenido (Paused): El MIDlet está inicializado y su ejecución ni reserva ni utiliza recursos compartidos. A este estado se entra:
o Después de crear el MIDlet con new. Se invoca el constructor público sin argumentos, que no devuelve excepción. Si se produce excepción se entra en el estado Destruido (Destroyed) y se descarta.
o Desde el estado Activo (Active) después de que se invoque con éxito el método MIDlet.pauseApp() .
o Desde el estado Activo si el método startApp lanza una excepcién MIDletStateChangeException.
• Activo (Active): EL MIDlet funciona normalmente. A este estado se entra:
o Justo antes de llamar al método MIDlet.startApp().
• Destruido (Destroyed): El MIDlet ha liberado todos sus recursos y terminado. A este estado se entra:
o Cuando se termina el método MIDlet.destroyApp() excepto si el argumento incondicional tiene el valor false y se lanza una excepción MIDletStateChangeException. El método destroyApp() liberará los recursos que se estén empleando y dejará la instancia en una situación que permita que se libere mediante le recolector de basura.
o Cuando el método MIDlet.notifyDestroyed() responde correctamente a la aplicación. El MIDlet debe haber ejecutado las operaciones equivalentes al método MIDlet.destroyApp() antes de invocar a MIDlet.notifyDestroyed().
o En este estado sólo se entrará una vez.
Diagrama 8 - Ciclo de vida de un MIDlet
5.2.4 Paquetes opcionales
La plataforma J2ME se puede ampliar combinando varios paquetes opcionales con CLDC y CDC junto con sus perfiles. Estos paquetes se han creado para responder a requisitos concretos de mercado y ofrecen un conjunto de APIs estándares para utilizar tanto tecnologías existentes como emergentes; entre estas se incluyen Bluetooth, servicios Web, mensajería wireless, capacidades multimedia o conectividad a
bases de datos. Dado que son modulares, los fabricantes de dispositivos pueden incorporarlos según los vayan necesitando para mejorar las características soportadas.
5.2.5 Máquinas virtuales
La máquina virtual para CLDC soporta un subconjunto de funcionalidad de J2SE además de incorporar una funcionalidad propia tal y como detalla el siguiente diagrama:
Diagrama 9 - J2ME vs J2SE
A continuación detallamos las características entre una JVM que soporta J2SE y J2ME:
• CLDC no soporta coma flotante (en la versión CLDC 1.0).
• No soporta la finalización de instancias de clases.
• El soporte a la gestión de errores es limitado, debido a las exigencias que impone en los dispositivos a nivel de memoria, y a que la recuperación de errores es dependiente de los dispositivos.
• Por motivos de seguridad se eliminan las siguientes características:
o Java Native Interface (JNI).
o Cargadores de clase definidos por el usuario.
o Reflection (Reflexión).
o Grupos de subprocesos (Thread groups) y subprocesos demonio (daemon threads).
o Finalización.
o Referencias débiles.
• Soporta un conjunto limitado de propiedades:
o microedition.platform Nombre de la plataforma, con valor predeterminado null
o microedition.encodingDefault Codificación
