Sigatex Móvil - SIG para dispositivos móviles - Index of

Transcripción

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 y Turismo
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
2
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.
3
•
•
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.
4
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.
5
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.
6
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
7
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.
8
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.
9
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
Condiciones
Precondiciones
•
•
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
10
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.
11
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
Condiciones
Precondiciones
•
•
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.
12
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
Condiciones
Precondiciones
•
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.
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
en el centro).
13
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.
14
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
Condiciones
Precondiciones
•
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.
menú Establecer como fin de ruta. La aplicación realiza el mismo
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
opción Seleccionar Ubicación referida a Punto de Destino. La
15
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).
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.
16
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
Condiciones
Precondiciones
•
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.
menú Establecer como inicio de ruta. La aplicación realiza el mismo
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
opción Seleccionar Ubicación referida a Punto de Partida. La aplicación
17
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).
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.
18
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
Condiciones
Precondiciones
•
•
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
19
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
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.
20
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
Condiciones
Precondiciones
•
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.
21
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
Condiciones
Precondiciones
•
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.
22
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
Condiciones
Precondiciones
•
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
seleccionado en punto de partida o de destino.
23
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.
24
3.4.12 Caso Uso Calcular Ruta
Descripción
El turista, desde su aplicación solicita calcular ruta.
Actores
Condiciones
Precondiciones
•
•
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.
25
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
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).
26
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
Condiciones
Precondiciones
•
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 recentrado desde el GPS.
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.
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.
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.
27
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
Condiciones
Precondiciones
•
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.
28
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.
29
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.
30
•
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 WMSc (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.
31
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
32
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
33
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.
34
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.
35
•
•
•
•
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
36
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
37
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:
38
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,
incluyendo la JVM.
39
o
o
o
o
Las clases y código nativo que implementa el entorno de
ejecución MIDP.
Todas las clases del archivo JAR para su ejecución.
Los archivos del JAR que no son clases como recursos.
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:
40
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
41
•
•
•
•
•
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:
42
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.
Clases java para el/los MIDlet/s y clases compartidas por
éstos.
Archivos de recursos empleados por el/los MIDlet/s.
o
o
•
Descriptor de aplicación:
43
o
o
o
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.
La extensión del descriptor de aplicación deber ser jad.
El tipo MIME del archivo descriptor de aplicación ha de ser
text/vnd.sun.j2me.app-descriptor.
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.
44
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:
45
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.
o
•
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
46
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
predeterminada, con valor predeterminado "ISO8859_1"
47
microedition.configuration
Nombre
y
versión
de
configuración soportada, con valor predeterminado "CLDC1.0"
o microedition.profiles Nombre de perfiles soportados, con
valor predeterminado null
Bibliotecas de función soportadas:
o Clases subconjunto del las bibliotecas estándar J2SE,
localizadas en los paquetes java.lang.*, java.util.* y java.io.*:
o
•
Clases de sistema:
java.lang.Object
java.lang.Class
java.lang.Runtime
java.lang.System
java.lang.Thread
java.lang.Runnable (interfaz)
java.lang.String
java.lang.StringBuffer
java.lang.Throwable
Tipos de datos:
java.lang.Boolean
java.lang.Byte
java.lang.Short
java.lang.Integer
java.lang.Long
java.lang.Character
Clases de colección
java.util.Vector
java.util.Stack
java.util.Hashtable
java.util.Enumeration (interfaz)
Clases de entrada/salida
java.io.InputStream
java.io.OutputStream
java.io.ByteArrayInputStream
java.io.ByteArrayOutputStream
java.io.DataInput (interface)
java.io.DataOutput (interface)
java.io.DataInputStream
java.io.DataOutputStream
java.io.Reader
48
java.io.Writer
java.io.InputStreamReader
java.io.OutputStreamWriter
java.io.PrintStream
Clases de calendario y fecha
java.util.Calendar
java.util.Date
java.util.TimeZone
Clases de excepción
java.lang.Exception
java.lang.ClassNotFoundException
java.lang.IllegalAccessException
java.lang.InstantiationException
java.lang.InterruptedException
java.lang.RuntimeException
java.lang.ArithmeticException
java.lang.ArrayStoreException
java.lang.ClassCastException
java.lang.IllegalArgumentException
java.lang.IllegalThreadStateException
java.lang.NumberFormatException
java.lang.IllegalMonitorStateException
java.lang.IndexOutOfBoundsException
java.lang.ArrayIndexOutOfBoundsException
java.lang.StringIndexOutOfBoundsException
java.lang.NegativeArraySizeException
java.lang.NullPointerException
java.lang.SecurityException
java.util.EmptyStackException
java.util.NoSuchElementException
java.io.EOFException
java.io.IOException
java.io.InterruptedIOException
java.io.UnsupportedEncodingException
java.io.UTFDataFormatException
Clases de error
java.lang.Error
java.lang.VirtualMachineError
java.lang.OutOfMemoryError
49
o
Clases específicas a CLDC (pero que se pueden asociar a
J2SE), localizadas en los paquetes javax.microedition.*:
En cuanto a la máquina virtual de CLDC, KVM, requiere entre 40 y 80
Kbytes dependiendo de las opciones de compilación y el tipo de
dispositivo para el que se compile. Esto implica que se podrán ejecutar
aplicaciones con un total de 128 Kbytes. Aparte de esto, se necesitan
otros 32 Kbytes para memoria dinámica de la aplicación a ejecutar.
KVM está implementada en C y está diseñada para ser tan completa y
rápida como sea posible. De hecho, puede ejecutarse de un 30 a un
80% de la velocidad de la JVM.
Volviendo a la verificación de clases, la máquina virtual de Java
estándar efectúa un proceso en tiempo de ejecución que se denomina
verificación 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 código 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 núcleo 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:
•
•
•
•
Inicialización de todas las variables locales antes de su uso.
El constructor de un objeto debe ser llamado justo seguidamente
de la creación 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 estáticos deben contener
referencias a objetos que sean asignables legalmente.
Si nos trasladamos a CLDC, este proceso será muy costoso en términos
de uso de recursos, ya que requiere mucha memoria, procesador y
espacio para código binario. Es por esto por lo que los diseñadores de
KVM decidieron hacer la verificación 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 añadir al fichero clase generado por javac
nuevo código que identifique la clase como válida (pasa a ser una
clase verificada). Seguidamente, se transfiere al dispositivo y la KVM sólo
tiene que comprobar si esta información está o no presente o contiene
o no la información correcta. En cualquiera de los dos casos negativos,
el proceso de carga se interrumpe y se lanza una excepción. Esta
comprobación se puede hacer justo cuando se carga la clase o como
parte del proceso de instalación de la aplicación. En cualquier caso es
50
un proceso más rápido que la preverificación y requiere menos
memoria.
Al tener como objetivo dispositivos con prestaciones reducidas, CLDC
elimina una gran cantidad de características que sí aparecen en J2SE,
tanto en el propio lenguaje Java como en la máquina virtual, como por
ejemplo:
•
•
•
•
•
•
•
•
•
•
Interfaz nativo de Java (Java Native Interface - JINI) (Máquina
virtual).
Cargadores de clases definidas por el usuario (Máquina virtual).
Grupos de hilos e hilos demonios (Máquina virtual).
Finalización (lenguaje Java).
Referencias débiles (Máquina virtual).
Reflexión (Máquina virtual).
Tipos de datos de punto flotante (lenguaje Java).
Algunos aspectos de seguridad y APIs (Máquina virtual).
Verificación de ficheros de clases (Máquina virtual).
Posee algunas limitaciones en las gestiones de errores (lenguaje
Java).
5.3 Buenas prácticas
5.3.1 Compatibilidad vs complejidad
Como ya hemos comentado anteriormente, una de las principales
dificultades en el desarrollo de aplicaciones para dispositivos móviles es
la fragmentación de dispositivo. Esto ha llevado a los desarrolladores a
establecer una serie de pautas para maximizar la compatibilidad de sus
aplicaciones intentando producir aplicaciones con el mínimo consumo
de memoria y procesamiento posibles.
En general, la compatibilidad de una aplicación es inversamente
proporcional a la complejidad de la misma, es por ello, que será
necesario aplicar una serie de buenas prácticas para salvar esta
situación.
51
Diagrama 10 - Relación entre compatibilidad y complejidad en el desarrollo con J2ME
Por otra parte, hay que recalcar que la optimización de aplicaciones
puede ser una tarea complicada, ya que se pueden introducir nuevos
bugs o conseguir el efecto contrario y decrementar la compatibilidad.
Así pues no siempre es necesario aplicar todas estas prácticas, en
nuestro caso se hizo selección de algunas ayudándonos de un monitor
de memoria y CPU para localizar puntos críticos y optimizar.
A continuación se detallan algunas de estas buenas prácticas y
consejos para aumentar la compatibilidad que se han ido recopilando
a lo largo de la realización del proyecto.
5.3.2 A nivel de usuario
•
Siempre hay que tener en cuenta a quién va dirigida nuestra
aplicación. Generalmente, el usuario de dispositivos móviles es un
usuario impaciente que necesita acceder a la información de
manera rápida y de un vistazo. Puesto que la entrada de
información es complicada para el usuario hay que facilitar las
cosas utilizando siempre que sea posible listas o botones y
maximizando el tamaño de la pantalla que de por sí ya es
reducido, simplificando formularios o dividiendo la entrada de
datos en diferentes pasos a través de pantallas permitiendo
cancelar siempre la operación en cualquier momento.
52
•
Hay que ser consistente con el uso de las teclas a lo largo de la
aplicación. Así, se pueden establecer teclas predefinidas para
según qué tareas. También intentar mantener la misma estructura
de menús entre pantallas siempre que sea posible.
•
El hilo principal de la aplicación debe ser el encargado de
manejar la interacción con el usuario y por tanto nunca debe
bloquearse. Las operaciones de entrada/salida tales como
lectura de ficheros son lentas, como también lo son las conexiones
http. Es importante utilizar hilos para estas operaciones para evitar
bloquear el hilo principal y que parezca que la aplicación se ha
quedado colgada.
5.3.3 A nivel de rendimiento y eficiencia
•
Evitar concatenaciones de Strings, utilizar StringBuffer para tal
caso. La concatenación de Strings produce cada vez un nuevo
objeto y por tanto, mayor consumo de memoria y mayor
recolección de basura.
•
La encriptación y conexiones https tienen peor rendimiento.
•
Intentar llamar a los métodos con el menor número de parámetros
posible.
•
Si se van a realizar operaciones complejas como, senos, cosenos u
otras operaciones complicadas de coma flotante y se sabe de
antemano cuál va a ser el resultado, es conveniente pre-calcular
estos valores y utilizarlos como constantes.
•
Los métodos sincronizados son los más lentos, a continuación los
métodos de interfaz, los métodos de instancia, los métodos finales
y por último los métodos estáticos son los más rápidos. Hay que
tener en cuenta esta clasificación para evitar siempre que sea
posible la sincronización e interfaces.
•
Evitar en cualquier caso sincronización dentro de bucles.
•
Usar variables es más eficiente que arrays. Los arrays son más
eficientes que Vector o HashTable y en cualquier caso, arrays
unidimensionales siempre mejor que bidimensionales. Tener en
cuenta también que hay que inicializar la clase Vector y
HashTable con un tamaño que se ajuste a nuestras necesidades
ya que crecen según nuestra demanda y para evitar desperdiciar
53
memoria, ya que de no ser así se inicializan con 100 elementos
que pueden ser más de los que necesitemos.
•
El acceso a los atributos de una clase es más rápido que
encapsular con getter y setter.
•
El acceso a variables locales es más rápido que a atributos de la
clase. Siempre que sea posible asignar atributos de una clase a
una variable local si se va a hacer referencia a ella varias veces
dentro de un método o bucle.
•
Soportar el trabajo off-line siempre que sea posible persistiendo la
información en el almacenamiento del dispositivo.
•
Contar hacia atrás es más rápido en los bucles.
•
Usar operadores como x+=1 en vez de x = x+1 ya que generan
menos byte code.
•
Sacar fuera de los bucles las constantes.
•
Utilizar desplazamiento de bits en vez de la multiplicación o
división si es posible. Por ejemplo, x >> 2 es equivalente a x / 4 y x
<< 10 es equivalente a x * 1024, 1 << 20 es equivalente a
Math.pow(2, 20).
•
Cuando sea posible evitar bucles ya que evitaremos toda la
sobrecarga de control de flujo en cada iteración. Por ejemplo, si
tenemos una operación que se va a realizar 5 veces, en vez de
utilizar un bucle podemos realizar las 5 operaciones
secuencialmente.
•
Siempre que vayamos a acceder a la misma posición de un array
varias veces, es mejor guardar esa posición en una variable local
y así evitar el acceso repetido al índice del array.
•
Normalmente cuesta menos comparar un número a cero, así,
siempre que sea posible en un bucle utilizar como guarda una
comparación a cero.
•
Delegar operaciones demasiado complejas en portales y
acceder a los resultados a través de servicios web o conexiones
de red.
•
Utilizar buffers para leer datos a través de la red y leer los datos en
porciones en lugar de byte a byte que es más lento.
54
5.3.4 A nivel de memoria
•
Reutilizar y hacer pool de objetos siempre que sea posible para
evitar crear nuevas instancias.
•
Usar tipos escalares en lugar de objetos Java siempre que sea
posible, por ejemplo, int en lugar de Integer.
•
Liberar recursos tan pronto como sea posible, como conexiones
de red, a streams o a ficheros. Normalmente, se suele liberar este
tipo de recursos dentro de la cláusula finally para asegurarnos de
que los recursos se liberan aún cuando se produzca alguna
excepción.
•
Usar excepciones únicamente cuando sea necesario ya que
cada excepción lanza un nuevo objeto.
•
Instanciación perezosa de clases.
•
Referenciar a null instancias de objetos que ya no se van a usar,
para que el recolector de basura libere memoria.
•
Es conveniente utilizar un ofuscador para reducir tanto como sea
posible el tamaño del JAR. Además, el ofuscador puede incluir
algunas optimizaciones.
5.3.5 A nivel de arquitectura
•
Debido a la programación orientada a objetos hay una
tendencia a tener clases, frameworks, patrones, etc. lo cual
produce arquitecturas complicadas. Generalmente, esto no
supone ningún problema, pero cuando trabajamos con
dispositivos móviles en los que la memoria está muy limitada, en
ocasiones, es conveniente simplificar el diseño y la arquitectura
siempre que sea posible.
•
Sería suficiente con una arquitectura en la que la partición de lo
que contiene cada clase fuera tal, que cuando se instancia,
contiene única y exclusivamente todas las referencias que
necesita para realizar su función, evitando así el desperdicio de
recursos.
55
5.3.6 A nivel de interfaz
El desarrollo de interfaces de usuario siempre ha sido una tarea ardua
en el mundo móvil, es por ello, que para superar esa gran dificultad se
optó por la utilización de un framework libre, LWUIT (Light Weight User
Interface ToolKit) que se detalla en el siguiente capítulo.
56
6. Desarrollo de interfaces de usuario para dispositivos móviles
6.1 Introducción
El desarrollo de interfaces de usuario para dispositivos móviles siempre
ha supuesto una gran dificultad, debido en parte a los errores en las
implementaciones de la librería gráfica de los fabricantes y a la multitud
de dispositivos diferentes que conduce a la inconsistencia en las
interfaces.
En este apartado se describe la problemática asociada a las interfaces
de usuario, algunas alternativas existentes hasta el momento y se
propone y analiza LWUIT como una alternativa de código libre.
Diagrama 11 - Bloque interfaz usuario móvil
6.2 Fragmentación de dispositivo.
Una de las grandes dificultades a la hora de desarrollar aplicaciones
para dispositivos móviles radica en el diseño de interfaces de usuario. El
57
principal problema es que la especificación de la librería gráfica
javax.microedition.lcdui.* deja lugar a la interpretación, de ahí, que
podamos encontrar diferentes implementaciones de un mismo
componente en distintos fabricantes, incluso entre distintos modelos del
mismo fabricante o implementaciones con errores. Esto, unido a la
heterogeneidad de dispositivos en donde nos podemos encontrar
algunos con teclado QWERTY, con interfaz táctil, diferentes tamaños de
pantalla, distintas resoluciones, etc. Puede conducir a que una misma
interfaz de usuario tenga distinto aspecto según el dispositivo, o lo que
es peor, distinto comportamiento.
Hasta el momento había varias soluciones a este problema:
•
Desarrollar nuestra propia librería gráfica: Esta solución sería la
menos deseable, pero es a la que recurren grandes compañías
que se dedican a desarrollar aplicaciones así como las empresas
que desarrollan juegos para teléfonos móviles. Implica un gran
esfuerzo ya que no es una tarea en absoluto trivial.
•
Utilizar un framework: Hasta el momento una de las soluciones más
comunes era el framework J2ME Polish que contenía gran
cantidad de componentes y widgets. Además contiene una base
de datos con las especificaciones de la gran mayoría de
dispositivos existentes, de manera que existe la posibilidad de
activar directivas de pre-procesado para configurar nuestra
aplicación en función del modelo concreto de dispositivo a que
vaya dirigido, de manera que obtenemos un jar diferente según el
dispositivo.
o Tiene la ventaja de que es un framework de código libre y
por tanto se ajusta a nuestras necesidades.
o La principal desventaja es que como todo framework
requiere una fase de aprendizaje importante, además,
realizar una configuración para cada dispositivo puede
llegar a ser algo complicado.
•
Utilizar la librería estándar de J2ME (javax.microedition.lcdui.*):
Como hemos dicho puede suponer un problema, pero su función
es la de diseñar interfaces de usuario.
58
o La principal ventaja es que es una librería bastante sencilla
de utilizar, se basa en añadir componentes a formularios,
con posibilidad de añadir opciones de menú.
o La principal desventaja como hemos dicho es que la
interfaz de usuario resultante puede resultar poco
consistente entre dispositivos. Además, no existe la
posibilidad de crear interfaces complejas, especificar
layouts, animaciones, etc.
6.3 LWUIT (Swing para teléfonos móviles)
Recientemente, en verano de 2008, se liberó LWUIT (Light Weight User
Interface ToolKit) una librería gráfica con licencia GPL desarrollada por
Sun cuyo objetivo es resolver los problemas que había hasta el
momento en cuanto a desarrollo de interfaces de usuario. LWUIT
funciona sobre MIDP 2.0/CLDC 1.1 y CDC/PP, es decir, la mayoría de
teléfonos móviles y PDAs existentes en el mercado en la actualidad.
Como hemos dicho el objetivo de LWUIT es superar la fragmentación de
dispositivo en cuanto a interfaces de usuario y su máxima es la de ‘un jar
para todos los dispositivos’ consiguiendo que la interfaz sea igual en
todos los dispositivos o al menos en casi todos.
Algunas de las características más interesantes de LWUIT son:
•
Look and Feel, temas y estilos.
•
Jerarquía de contenedores y componentes al estilo Swing.
•
Diferentes distribuciones - layouts (también como en Swing) para
los contenedores, lo que permite que los componentes se
distribuyan en función de su propio tamaño, no el de la pantalla.
•
Paradigma MVC (simplificado de Swing) para el renderizado de la
clase List.
•
Posibilidad de generar ficheros de recursos con iconos, imágenes,
archivos de idioma, etc.
•
Los eventos son manejados por un hilo (EDT – Event Dispatch
Thread) que encapsula la entrega de eventos. El desarrollador
sólo necesita implementar alguna de las interfaces que
proporciona LWUIT y registrarla sobre el componente que desee
monitorizar.
59
6.3.1 Paradigma de programación de LWUIT
Como hemos dicho LWUIT está inspirado en Swing para J2SE y según sus
desarrolladores en algunos aspectos incluso lo mejora.
En el esquema podemos ver la jerarquía de clases de componentes
básica de LWUIT:
Diagrama 12 - Diagrama de componentes LWUIT
Como podemos ver todo es un componente. Un contenedor es un
componente que puede contener a su vez, más componentes; de esta
manera anidando contenedores podemos crear interfaces complejas.
6.3.1.1 Formularios, componentes y contenedores
Un formulario es un componente de alto nivel, está considerado como
el elemento raíz de una interfaz de usuario. Por defecto el contenido de
un formulario permite desplazamiento, así podemos colocar más
componentes de los que cabrían en la pantalla y poder desplazarnos
entre ellos.
Un componente es un objeto que se representa gráficamente y puede
interactuar con el usuario. Está considerada la clase base y son por
ejemplo: botones, etiquetas, cuadros de texto, etc.
Un contenedor permite anidar y colocar múltiples componentes
utilizando distintas distribuciones. Así mismo, puesto que un contenedor
es un componente, es posible anidar distintos contenedores.
Normalmente, una aplicación estará compuesta de uno o más
formularios, que contendrán diversos componentes. Un formulario
puede tener su propia distribución y anidar contenedores obteniendo
así interfaces complejas. Veamos las 3 áreas de un Formulario:
60
Diagrama 13 - Formulario LWUIT
En este ejemplo sencillo podemos ver que un formulario cuenta con una
barra de título, aunque puede no tener si no especificamos ninguno, un
panel de contenido donde se situarán los componentes y contenedores
y una barra de menú donde habitualmente colocaremos las opciones
de menú que se corresponden con las acciones que pueda realizar el
usuario sobre el formulario.
A continuación podemos ver un ejemplo simple de un formulario con
varios componentes:
Diagrama 14 - Formulario + Labels
RadioButton
Diagrama 15 - Checkbox +
61
6.3.1.2 Distribuciones (Layouts)
Como hemos visto un contenedor (y un formulario) puede tener una
distribución de 5 posibles: BorderLayout, BoxLayout, FlowLayout,
GridLayout, GroupLayout. A continuación se hace un repaso a las 4
primeras.
•
BorderLayout: Consta de 5 áreas en donde podremos colocar
componentes: norte, sur, centro, este y oeste. El aspecto de la
distribución es el siguiente:
Diagrama 16 - BorderLayout
•
BoxLayout: Los componentes se alinean bien en vertical o en
horizontal según especifiquemos.
62
Diagrama 17 - BoxLayout horizontal
Diagrama 18 - BoxLayout
vertical
•
FlowLayout: Es la distribución por defecto de un contenedor.
Consiste en colocar los components en fila, cuando en una misma
fila no caben más componentes se añaden en una nueva fila y
así sucesivamente.
Diagrama 19 - FlowLayout
•
GridLayout: Podemos especificar una rejilla de filas y columnas.
63
Diagrama 20 - GridLayout 2x2
6.3.1.3 Listas y el paradigma MVC: Independizar el modelo
de la vista
El paradigma MVC es el que utiliza LWUIT para manejar el componente
List. Consta de 3 partes diferenciadas: modelo, vista y controlador.
•
El modelo representa los datos del componente List. Es similar a un
Vector o Array pero nos puede decir exactamente cuántos ítems
contiene y en qué posición.
•
La vista pinta el contenido del modelo sobre la pantalla. No
conoce los datos que se están pintando, sino solo cómo pintarlos.
Monitoriza los cambios en el modelo y se repinta cuando detecta
cambios.
•
El controlador acepta los datos del usuario y realiza los cambios
sobre el modelo que provoca que la vista se actualice.
En LWUIT, el componente List es el controlador, la interfaz
ListCellRenderer es la vista y la clase ListModel es el modelo. Cada vez
que la lista se pinta, ésta itera sobre los elementos visibles del modelo, los
toma y los dibuja utilizando el renderer.
El paradigma MVC puede resultar útil principalmente en estas 2
situaciones:
1. Una lista puede contener miles de entradas pero solo carga en
64
memoria las que son visibles al usuario. Como hemos dicho la lista
sólo pregunta al modelo sobre los elementos que son visibles y por
tanto, el resto, no se cargan en memoria hasta que no se
desplaza la lista y en ese momento, los elementos que estaban
visibles y ya no lo están serán descargados de memoria.
2. Es posible reutilizar modelos genéricos para distintas vistas.
Como también es posible tener diferentes vistas para el mismo
modelo, de modo que podríamos tener varios formularios con
vistas que apuntaran a un modelo, una con menos detalle y otra
con más información y se actualizarían todas al mismo tiempo.
Fundamentalmente, la principal ventaja, la encontramos cuando
tenemos listas de gran tamaño o que representan estructuras de datos
complejas que podemos personalizar la manera en que serán
mostradas en pantalla.
Veamos un par de ejemplos:
Diagrama 21 - DefaultListCellRenderer
En este ejemplo, tenemos una lista de Strings. El ListModel (el modelo)
sería un Vector de Strings y el ListCellRenderer (la vista), sería una clase
que asignaría a una Label el texto de cada String. Cuando el elemento
seleccionado del componente List cambia, la vista detecta este
cambio y pinta el elemento con un fondo y una letra de otro color al
resto.
65
Diagrama 22 - LisCellRenderer complejo
Este ejemplo es algo más complejo. El ListModel (el modelo) sería un
Vector de ‘Contactos’, donde la clase Contacto tendría dos atributos
de tipo String (nombre y e-mail) y un atributo de tipo Image (foto). El
ListCellRenderer podría ser un Contenedor con BorderLayout, donde en
la zona ESTE pintaríamos la foto, y en la zona CENTRO colocaríamos otro
Contenedor con FlowLayout vertical, donde colocaríamos dos etiquetas
con el nombre y el e-mail. Además el elemento seleccionado es
dibujado con una imagen a la derecha y un fondo de otro color.
6.3.2 Estilos y temas
Los dispositivos móviles, especialmente los teléfonos móviles son
considerados como elementos muy personales. De ahí que a los
usuarios les guste configurarlo de acuerdo a su personalidad. Debido a
esta demanda LWUIT proporciona una serie de mecanismos para
personalizar el aspecto de las aplicaciones.
LWUIT define un objeto Style que dicta los colores, fuentes,
transparencia, margen, imagen de fondo y borde de cada
componente. Cada componente tiene su propio objeto Style al cual es
posible acceder y modificar sus propiedades mediante código.
La idea es definir los atributos visuales de cada componente de
acuerdo a unas características comunes que son:
Colores de fondo y de relleno: Cada componente tiene cuatro
atributos de color: dos para color de fondo y dos para relleno. Cada
uno de esos dos colores son para cuando el componente está
activado (tiene el foco) y cuando no lo tiene.
66
Fuentes de texto: El texto puede ser renderizado usando estilos de
fuente estándar del dispositivo o como mapas de bits.
Transparencia: El fondo de un componente puede ser opaco o
completamente transparente.
Imagen de fondo: Por defecto un componente no tiene imagen de
fondo.
Margen y padding: Es posible especificar la distribución interna del
componente, de acuerdo al siguiente gráfico.
Diagrama 23 - Distribución de un componente
Definir el estilo de cada componente uno a uno puede resultar una
tarea tediosa. De ahí la utilidad de los temas, que consisten en una
colección de propiedades de estilo comunes (colores, fuentes,
transparencias, etc.) que se aplican a cada clase de componente y se
puede enchufar directamente en tiempo de ejecución, sin necesidad
de recompilar la aplicación. Las propiedades de un tema se guardan
en un fichero de recursos que se carga al arrancar la aplicación, aún
así, las instancias de componentes que tengan definido su propio estilo
mediante código lo conservan.
Utilizando temas nos aseguramos que el estilo general de nuestra
aplicación será coherente en todas las pantallas y además cada vez
que añadimos un componente nos aseguramos de que mantendrá el
estilo que tenemos definido.
67
Diagrama 24 - Ejemplo theme 1
Para ayudar a la creación de archivos de tema, LWUIT proporciona
ResourceEditor, una sencilla aplicación que nos permite modificar y ver
en tiempo real el aspecto del tema que queramos crear y almacenarlo
en un fichero de recursos que podemos embeber en nuestra aplicación.
Diagrama 26 - Editor de recursos de LWUIT
6.3.3 Componentes personalizados
Necesitamos dos funcionalidades no implementadas en LWUIT y que
conseguiremos sin demasiada dificultad extendiendo algunos de los
componentes básicos. Estas funcionalidades son, por una parte, el
poder deshabilitar opciones de menú, de manera que no sean
68
seleccionables por el usuario y por otra parte, la necesidad de
representar listas con contenido animable.
6.3.3.1 CommandEnable
La clase CommandEnable extiende la clase Command de LWUIT y
añade la posibilidad de que el comando esté habilitado o no.
Diagrama 27 - Clase UML CommandEnable
6.3.3.2 TickerList
69
Diagrama 28 - Diagrama de clases de Listas tipo marquesina
Para conseguir listas cuyo contenido sea animado (a modo de
marquesina), utilizaremos la clase TickerList que mediante su método
animate, indica al Renderer que el elemento con el foco debe
incrementar su posición en x un determinado número de píxels.
Así pues, todas las listas de la aplicación extenderán TickerList. Además,
dependiendo de cómo queramos que se pinte la animación, cada
TickerList llevará asociado un Renderer que implementará la interfaz
TickerRenderer.
A medida que vayamos desarrollando los casos de uso se explicarán los
diferentes Renderers implementados.
6.4 Flujo de control de la interfaz de usuario
El siguiente diagrama representa el flujo de control de la interfaz de
usuario relacionado con los correspondientes casos de uso:
70
Diagrama 29 - Diagrama de flujo de interfaz de usuario
71
7. Desarrollo de la aplicación
7.0 Introducción
Este capítulo incluye el desarrollo de los casos de uso organizados en
cuatro bloques:
•
•
•
•
Casos de uso de cartografía.
Casos de uso de GPS.
Casos de uso de rutas.
Casos de uso de puntos de interés.
Para cada caso de uso se explicarán los componentes del diseño de la
arquitectura, el diseño UML creado para resolver la funcionalidad,
diseño de la interfaz de usuario (si la hay) y tecnologías utilizadas.
7.1 Casos de uso de cartografía
Diagrama 30 - Componente mapa en la arquitectura
Los casos de uso de cartografía implican poder visualizar la capa de
orto-fotografías del subsistema servidor de mapas: desplazarse arriba,
abajo, izquierda, derecha y hacer zoom más y zoom menos. Además,
de definir un método para re-centrar el mapa en una determinada
72
coordenada, esto nos ayudará a resolver casos de uso relacionados
con posicionamiento GPS y añadir funcionalidad a cualquier geometría
(puntos de una ruta, puntos de interés, tramos de una ruta), permitiendo
centrar el mapa en cualquiera de ellas.
Antes de comenzar con el diseño es importante conocer cómo el
subsistema servidor de mapas ofrece la cartografía, qué otras
alternativas existen actualmente y qué diferencias hay entre ellas.
Además hay que diseñar un sistema eficiente para la gestión de
imágenes devueltas por el servidor y un sistema inteligente de caché de
imágenes.
Una vez resueltos esos asuntos, el desarrollo de los casos de uso será una
tarea sencilla de implementar.
73
7.1.1 Diseño de la arquitectura que permite la visualización
de mapas
Diagrama 31 - Componentes para visualizar mapas en la arquitectura
7.1.1.1 Servicios WMS-c (Web Map Service – caché)
El estándar WMS es una especificación definida por el OGC (Open
Geospatial Consortium) que sirve para definir con detalle qué deben
cumplir los servidores que proporcionen cartografía de manera remota.
Web Map Service (WMS) es un estándar internacional (ISO 19128: 2005
Geographic information - Web map server interface) que define un
'mapa' como una porción de información geográfica representada por
un fichero de imagen digital para mostrar en una pantalla de
ordenador. WMS es una especificación que produce mapas de datos
espaciales referenciados dinámicamente a partir de información
geográfica. Normalmente, los mapas renderizados están en un formato
de imagen tales como PNG, GIF o JPEG.
74
Un servidor WMS debe proporcionar 3 operaciones: GetCapabilities,
GetMap y GetFeatureInfo. GetCapabilities y GetMap son de obligatoria
implementación por parte del servidor, mientas que GetFeatureInfo es
opcional (y no será tratada en este documento). Por tanto, un servidor
WMS debe proporcionar a un cliente una interfaz para recibir los
parámetros estándar de cada operación y si estos parámetros son
válidos deber servir los datos correspondientes a la petición. El método
para enviar una petición a un servidor WMS es a través de una URL con
una serie de parámetros bien definidos.
7.1.1.2 ¿Qué es un tile?
Cada porción en que se corta la cartografía en un servidor WMS-c se le
conoce como tile o tesela. En este documente se utilizan los dos
términos para referirse al mismo concepto.
Las características más interesantes de un tile son: su tamaño y su
resolución.
El tamaño de un tile generalmente es 256x256, aunque puede ser
cualquier otro. En cualquier caso, los servidores WMS-c deben exponer
el tamaño del tile.
La resolución es la distancia en coordenadas del mundo real (del
sistema de referencia en el que está la capa) de un píxel para un
determinado nivel de zoom.
Un cliente deberá conocer para cada capa, cuál es el sistema de
referencia en el que están proyectadas las coordenadas, cuántos
niveles de zoom soporta dicha capa, el tamaño del tile, cual es la
extensión máxima de la capa (o el origen de coordenadas) y cuál es la
resolución para cada nivel de zoom. Así, el cliente deberá ajustar sus
peticiones a las resoluciones que soporte el servidor, ya que en caso
contrario el servidor no tendrá una imagen cacheada para dicha
petición y devolverá una excepción.
75
Diagrama 32 - Origen de coordenadas de tiles en Google Maps
Una tesela tiene su origen (0,0) en su esquina superior izquierda. Cada
tile puede ser identificado por su posición en x y su posición en y, tal
como vemos en la siguiente figura.
Diagrama 33 - Numeración de tiles en Google Maps
7.1.1.3 Diferencia entre un servidor WMS y uno cacheado
Tradicionalmente los servidores que cumplen con el estándar WMS,
respondían a los clientes que solicitaban cartografía de la siguiente
manera.
1. El cliente hacía una petición de una porción de mapa para una
de las capas del servidor de acuerdo a una operación con una
sintaxis bien definida según la especificación.
2. El servidor se encargaba de buscar entre su información vectorial
la porción solicitada por el cliente, componer una imagen y
devolverla.
76
3. Es posible que en otro momento el mismo cliente necesite que el
servidor le proporcione la misma porción de mapa y por tanto al
hacer la solicitud, el servidor se comporta de la misma manera:
busca entre su información, compone la imagen y la devuelve.
Se observa claramente que esta manera de trabajar puede resultar
ineficiente, ya que peticiones iguales pueden ser generadas por el
servidor continuamente. Además, estamos hablando de información
geográfica que puede ser de gran complejidad y el resultado (la
imagen devuelta por el servidor) debe viajar por la red, resumiendo: el
coste en tiempo puede ser elevado.
Para resolver este problema surgió la especificación WMS-c, que de
hecho todavía no es un estándar de facto, sino que existe una
recomendación promovida por OSGeo de cómo implementar
servidores de mapas cacheados conocida como TMS (Tile Map Service)
y otra promovida por OGC conocida por WMTS (Web Map Tiling
Service). Hasta el momento la más extendida es TMS que es la que
implementará el subsistema servidor de mapas.
Básicamente consiste en realizar el trabajo de ‘cortado’ de la
cartografía antes. Es decir, el servidor define un tamaño de las porciones
y un conjunto de niveles de zoom (resoluciones) que debe exponer
públicamente para que cualquier cliente los conozca. Cuando un
cliente solicite una porción de mapa, deberá ajustarse al tamaño
ofrecido por el servidor y con la resolución que soporta, el servidor
simplemente tendrá que buscar en disco la imagen pre-generada y
enviarla al cliente.
Así, un servidor WMS-c tiene algunas restricciones a la hora de solicitar
mapas:
1. Bounding Boxes (extensiones) prefijados.
2. Resoluciones (niveles de zoom) prefijada.
3. Tamaño de porciones de mapa (tiles) prefijados.
Con este mecanismo se evita la carga de operaciones que debería
soportar el servidor para generar las imágenes que solicita el cliente. En
este caso, el cliente será el encargado de realizar tantas peticiones
como necesita para componer un mapa del tamaño que desee.
Hay que distinguir entre lo que llamaremos ‘servidores de tiles’ y
servidores WMS-c. Los servidores de tiles (tales como Google Maps,
Open Street Maps, etc.), funcionan de la misma manera que los
servidores WMS-c, tienen todas las imágenes cortadas en porciones y
varios niveles de zoom. La diferencia radica en que no tienen un
77
mecanismo de descubrimiento y petición estándar de su información
cartográfica.
Vamos a ver un ejemplo de cómo sería el proceso de cortado en tiles
de la información geográfica de un servidor WMS-c:
Diagrama 34 - La Tierra como una esfera y relación latitud-longitud
Por ejemplo, podemos tener un servidor que ofrece cartografía de todo
el mundo, en coordenadas geográficas (latitud-longitud). El primer paso
es proyectar las coordenadas sobre un plano utilizando un sistema de
referencia:
Diagrama 35 - La Tierra en un plano según la proyección de Mercator
Los servidores WMS-c pueden presentar 3 perfiles dependiendo de la
proyección utilizada para representar las coordenadas, además cada
perfil debe proporcionar una lista de resoluciones soportadas
correspondientes a los niveles de zoom que soporta:
•
Global geodetic: O lo que es lo mismo coordenadas geográficas
sin proyectar (latitud, longitud). Los parámetros del perfil son:
78
•
•
•
•
•
•
•
•
Global spherical Mercator: La proyección de Mercator. Los
parámetros son:
•
•
•
•
•
•
•
•
Width: 256 px
Height: 256 px
Format: image/png
SRS: EPSG:4326
BoundingBox: -180 -90, 180 90
Resolutions: 0.703125, 0.3515625 ...
En el nivel más alto de resolución hay dos tiles.
Width: 256 px
Height: 256 px
Format: image/png
SRS: OSGEO:41001
BoundingBox:
-20037508.34
-20037508.34
20037508.34
20037508.34
Resolutions: 156543.03390625 78271.516953125 ...
En el nivel más alto de resolución hay un único tile.
Local/none: El servidor WMS-c puede especificar cualquier otro
perfil. El sistema de coordenadas será cualquiera definido por el
servidor y en el nivel de zoom 0 habrá tantos tiles como
especifique el servidor. En el caso del subsistema visor de mapas
como veremos más tarde, se utiliza como sistema de referencia
EPSG:23030 y en el nivel 0 de zoom hay dos tiles en vertical. De
manera general los parámetros pueden ser:
•
•
•
•
•
•
Width: Cualquiera, generalmente 256 px
Height: Cualquiera, generalmente 256 px
Format: Cualquiera, generalmente image/png
SRS: Cualquiera
BoundingBox: Cualquiera
Resolutions: Cualesquiera
79
Diagrama 36 - Pirámida de tiles
El siguiente paso consiste en definir los niveles de zoom. El nivel de zoom
0 está formado por una única imagen, normalmente de tamaño
256x256 píxels, que representa el mundo entero. En el siguiente nivel de
zoom, la imagen del nivel anterior se divide en 4 partes iguales de
256X256 píxels ocupando en total 512x512 píxels y así sucesivamente,
hasta llegar al nivel máximo de zoom.
Diagrama 37 - Relación entre número de tiles y niveles de zoom
Por último, cada una de esas imágenes de 256x256 píxels son
numeradas atendiendo a su posición x e y en la rejilla. En el nivel de
zoom 0 tendríamos un único tile, en el siguiente nivel 4, en el siguiente 16
y así sucesivamente.
Para nuestro ejemplo los niveles de zoom y número de tiles quedarían
así:
80
Nivel de zoom
0
1
2
N
Número de tiles
1 tile cubre el mundo entero
2x2 tiles
4x4 tiles
2nx2n tiles
Tabla 1 - Número de zoom vs número de tiles
Para nuestra aplicación nos comunicaremos con el subsistema servidor
de mapas que cumplirá con la especificación TMS, además de ser un
servidor WMS. Así pues las diferencias fundamentales entre un servidor
de tiles y el servidor con el que trabajaremos son:
OpenStreetMap (Tile Server)
No tiene un mecanismo
descubrición de servicios.
de
No tiene un mecanismo estándar
de petición de mapas.
Utiliza la proyección de Mercator.
Subsistema servidor de mapas
(WMS –TMS)
Tiene
un
mecanismo
de
descubrimiento
de
servicios
(GetCapabilities y a través de su
URL)
Tiene un mecanismo estándar de
petición de mapas (GetMap)
Puede
utilizar
cualquier
proyección.
Pueden servir capas de cualquier
temática.
Normalmente sirven una única
capa correspondiente al mundo
entero.
Tiles de 256x256
Tiles de cualquier tamaño aunque
en general son de 256x256
Tabla 2 - Comparación OSM - WMS-c
Respecto a la numeración de los tiles hay una diferencia fundamental y
es que los servidores de tiles sitúan el origen (el tile 0,0) en la esquina
inferior izquierda, mientras que los servidores TMS sitúan el origen en la
esquina inferior izquierda, de acuerdo al siguiente diagrama:
81
Diagrama 38 - Origen de coordenadas de tiles según la recomendación TMS
Con esto tenemos que un servidor WMS-c es mucho más versátil que un
servidor de tiles.
7.1.1.4 Arquitecturas de tiles y dispositivos móviles
Disponer de servidores que cachean su información cartográfica y la
transmiten en forma de tiles es muy interesante para el desarrollo de SIG
para dispositivos móviles o web.
La principal ventaja que tenemos es que los tiempos de respuesta se
reducen considerablemente, algo que es muy importante cuando se
trata de dispositivos con un ancho de banda muy limitado.
82
Al mismo tiempo, al recibir la información cartográfica en porciones, los
mapas se pueden ir ‘montando al vuelo’ y la sensación de cara al
usuario es de mayor fluidez.
Por último y como veremos en siguientes capítulos, los servidores de tiles
presentan algunas propiedades muy interesantes que permiten cachear
su información en local, con lo que el acceso a la información puede
llegar a ser casi instantáneo.
7.1.1.5 Operaciones WMS
Como hemos comentado el estándar WMS define algunas operaciones
para que cualquier cliente pueda interactuar con un servidor. Las dos
operaciones que nos interesan para este proyecto son GetCapabilities y
GetMap. A continuación definiremos brevemente cuál es su sintaxis y la
respuesta del subsistema servidor de mapas a las dos peticiones.
7.1.1.5.1 GetCapabilities
Los parámetros de una petición GetCapabilities son los siguientes:
Tabla 3 - Parámetros de GetCapabilities
Un ejemplo de petición sería:
http://194.179.111.10:8090/tilecache/tilecache.py?request=getcapabiliti
es&service=WMS
En nuestro caso, puesto que la aplicación sólo accederá a un servidor
conocido, la configuración del servidor será conocida en tiempo de
compilación, con lo cual no necesitaremos obtener una respuesta del
servidor en tiempo de ejecución. De todas maneras y en futuras
revisiones, la operación GetCapabilities es interesante para poder
acceder a la información cartográfica de cualquier servidor de mapas.
83
Puesto que el subsistema servidor de mapas también cumple con la
especificación TMS es posible acceder a la misma información que
devolvería mediante la operación GetCapabilities, accediendo a él de
la siguiente manera:
Accedemos a la raíz del servidor:
http://194.179.111.10:8090/tilecache/tilecache.py/1.0.0
y a la capa que nos interesa para la aplicación móvil desde:
http://194.179.111.10:8090/tilecache/tilecache.py/1.0.0/ortoSigPac
Obteniendo como respuesta el siguiente documento XML:
Cada etiqueta tiene el siguiente significado:
•
•
•
•
•
•
Title: El título de la capa, en este caso, se trata de ortofotos de la
comunidad de Extremadura.
SRS: El sistema de referencia en el que están representadas las
coordenadas de la capa.
BoundingBox: La extensión del mapa que corresponderá a la
región de Extremadura codificada en EPSG:23030.
Origin: Indica las coordenadas del origen del mapa, como
podemos ver, se trata de la esquina inferior izquierda del mapa.
TileFormat: Incluye atributos para definir el tamaño del tile
(256X256) y el tipo de imagen (JPEG)
TileSets: Contiene la URL para acceder a cada nivel de zoom y la
resolución (unidades por píxel) de cada nivel de zoom.
Para ser ‘cacheables’ los tiles del servidor deben tener bounding boxes
alineados a una serie de rejillas cada una con una determinada
resolución (cada vez mayor). El origen de las rejillas está en la esquina
inferior izquierda del bounding box de cada capa. Al hacer una
84
petición el bounding box que se utilice debe estar alineado a la rejilla
que proporciona el servicio, es decir, las coordenadas del bounding box
deben ser igual al origen de la rejilla sumado a un múltiplo del tamaño
del tile en píxels multiplicado por una de las resoluciones soportadas por
la capa.
Veamos un ejemplo, con cartografía extraída del servidor para
entender mejor los atributos de una capa.
Diagrama 39 - Parámetros de un tile
Aunque es posible acceder a un tile de manera similar a como se
realizaba en un servidor de tiles, esto es, especificando en la URL el nivel
de zoom, la posición en x del tile y la posición en y:
http://194.179.111.10:8090/tilecache/tilecache.py/1.0.0/ortoSigPac/0/0/
0.jpeg
En nuestro caso, utilizaremos la operación GetMap.
85
7.1.1.5.2 GetMap
Tabla 4 - Parámetros GetMap
Por ejemplo, la siguiente consulta, devolvería la imagen del Diagrama
40.
http://194.179.111.10:8090/tilecache/tilecache.py?LAYERS=ortoSigPac&FORMAT=i
mage/jpeg&SERVICE=WMS&VERSION=&REQUEST=GetMap&STYLES=&EXCE
PTIONS=&SRS=EPSG:23030&BBOX=107897.0,4201010.0,322936.883776,4416049.
883776&WIDTH=256&HEIGHT=256
7.1.1.6 Conversión de coordenadas entre sistemas de
referencia
86
La conversión de coordenadas entre sistemas de referencia es un
proceso complicado que queda fuera del alcance de este proyecto y
que podría explicar con más detalle un Cartógrafo. Para el caso que
nos ocupa, nos limitaremos a utilizar el trabajo realizado para el
proyecto gvSIG que proporciona los métodos necesarios para realizar la
conversión entre coordenadas geográficas EPSG:4326 a EPSG:23030 (y
otros sistemas de referencia) mediante la clase ConversionCoords.
7.1.1.6.1 La clase Math en CLDC 1.1
La
conversión
de
coordenadas
necesita
de
operaciones
trigonométricas que por su complejidad la clase Math de J2ME no
proporciona. Esto supondría una gran limitación, por ello, se ha utilizado
una clase libre (Float11) con los métodos necesarios para realizar dichas
operaciones.
7.1.1.7 Arquitectura de tiles
Para poder hacer peticiones de tiles y pintarlas sobre la pantalla de una
manera eficiente se propone el siguiente diseño:
87
Diagrama 40 - Diagrama de clases de arquitectura de tiles
Los objetivos a conseguir con el diseño anterior son los siguientes:
1. Poder transformar coordenadas en píxels a coordenadas del
mundo real de una manera sencilla.
2. Poder realizar peticiones de tiles de manera concurrente, de
manera que el usuario no pierda en ningún momento el control
de la aplicación.
88
3. Realizar sólo las peticiones necesarias, cancelando las que ya no
son útiles (por ejemplo, al intentar acervar el zoom varias veces
seguidas)
4. Cachear los tiles descargados para que el acceso a red sea
mínimo.
5. Poder mostrar en pantalla información de distinto tipo: mapas
(imágenes), puntos de interés (puntos), rutas (líneas).
A continuación se explica con detalle el papel de cada una de las
clases del diseño.
7.1.1.7.1 La clase Map, gestión de la información geográfica y
proceso de pintado
89
90
Diagrama 41 - Clase UML Map
La clase Map extiende a la clase Component de LWUIT. Por tanto,
vamos a poder definir su tamaño y podrá ser colocado como un
componente más en un formulario LWUIT. Para esta aplicación, el
formulario principal tendrá un único componente que será el mapa con
tamaño igual al tamaño de la pantalla, pero podría darse el caso en
que nos interesara tener el mapa ocupando una porción de pantalla
(por ejemplo, la mitad) y el resto de la pantalla con otro tipo de
información.
Las propiedades más importantes de Map, van a ser el punto central del
mapa expresado en coordenadas del mundo real (en nuestro caso, en
EPSG:23030) y la resolución del nivel de zoom actual. Con estas dos
propiedades y con la ayuda de la clase ViewPort vamos a poder
conocer cuáles son las porciones de mapa que necesitamos cada vez
que desplacemos el mapa o lo acerquemos (alejemos).
Además, el componente Map deberá capturar y manejar los eventos
de las teclas del teléfono para realizar la navegación y deberá
gestionar el pintado de las distintas capas.
7.1.1.7.2 La clase ViewPort, correspondencia entre coordenadas
del mundo real y píxels
91
Diagrama 42 - Clase UML Viewport
La clase ViewPort se utiliza para conocer la correspondencia entre un
pixel de la pantalla y su coordenada en el mundo real y viceversa. Para
ello dispone de la resolución actual del nivel de zoom del mapa, o lo
que es lo mismo, la distancia en el sistema de coordenadas del mapa
de un pixel de la pantalla.
7.1.1.7.3 La clase Layer, el concepto de capa en SIG
92
93
Diagrama 43 - Diagrama de clases de capa
En los SIG la información que se muestra en pantalla se organiza en
capas. De la misma manera que se hace en las aplicaciones de diseño
gráfico, las capas en los SIG, se utilizan para gestionar información de
distinta índole y poder aplicar operaciones sobre ellas. Es habitual tener
una capa base con cartografía de fondo, por ejemplo, fotos aéreas de
una población. Encima de ella una capa vectorial (polígonos) de
parcelas, a continuación otra capa de líneas correspondiente a
carreteras, etc. Se podrían hacer operaciones como intersectar las
geometrías de las capas, unir, aplicar la diferencia, etc.
En nuestro caso, no tiene demasiado sentido soportar gran cantidad de
capas (y operaciones), ya que el dispositivo móvil no sería capaz de
trabajar con todas ellas a la vez, así contaremos con una capa base,
correspondiente a la cartografía de fondo, en este caso, ortofotos de
Extremadura; y además, se superpondrá otra capa vectorial, de líneas y
puntos, correspondiente a rutas y puntos de interés, respectivamente.
Así pues, cada capa será la responsable de pintarse a sí misma,
conocerá cuáles son las entidades que debe mostrar en pantalla y
dónde colocarlas. En el caso de la capa base, lo que pintará será una
composición de imágenes y en el caso de la capa vectorial, pintará las
geometrías (líneas y puntos) descritas anteriormente. Para conocer cuál
es la posición dónde pintar las entidades cada capa deberá saber cuál
es su posición con respecto al origen de coordenadas de la pantalla y
además tener acceso a la clase ViewPort para poder realizar la
transformación de las coordenadas de las entidades a píxels de la
pantalla.
7.1.1.7.4 La clase Grid, gestión del mínimo número de tiles
94
95
Diagrama 44 - Clase UML Grid
La clase Grid es muy importante en el proceso de pintado de la capa
base. Como hemos visto, el servidor de mapas al que vamos a acceder
nos va a devolver teselas correspondientes a porciones de mapa que
compondremos sobre la pantalla. La clase Grid nos va a permitir
gestionar estas teselas.
En primer lugar, es importante montar una rejilla del tamaño suficiente
para que cubra toda la pantalla, es decir, la rejilla debe contener el
número máximo de teselas que pueden ser mostradas en la pantalla al
mismo tiempo.
Diagrama 45 - Ejemplo de Grid para un tamaño de pantalla de 240x320
Como ya sabemos el tamaño estándar de las teselas es de 256x256
píxels. Así por ejemplo, en una pantalla de 240x320 el número máximo
de teselas caben en pantalla es 6. Este cálculo se debe hacer
dinámicamente en tiempo de ejecución y nos va a permitir tener un
componente (el mapa) del tamaño que nosotros queramos, en este
caso, del tamaño de la pantalla y donde los recursos de memoria van a
estar optimizados.
Además la clase Grid se encargará de gestionar las peticiones de
96
teselas conforme se navega por el mapa, para ello, se utilizará
Multithreading.
7.1.1.7.5 La clase Tile, abstracción de una tesela.
Diagrama 46 - Diagrama de clases de teselas
Hemos visto que la clase Grid gestionará las peticiones de las diferentes
teselas y para ello contará con un array de Tiles. Un Tile deberá saber su
97
posición relativa dentro de la rejilla, contendrá además la imagen
correspondiente a su porción de mapa y la URL necesaria para obtener
dicha imagen.
7.1.1.7.6 La clase Extent
98
Diagrama 47 - Clase UML Extent
Un Extent representa un rectángulo en coordenadas del mapa y que se
utiliza para saber, cuál es la extensión que ocupa el mapa o cada una
de las teselas.
7.1.1.8 Diseño sistema eficiente de gestión de tiles
Diagrama 48 - Multithreading en la arquitectura
7.1.1.8.1 La clase ThreadPool, gestión de hilos para operaciones
bloqueantes
99
Diagrama 49 - Clase UML ThreadPool
En la mayoría de aplicaciones y especialmente en aplicaciones para
dispositivos móviles es importante que el usuario tenga la sensación de
que nunca pierde el control de la misma. En nuestro caso,
especialmente mientras el usuario navega, se van a realizar una serie de
operaciones (accesos a disco o a Internet) que consumen muchos
recursos. Son operaciones bloqueantes ya que pueden tardar varios
segundos en terminar y si son lanzadas desde el mismo hilo que maneja
la interfaz de usuario, ésta queda ‘congelada’ y por tanto no responde
a los eventos del usuario (presionar teclas) hasta que terminan estas
operaciones.
Para evitar que la aplicación quede en este estado, es necesario que
las operaciones de las que hemos hablado se lancen en hilos diferentes
al hilo principal. Además, tenemos la complicación de que el número
de operaciones bloqueantes puede llegar a ser muy elevado.
En el mejor de los casos podríamos tener un usuario que esperara cada
vez a que terminara una operación para solicitar la siguiente, pero por
lo general, los usuarios de dispositivos móviles, son usuarios impacientes.
Para entender mejor el problema pongamos un escenario típico de
navegación:
El usuario impaciente se encuentra en el nivel más alto de zoom y quiere
llegar al nivel más próximo al suelo. Hay ocho niveles de zoom pero el
usuario impaciente no lo sabe y decide presionar repetidamente (por
ejemplo, veinte veces) la tecla para acercar el mapa hasta que
consigue llegar al nivel más próximo.
100
Si la aplicación no gestiona correctamente los hilos cada vez que el
usuario solicita acercar el mapa, lo que pasaría es lo siguiente:
1. El usuario impaciente solicita acercar el mapa.
2. El mapa captura el evento, actualiza su nivel de zoom y manda la
orden a la capa base.
3. La capa base recalcula su posición relativa a la pantalla y manda
al Grid recalcular las teselas.
4. El Grid recalcula las teselas y lanza un hilo por cada petición.
5. Cuando el servidor responde cada Tile pinta su imagen en la
posición relativa dentro de la rejilla.
6. Como el usuario impaciente no ha perdido el control sobre el
mapa, decide volver a solicitar acercar el mapa, antes de que el
servidor responda.
7. Las peticiones anteriores están en curso en hilos diferentes, así que
el mapa captura el evento, repite el proceso descrito y se vuelven
a lanzar los hilos necesarios para pedir las teselas.
El proceso se realiza repetidamente, mientras el usuario impaciente
sigue haciendo peticiones, llega un momento en que la aplicación ha
lanzado un número elevado de hilos que la máquina virtual es incapaz
de gestionar, además, por el camino peticiones más recientes han
terminado antes que otras más antiguas y hay teselas de diferentes
niveles de zoom pintadas en pantalla.
Para solucionar este problema y gestionar correctamente peticiones en
‘background’ se propone la utilización del patrón Thread pool.
El patrón consta de:
•
•
Un array de hilos.
Una cola de peticiones.
El objetivo es lanzar un número determinado de hilos e ir encolando las
peticiones. Los hilos se irán repartiendo el trabajo e irán cogiendo las
peticiones de la cola, cuando no haya más trabajo quedarán a la
espera de nuevas peticiones. De esta manera se consigue tener
limitado el número de hilos en ejecución y la cancelación de peticiones
inútiles es tan simple como limpiar la cola y marcar como no válidas las
tareas de los hilos en ejecución. El escenario propuesto anteriormente
funcionaría de la siguiente manera:
1. El usuario impaciente solicita acercar el mapa.
2. El mapa captura el evento, actualiza su nivel de zoom y manda la
orden a la capa base.
3. La capa base recalcula su posición relativa a la pantalla y manda
al Grid recalcular las teselas.
101
4. El Grid recalcula las teselas encola las peticiones en la cola del
Thread pool.
5. Cuando el servidor responde cada Tile pinta su imagen en la
posición relativa dentro de la rejilla.
6. Como el usuario impaciente no ha perdido el control sobre el
mapa, decide volver a solicitar acercar el mapa, antes de que el
servidor responda.
7. Algunas peticiones anteriores están en curso en hilos diferentes así
que se cancelan, otras están en la cola así que se eliminan de la
cola, el mapa captura el evento, repite el proceso descrito y se
vuelven encolar las peticiones.
8. Sucesivamente conforme el usuario impaciente solicita acercar el
mapa, las peticiones anteriores se van cancelando y sólo la última
petición es válida, termina y se muestra en pantalla el resultado,
en este caso, el mapa.
7.1.1.8.1 Jerarquía de tareas en background
Diagrama 50 - Diagrama UML de jerarquía de tareas
102
7.1.1.9 Diseño de cache de teselas
Para acelerar la carga de teselas y conseguir que la aplicación pueda
funcionar en modo desconectado se proponen dos tipos de cache:
1. Por una parte se cachean las teselas descargadas desde el
servidor WMS a disco. Para ello se estudiarán diferentes
alternativas en la persistencia.
2. Por otra parte para acelerar el rendimiento de la aplicación, se
cachearán en memoria los últimos tiles accedidos.
Diagrama 51 - Diagrama de niveles de cache
La aplicación hará uso de dos cachés, una pequeña en memoria para
tiles recientes, otra en disco para evitar continuos accesos a la red y por
último los recursos que no encuentren en local se buscarán en el
servidor WMS-c.
El siguiente diagrama nos ayuda a entender mejor el sistema de cachés:
103
Diagrama 52 - Diagrama de actividad de obtener tile
7.1.1.9.1 Diseño de caché de tiles en disco
La caché de teselas en disco consiste en almacenar en la memoria
física del teléfono las imágenes obtenidas del servidor WMS con dos
objetivos:
1. Evitar repetir accesos al servidor para obtener la misma tesela y
por tanto disminuir el acceso a Internet (que en general supone
un coste en dinero).
2. Acelerar la carga de teselas ya que el acceso a disco en todos
los casos va a ser más rápido que al servidor.
7.1.1.9.2 JSR-75 vs RecordStore
Actualmente J2ME ofrece dos alternativas para persistir datos en la
memoria del teléfono.
104
1. Como mecanismo estándar de persistencia ofrece RMS –
Record Management Store, que es un modelo propio de
persistencia donde la información se almacena en registros.
2. Opcionalmente existe la especificación JSR-75, que
básicamente consiste en persistir en el sistema de ficheros
del teléfono.
Es conveniente comparar ambas
necesidades de la aplicación:
RMS
Es
el
mecanismo
estándar
de
persistencia.
No requiere de ningún
permiso especial tanto
para leer como para
escribir.
En general, muchos
teléfonos restringen el
tamaño
disponible
para RMS
No
existe
acceso
aleatorio a los datos
almacenados,
por
tanto, el rendimiento
puede
ser
bajo
cuando se almacena
gran
cantidad
de
información.
La implementación es
transparente
al
desarrollador
y
en
general, no es posible
acceder a los datos
opciones
JSR-75
Es una librería opcional
y es posible que no
todos los teléfonos la
implementen.
Es
una
librería
restringida
por
el
sistema de permisos
de J2ME. Por tanto,
como mínimo será
necesario firmar la
aplicación y es posible
que, en algunos casos,
no sea suficiente.
No hay restricción.
Podemos almacenar
tantos datos como
quepan
en
la
memoria del teléfono
o en la tarjeta de
memoria.
Tampoco
existe
acceso aleatorio, pero
se puede acelerar el
acceso
a
la
información,
diseñando un pseudoíndice
espacial
mediante el sistema
de directorios.
La
implementación
también
es
transparente pero, los
datos se almacenan
en disco y es posible
de
acuerdo
a las
¿Qué necesitamos?
Sería conveniente un
mecanismo lo más
expandido posible.
Sería conveniente no
necesitar de ningún
permiso especial.
La aplicación va a
acceder
a
gran
cantidad
de
información
y
es
importante
poder
almacenar todos los
datos.
Uno de los objetivos
de la caché en disco
es acelerar la carga
de datos.
Puede resultar útil, por
ejemplo,
el
poder
descargar las teselas
desde un PC y luego
transferirlas al teléfono.
105
almacenados desde acceder a ellos desde
fuera de la aplicación. el gestor de archivos
del teléfono, lo que
puede
resultar
útil
para
compartir/consultar la
información.
Tabla 5 - Comparación RMS vs JSR-75
Así pues, a nivel de rendimiento la librería JSR-75 es mejor, aunque es
posible que sea menos compatible. RMS nos da mayor compatibilidad
pero no va a dar la suficiente versatilidad como para almacenar gran
cantidad de teselas, por tanto, la elección es JSR-75 que además como
veremos a continuación, nos permite diseñar un mecanismo eficiente
de acceso a las imágenes almacenadas.
7.1.1.9.3 Almacenamiento en disco
Como hemos visto, la aplicación va a utilizar internamente coordenadas
en metros para realizar las peticiones al servidor WMS, pero para poder
almacenar/recuperar las imágenes devueltas por el servidor a/desde
disco necesitamos diseñar un mecanismo que haga corresponder una
petición GetMap de una tesela, con el archivo que representa la
imagen que devolvería el servidor y que tendremos en disco.
Para ello nos vamos a aprovechar de dos propiedades importantes de
los servidores ‘tilecache’ que son:
•
•
La numeración de teselas.
Los quadkeys.
7.1.1.9.4 Conversión de coordenadas a tiles
Como ya hemos visto, actualmente existe una especificación
promovida por OSGeo utilizada para la definición de servidores de tiles
que se llama Tile Map Service y que es la especificación que sigue el
servidor de mapas al que estaremos accediendo.
Dicha especificación define el sistema de coordenadas en función de
los tiles que devuelve el servidor.
106
Diagrama 53 - Diagrama de origen de coordenadas según la recomendación TMS
En la imagen podemos ver que el origen de coordenadas se fija en la
esquina inferior izquierda, ese primer tile se numera como x=0 y=0 y a
partir de él se pueden numerar los tiles a la izquierda y hacia arriba. Así
que podemos definir un tile por su nivel de zoom, su posición en x y su
posición en y.
Para realizar la conversión de coordenadas UTM a número de tile,
utilizaremos la siguiente fórmula:
funcion entero[] metersToTile(double mx, double my,
resolution, double origX, double origY) {
//mx = coordenada en x
//my = coordenada en y
//resolution = metros por pixel del nivel de zoom actual
// origX = coordenada en x del origen de la capa
//origY = coordenada en y del origen de la capa
double
entero px = ((mx + originX) / resolution);
entero py = ((my + originY) / resolution);
entero pixelsPerTIle = 256;
entero tx = (Math.ceil(px / (pixelsPerTile)));
entero ty = (Math.ceil(py / (pixelsPerTile)));
devolver nuevo entero[]{tx, ty};
}
107
Si trabajáramos con dispositivos potentes (un PC por ejemplo) sería
suficiente con crear en disco una carpeta para cada nivel de zoom y
colocar dentro las imágenes nombrándolas con su número de tile (x_y)
de la siguiente manera:
Diagrama 54 - Estructura de directorios de caché ineficiente
En nuestro caso trabajamos con dispositivos con capacidad de
procesamiento tan limitada que para niveles de zoom muy profundos,
en una carpeta podríamos tener un número elevado de imágenes, por
ejemplo, en el nivel 7: 27X27 = 16384 y resultaría ineficiente intentar
acceder a esos ficheros.
7.1.1.9.5 Conversión de tiles a quadkeys
Una propiedad mucho más interesante que los números de tile son los
quadkeys. Un quadkey es un código que identifica unívocamente un
tile, y nos permite conocer, además de su posición dentro del sistema
de coordenadas, cuáles son sus padres y cuál es su nivel de zoom.
Diagrama 55 - Diagrama de correspondencia entre quadkeys
108
Los quadkeys nos van a ser útiles por dos motivos:
1. Con un quadkey podemos saber cuáles son los padres de un
determinado tile. De esta manera podemos replicar el espacio de
quadkeys al sistema de ficheros de la siguiente manera:
Diagrama 56 - Estructura de directorios de caché eficiente
Así tenemos, que cada carpeta del sistema de ficheros va a tener
en su interior como máximo 5 ficheros que son, 4 directorios y un
archivo de imagen incrementando la eficiencia al acceder a la
imagen.
2. La conversión de número de tile a quadkey es sencilla.
Que sólo tendremos que modificar para introducir el carácter ‘\’ y
obtener una ruta relativa al directorio de la aplicación donde
guardaremos las teselas.
Con el mecanismo diseñado tenemos un sistema de directorios donde
el acceso a una imagen es casi directo. Así pues, el procedimiento a
seguir para guardar/cargar un tile en/de disco es el siguiente:
109
1. Se transforma del sistema de coordenadas en metros a
número de tile, tomando como coordenada el centro del
tile:
mx, my = Coordenadas en EPGS:23030 del centro del
tile.
originX, originY = Coordenadas del origen del
Bounding Box de la capa según el perfil del servidor.
Resolution = Resolución (metros por píxel) del nivel
de zoom actual.
pixelsPerTile = 256 px.
int px = (int) ((mx + originX) / resolution);
int py = (int) ((my + originY) / resolution);
int tx = (int) (Math.ceil(px / (pixelsPerTile)));
int ty = (int) (Math.ceil(py / (pixelsPerTile)));
2. Se transforma de número de tile a ruta relativa de directorio
utilizando quadkey:
StringBuffer quadKey = new StringBuffer();
for (int i = levelOfDetail; i > 0; i--) {
char digit = '0';
int mask = 1 << (i - 1);
if ((tileX & mask) != 0) {
digit++;
}
if ((tileY & mask) != 0) {
digit++;
digit++;
}
quadKey.append(digit);
}
3. Para guardar: si no existe el directorio se crea y se guarda la
imagen.
4. Para cargar: si no existe el directorio se devolverá null y si
existe se cargará la imagen en memoria.
7.1.1.9.6 Diseño caché de tiles LRU en memoria
La caché de teselas en memoria consiste en almacenar en el espacio
de memoria del teléfono para aplicaciones Java un número pequeño
de tiles de manera que teselas que han sido visitadas recientemente se
carguen rápidamente.
110
Una vez más se presenta un problema debido a que el tamaño del
heap Java en teléfonos es variable. Los teléfonos más actuales no
imponen ninguna restricción, pero otros teléfonos limitan el tamaño.
Uno de los requisitos importantes de la aplicación a tener en cuenta
durante el diseño, es que la aplicación debe estar lista para ‘descargar
y usar’. Es decir, en este caso, (y en muchos otros), lo ideal sería que el
usuario pudiera definir, la cantidad de espacio que la caché en
memoria va a utilizar, así podría optimizar el uso de la memoria por parte
de la aplicación. Como no va a ser así, se toma la decisión de definir la
caché en memoria a lo que ocupen 12 teselas, que en la mayoría de los
casos va a suponer dos niveles de zoom.
Se utilizará una caché LRU (last recent used), de manera que las teselas
más nuevas, sustituirán a las más antiguas y en memoria siempre
tendremos las últimas 12 teselas visitadas. La implementación a utilizar
será la del proyecto ‘openbasemovil’ licenciado bajo GPL y que por
tanto podemos utilizar sin ningún problema.
La manera en que funcionará esta caché es la siguiente:
1.
2.
3.
4.
Al arrancar la aplicación, la caché está vacía.
Antes de cargar un nuevo tile se busca siempre en memoria.
Si está, se pone en primera posición.
Si no está, se descargará desde disco o de internet y se pondrá en
primera posición en memoria, eliminando siempre si es necesario
la tesela más antigua de la caché.
7.1.1.10 El proceso de pintado
El siguiente diagrama muestra las clases involucradas en el proceso de
pintado del mapa:
111
Diagrama 57 - Clases implicadas en el proceso de pintado del mapa
En la parte superior del diagrama tenemos la clase TileForm que
extiende la clase Form de LWUIT. Todas las clases involucradas
comparten el mismo objeto Graphics heredado de TileForm.
Map es un componente añadido a TileForm por tanto, LWUIT se encarga
de pintarlo. En la implementación del pintado del mapa, se itera sobre
la lista de capas y se llama a su método de pintado.
112
Si se trata de la capa base, ésta llama al Grid que itera sobre su array
de Tiles. Cada uno de ellos pintará su imagen, en una posición
determinada.
En el caso de LayerVect, iterará sobre sus FeatureCollection, que a su
vez iterará sobre cada una de sus geometrías y las pintará en pantalla,
utilizando la clase ViewPort para convertir sus coordenadas en píxels.
Por último, se pintará la clase TransparentCanvas, encargada de pintar
en un acetato la barra de zoom y el icono del GPS.
7.1.2 Diseño de los casos de uso de cartografía
Una vez definida la arquitectura necesaria para visualizar mapas, el
diseño de casos de uso es una tarea sencilla que se detalla en los
siguientes dos apartados.
7.1.2.1 Navegar por el mapa
El mapa se puede navegar con las teclas de dirección del teléfono en
cuatro direcciones: arriba, abajo, izquierda, derecha.
Con la arquitectura de tiles diseñada, el caso de uso se puede resumir
con el siguiente diagrama UML de secuencia:
Diagrama 58 - Diagrama de secuencia de navegación de mapa – parte 1
113
LWUIT recoge los eventos del teclado y utiliza un hilo que escucha
dichos eventos y los envía al formulario.
Cuando el formulario recibe un evento, en función de la tecla envía el
evento pan al mapa, con una cantidad prefijada de píxels (20 px).
El mapa llama al ViewPort para que recalcule el nuevo centro en
coordenadas del mundo real y a continuación se recorren todas las
capas del mapa (generalmente la capa base y una capa vectorial) y
se les dice que se muevan a la nueva posición.
Para el caso de la capa base:
Diagrama 59 - Diagrama de secuencia de navegación de mapa – parte 2
La capa le dice al Grid a dónde debe mover los tiles, el Grid en primer
lugar comprueba si van a hacer falta nuevos tiles. Si la respuesta es
positiva, los tiles que quedan fuera de la pantalla se destruyen.
A continuación, se cancelan las tareas anteriores que estuvieran
descargando tiles, llamando a clearAll del ThreadPool.
El Grid, recorre su array con los tiles, calcula la posición y el extent para
cada tile y crea una nueva tarea (DownTask) con toda la información
necesaria para descargar el tile, asigna cada tarea al ThreadPool y
finalmente, devuelve el control al mapa.
Por su parte, el ThreadPool asíncronamente inicia cada tarea en un hilo
diferente, que buscarán la imagen correspondiente al extent del tile
que les corresponde (de acuerda al sistema de cachés visto) y
finalmente solicita al mapa que repinte esa porción de pantalla.
114
7.1.2.2 Centrar mapa
Hay dos situaciones en las que es necesario centrar el mapa:
1. El usuario hace zoom más o zoom menos sobre el mapa.
2. La aplicación necesita centrar el mapa sobre unas
coordenadas:
• Las coordenadas del GPS
• Las coordenadas de una geometría
Para el caso en el que cambia el nivel de zoom:
Diagrama 60 - Diagrama de secuencia de centrar mapa con cambio de zoom
Es necesario actualizar la resolución actual del mapa y a continuación
llamar al moveTo de las capas indicando que debe repintar el mapa.
Esto quiere decir que el Grid destruirá los tiles y se cancelarán las
anteriores peticiones en curso.
Para el caso en que el mapa se recentra sobre una geometría o
coordenadas del GPS:
115
Diagrama 61 - Diagrama de secuencia de centrar mapa sin cambio de zoom
Se comprobará si el Extent de la capa base contiene el punto en
cuestión, si la respuesta es afirmativa, simplemente se mueve la capa a
ese punto, sino, habrá que recentrar el mapa como si hubiera
cambiado
el
nivel
de
zoom.
116
7.2 Obtener localización y detener GPS
Diagrama 62 - Localización GPS en la arquitectura
7.2.1 JSR-179 Location API
J2ME cuenta con una API (un paquete opcional) que permite abstraer
al desarrollador de las peculiaridades de los sistemas de
posicionamiento global. Normalmente, los satélites que proporcionan
información de posicionamiento, suelen enviar los datos codificados en
trazas NMEA con un formato determinado, bien, pues JSR-179, entre
otras cosas decodifica esas trazas de manera que podemos acceder
directamente a las coordenadas expresadas en grados.
La API proporciona las siguientes clases e interfaces en el paquete
javax.microedition.location:
•
AddresInfo:
Es una clase contenedora de la dirección postal de una
localización.
117
•
•
•
•
•
•
•
•
•
•
•
•
Coordinates:
Es una clase contenedora de los atributos latitud,
longitud y altitud de una localización. Para ello utiliza el datum
WGS84.
Criteria: Contiene atributos que representan requisitos que debe
cumplir un LocationProvider para proporcionar localizaciones.
Landmark: Esta clase representa un punto de interés, es decir, un a
localización
con
nombre,
descripción,
coordenadas
(QualifiedCoordinates) y opcionalmente una dirección (AddressInfo).
LandmarkException.
LandmarkStore: Permite abstraer la gestión de puntos de interés
(Landmark) en la memoria interna del teléfono.
Location: Representa información acerca de una localización, tal
como, coordenadas (QualifiedCoordinates), precisión, velocidad,
etc.
LocationException.
LocationListener: Es una interfaz que representa un listener que
recibe eventos asociados a un LocationProvider.
LocationProvider: Representa un origen desde el que se obtiene la
información de localización (Location).
Orientation: Representa la orientación física del terminal.
ProximityListener: Es una interfaz que representa un listener que
recibe eventos asociados a unas determinadas coordenadas
establecidas por el desarrollador.
QualifiedCoordinates: Representa unas coordenadas como latitud,
longitud y altitud asociadas a un nivel de precisión.
A la hora de configurar los permisos de nuestra aplicación debemos
tener en cuenta que el acceso a algunos métodos de la API tienen
acceso restringido, por tanto deberemos especificar el nombre del
permiso correspondiente en el manifiesto de la aplicación, de acuerdo
con la siguiente tabla:
Nombre del permiso
Métodos protegidos por el permiso
javax.microedition.location.Location
LocationProvider.getLocation(),
LocationProvider.setLocationListener(),
LocationProvider.getLastKnownLocation()
javax.microedition.location.Orientation
Orientation.getOrientation()
javax.microedition.location.ProximityListener
LocationProvider.addProximityListener()
javax.microedition.location.LandmarkStore.re
ad
LandmarkStore.getInstance(),
LandmarkStore.listLandmarkStores()
118
javax.microedition.location.LandmarkStore.w
rite
LandmarkStore.addLandmark(),
LandmarkStore.deleteLandmark(),
LandmarkStore.removeLandmarkFromCate
gory(), LandmarkStore.updateLandmark()
javax.microedition.location.LandmarkStore.c
ategory
LandmarkStore.addCategory(),
LandmarkStore.deleteCategory()
javax.microedition.location.LandmarkStore.m
anagement
LandmarkStore.createLandmarkStore(),
LandmarkStore.deleteLandmarkStore()
Tabla 6 - Tabla de permisos de JSR-179
En
nuestro
caso,
bastará
con
agregar
el
permiso
javax.microedition.location.Location.
7.2.2 Diseño del caso de uso
Tras estudiar las posibilidades de la API JSR-179 se selecciona un
subconjunto que proporcione las funcionalidades necesarias para
cumplir los requisitos del caso de uso. Por ejemplo, no necesitamos nada
de la funcionalidad de proximidad, orientación y puntos de interés.
Se propone un diseño en el cual exista una clase (LocationData) que
implemente la interfaz LocationListener, esta clase, será la encargada de
obtener la posición del dispositivo y enviar la orden para centrar el
mapa. Los métodos que implementa de la interfaz son locationUpdate() y
providerStatusListener(), ambos deberán ejecutarse en un hilo diferente del
hilo principal de la aplicación, puesto que, ambas operaciones pueden
consumir gran cantidad de tiempo y bloquearían la aplicación de
ejecutarse en el mismo hilo. Sendos métodos contarán con una guarda
en sus hilos que comprobará un flag booleano (el atributo ‘stop’) para
pausar la ejecución del hilo y otro flag (el atributo ‘kill’) para detener la
ejecución.
De acuerdo con la especificación de la API, las coordenadas están
expresados en grados, mientras que según la especificación de nuestra
aplicación, las coordenadas de la cartografía suministrada está
expresada en metros con el sistema de referencia EPSG:23030, por
tanto, es necesario realizar la conversión de coordenadas geográficas a
metros. Para realizar esta operación se utiliza la clase de utilidades
ConversionCoords tomada del proyecto gvSIG y adaptada a nuestra
aplicación utilizando algunos métodos matemáticos de la clase Float11.
Por otra parte, contaremos con otra clase ConfigurationProvider, que
contendrá la configuración del proveedor y comprobará si es posible la
obtención de localización GPS. La aplicación sólo debe instanciar esta
clase una vez, por tanto, habrá que utilizar el patrón Singleton.
119
A continuación el diagrama de clases UML correspondiente al diseño
propuesto:
Diagrama 63 - Diagrama de clases del paquete gps
Por otro lado, para entender mejor los estados por los que puede pasar
la clase LocationData, encargada del proceso de adquisición de
localización, se diseña la siguiente máquina de estados:
120
Diagrama 64 - Diagrama de transición de estados de la clase LocationData
Al estado ‘creado’ se llega obteniendo de la clase ConfigurationProvider,
una instancia de LocationProvider que cumpla las restricciones definidas
en Criteria. Estas restricciones dada la naturaleza de nuestra aplicación
que será usado en el ámbito turístico, serán las mínimas posibles,
indicando NO_REQUERIMENT en los parámetros de Criteria siempre que sea
posible.
Una vez se obtiene la primera localización, nos encontramos en el
estado ‘posicionando’, en el que periódicamente se irán obteniendo
nuevas posiciones y se irá re-centrando el mapa.
Hay cuatro casos posibles en los que pasaremos al estado ‘parado’:
1. Llega un evento providerStatusChanged indicando que se ha perdido
el servicio o similar.
2. Estando en la pantalla desde donde visualizamos el mapa,
mostramos el menú o accedemos a otra pantalla.
3. Estando en la pantalla de ‘selección de puntos de ruta’, volvemos
al mapa tras haber seleccionado alguno de estos 3 comandos:
Selección ubicación de origen, selección ubicación destino,
añadir punto de paso.
4. El usuario explícitamente solicita detener el GPS.
121
Estando en el estado ‘parado’
‘posicionando’ de tres maneras:
podemos
volver
al
estado
1. Tras llegar un evento providerStatusChanged indicando que se ha
restablecido el servicio.
2. Al volver al mapa desde otra pantalla o al ocultar el menú,
siempre que no estemos seleccionando un punto de ruta como se
describía en el anterior punto 3.
3. Habiendo seleccionado la opción de parar el GPS, el usuario
selecciona explícitamente la opción de reanudar el GPS.
Desde cualquiera de los 3 estados es posible llegar al estado final, en
que los dos hilos son cerrados y se liberan los recursos. A este estado se
llega cuando se cierra la aplicación.
7.2.3 Interfaz de usuario del caso de uso
La interfaz para este caso de uso es bastante simple, puesto que el
usuario sólo deberá activar o desactivar la localización mediante GPS,
siendo la clase LocationData la que vaya recogiendo los eventos y recentrando el mapa. Por tanto, será suficiente con incluir una entrada en
el menú principal de la aplicación con el texto ‘Obtener localización’.
Cuando nos encontremos en el estado ‘posicionando’ el texto del
comando de menú será detener GPS, y siempre que estemos en el
estado previo al inicial o en estado ‘parado’, el texto será ‘Detener
GPS’.
122
7.3 Casos de uso de rutas
Diagrama 65 - Componentes de rutas en la arquitectura
7.3.1 Introducción
El cálculo de rutas desde la aplicación se divide en dos etapas:
1. En una primera etapa, el usuario selecciona navegando por el
mapa los puntos por los que pasará la ruta, lógicamente para que
el cálculo tenga sentido, los puntos deberán estar cercanos a una
carretera. Esta etapa engloba los casos de uso:
•
•
•
•
•
Establecer punto de inicio de ruta
Establecer punto de fin de ruta
Establecer punto de paso de ruta
Eliminar punto de paso de ruta
Selección de puntos para ruta
2. En la segunda etapa el usuario ya ha seleccionado los puntos que
desea y solicita el cálculo de rutas que se realiza en el subsistema
servidor de rutas, se obtiene la respuesta y se dibuja en pantalla la
123
ruta. El usuario puede anular la ruta u obtener las indicaciones de
por dónde tiene que ir. Los casos de uso de esta etapa son:
•
•
•
•
Calcular ruta
Anular Ruta
Obtener indicaciones ruta
Selección tipo ruta
En esta sección definiremos las entidades necesarias para la selección
de puntos de ruta en local, los diferentes estados por los que puede
pasar una ruta, así como la interacción con el subsistema de rutas.
7.3.2 Geometrías
Antes de comenzar con el diseño de los casos de uso de rutas, es
conveniente definir algunas abstracciones que van a ser útiles. Estas
abstracciones son las distintas geometrías utilizadas, qué representan y
cómo se representan y un par de conceptos como son ‘Feature’ y
‘FeatureCollection’.
Cada geometría será una entidad que podrá ser representada en
pantalla y conocerá su visibilidad y la forma en que debe ser dibujada.
También deberemos de poder liberar la memoria asociada a la
geometría y conocer cuáles son sus coordenadas. Para asegurarnos de
esto, una geometría deberá implementar la siguiente interfaz:
Diagrama 66 - Interfaz UML IGeometry
7.3.2.1 Point
Un punto representa unas coordenadas x e y en el sistema de referencia
del mapa.
En nuestro caso, además debemos de poder realizar operaciones con
puntos tales como, comparar, sumar, restar y calcular la distancia
euclídea entre dos puntos. Por comodidad, utilizaremos la clase ‘Point’
también para representar coordenadas en píxeles de la pantalla.
124
Diagrama 67 - Clase UML Point
7.3.2.2 Multipoint
Un multipunto es un conjunto de puntos que constituyen una única
geometría.
125
Diagrama 68 - Clase UML MultiPoint
7.3.2.3 LineString
Una línea es una colección de coordenadas x e y que unidas forman un
tramo.
Diagrama 69 - Clase UML LineString
7.3.2.4 MultiLineString
Una multilínea es un conjunto de líneas que forman una única
geometría.
Diagrama 70 - Clase UML MultiLineString
7.3.2.5 Feature
126
Una Feature es una abstracción que representa una entidad del
mundo real. Normalmente suele contener una geometría con las
coordenadas de la entidad y unos atributos que pueden corresponder
a datos alfa-numéricos de la entidad.
7.3.2.6 FeatureCollection
Una FeatureCollection no es más que una clase con una colección
de Features. Debe proporcionar métodos para añadir, eliminar y
acceder a las Features que contiene.
El siguiente diagrama muestra las relaciones entre las diferentes clases
de nuestro modelo de geometrías:
Diagrama 71 - Diagrama de clases del modelo de geometrías
7.3.3 Definiendo con detalle una ruta
127
Una ruta pasa por varios estados a lo largo de su vida. Se entiende por
Ruta el conjunto de puntos de partida, destino, paso y el estado de la
ruta. Aunque esta definición es variable y depende del estado de la
ruta, así, ésta contendrá puntos cuando todavía no esté calculada,
pero en el momento que haya sido calculada por el servidor y
representada en pantalla, contendrá el conjunto de tramos
(MultiLineString) por los que pasa.
7.3.3.1 Tipos de puntos de una ruta
Una ruta podrá tener tres tipos de puntos:
1. Punto de origen: Es el punto desde donde partirá aunque no tiene
porqué ser el primero en ser seleccionado. Se representa en
pantalla con una bandera de color verde .
2. Punto de destino: Es el punto donde finaliza la ruta. Se representa
en pantalla con una bandera de color rojo .
3. Punto de paso: Son puntos intermedios por donde pasará la ruta.
Si sólo existe un único punto de paso, se considerará como el
punto de destino. En caso de haber seleccionado más de uno, el
último punto seleccionado se considerará el punto de destino. Se
representa en pantalla con una bandera de color azul .
7.3.3.2 Diagrama de transición de estados
Para entender mejor los posibles estados por los que puede pasar una
ruta se diseña un diagrama de transición de estados UML. En función del
tipo de puntos que contenga una ruta podrá encontrarse en un estado
tal y como se representa en el siguiente diagrama:
128
Diagrama 72 - Diagrama de transición de estados de una ruta
Por ruta calculada se entiende que la ruta contiene un punto de origen
y al menos un punto de paso o el punto de destino y que el resultado
obtenido del servidor ha sido pintado en pantalla. En este estado el
usuario no puede modificar los puntos que contiene.
De acuerdo a la máquina de estados se resumen las posibles acciones
que podrá realizar el usuario en la siguiente tabla:
En la siguiente tabla se muestra el conjunto de posibles acciones que se
pueden realizar sobre una ruta dependiendo de su estado:
129
Tabla 7 - Tabla de posibilidades de puntos de ruta
7.3.4 Interacción con el servicio de rutas
El cálculo de rutas es una operación que debido a las restricciones de
procesamiento y memoria no es posible realizar en el propio dispositivo.
Esto, unido a la necesidad de interoperabilidad del cálculo de rutas con
el visor web (ver diagrama de componentes) lleva a la necesidad de la
definición de un servicio web para realizar el cálculo.
El subsistema de rutas será el encargado de definir el servicio web y
poner a disposición de nuestra aplicación y del visor web los métodos
necesarios para realizar el cálculo de rutas.
Así pues, es necesario conocer cuáles son y qué atributos tienen las
geometrías que definen una ruta según el servicio de cálculo de rutas.
Qué información y en qué formato necesita el servicio para realizar su
función y cómo se transmitirá dicha información.
7.3.4.1 Geometrías y atributos
El subsistema de rutas acepta como entrada para el cálculo de una
ruta, una colección ordenada de puntos, que representarán las
coordenadas por las que transcurre la ruta.
Se definen dos operaciones:
130
•
Cuando el subsistema de rutas reciba dos puntos, entenderá que
el primero es el origen y el segundo el destino y calculará una ruta
con origen y destino en esos puntos.
•
Cuando reciba una colección de puntos, realizará el cálculo
utilizando el algoritmo del viajante de comercio, es decir,
devolverá la ruta más corta pasando por todos los puntos.
El subsistema de rutas define la geometría de una ruta como un
MultiLineString. Como hemos visto un MultiLineString está
compuesto por uno o más LineString. En este caso, un LineString
representará un tramo de una calle o carretera que pasa por distintas
coordenadas.
Cada Feature que contenga un LineString además contendrá los
siguientes atributos que nos servirán para poder obtener en local las
direcciones de una ruta:
•
•
•
•
ID: Un entero que identifica el Feature.
Text: Una cadena con un nombre que identifica el tramo de ruta,
generalmente, el nombre de la calle o de la carretera.
Cost: Un atributo de tipo double que representa el tiempo medio
en recorrer el tramo.
Length: Un atributo de tipo double que representa la longitud en
metros del tramo.
7.3.4.2 Servicios web SOAP
131
Diagrama 73 - Componente HTTP/Web service en la arquitectura
Un servicio web (en inglés Web service) es un conjunto de protocolos y
estándares que sirven para intercambiar datos entre aplicaciones.
Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes, y ejecutadas sobre cualquier plataforma,
pueden utilizar los servicios web para intercambiar datos en redes de
ordenadores como Internet. La interoperabilidad se consigue mediante
la adopción de estándares abiertos.
7.3.4.2.1 Ventajas de los servicios Web
•
•
•
•
Aportan interoperabilidad entre aplicaciones de software
independientemente de sus propiedades o de las plataformas
sobre las que se instalen.
Los servicios Web fomentan los estándares y protocolos basados
en texto, que hacen más fácil acceder a su contenido y entender
su funcionamiento.
Al apoyarse en HTTP, los servicios Web pueden aprovecharse de
los sistemas de seguridad firewall sin necesidad de cambiar las
reglas de filtrado.
Permiten que servicios y software de diferentes compañías
ubicadas en diferentes lugares geográficos puedan ser
combinados fácilmente para proveer servicios integrados.
132
•
Permiten la interoperabilidad entre plataformas de distintos
fabricantes por medio de protocolos estándar y abiertos. Las
especificaciones son gestionadas por una organización abierta, la
W3C, por tanto no hay secretismos por intereses particulares de
fabricantes concretos y se garantiza la plena interoperabilidad
entre aplicaciones.
7.3.4.2.2 Razones para crear servicios Web
La principal razón para usar servicios Web es que se basan en HTTP sobre
TCP (Transmission Control Protocol) en el puerto 80. Dado que las
organizaciones protegen sus redes mediante firewalls -que filtran y
bloquean gran parte del tráfico de Internet-, cierran casi todos los
puertos TCP salvo el 80, que es, precisamente, el que usan los
navegadores. Los servicios Web utilizan este puerto, por la simple razón
de que no resultan bloqueados.
Otra razón es que, antes de que existiera SOAP, no había buenas
interfaces para acceder a las funcionalidades de otros ordenadores en
red. Las que había eran ad hoc y poco conocidas, tales como EDI
(Electronic Data Interchange), RPC (Remote Procedure Call), u otras
APIs.
Una tercera razón por la que los servicios Web son muy prácticos es que
pueden aportar gran independencia entre la aplicación que usa el
servicio Web y el propio servicio. De esta forma, los cambios a lo largo
del tiempo en uno no deben afectar al otro.
7.3.4.3 Intercambio de geometrías
Una vez conocidos qué geometrías es necesario intercambiar con el
subsistema de rutas y qué medio se utilizará para dicho intercambio, es
necesario conocer con detalle qué formato será necesario para
codificar la información.
7.3.4.3.1 Elección de un formato de intercambio de geometrías:
GeoJSON
133
Diagrama 74 - Componentes de rutas en la arquitectura
JSON, acrónimo de "JavaScript Object Notation", es un formato ligero
para el intercambio de datos. JSON es un subconjunto de la notación
literal de objetos de JavaScript que no requiere el uso de XML. Es legible
e independiente de la plataforma, además de tener a su disposición
una amplia gama de implementaciones
La simplicidad de JSON ha dado lugar a la generalización de su uso,
especialmente como alternativa a XML en AJAX. Una de las supuestas
ventajas de JSON sobre XML como formato de intercambio de datos en
este contexto es que es mucho más sencillo escribir un analizador
semántico de JSON.
JSON se emplea habitualmente en entornos donde el tamaño del flujo
de datos entre cliente y servidor es de vital importancia (de aquí su uso
por Yahoo, Google, etc. que atienden a millones de usuarios) cuando la
fuente de datos es explícitamente de fiar y donde no es importante el
no disponer de procesamiento XSLT para manipular los datos en el
cliente.
Si bien es frecuente ver JSON posicionado contra XML, también es
frecuente el uso de JSON y XML en la misma aplicación. Por ejemplo,
una aplicación de cliente que integra datos de Google Maps con datos
meteorológicos en SOAP hacen necesario soportar ambos formatos.
134
El beneficio de JSON, entonces, no es que sea más pequeño a la hora
de transmitir, sino que representa mejor la estructura de los datos y
requiere menos codificación y procesamiento.
GeoJSON es un formato de intercambio de datos de estructuras de
datos geográficas. GeoJSON se puede utilizar para representar
geometrías, Features, colecciones de geometrías o FeatureCollections.
Los tipos de geometrías soportadas por GeoJSON son: Point, LineString,
Polygon, MultiPoint, MultiLineString, MUltiPolygon y Box.
GeoJSON utiliza la notación y estructuras de datos de JSON descritas
anteriormente.
7.3.5 Diseño de los casos de uso de rutas
7.3.5.1 Selección de puntos de ruta
Para la selección de puntos necesitaremos una clase ‘Route’ que
servirá de contenedor de las geometrías. Cuando la ruta no esté
calculada, contendrá ‘RoutePoints’ y cuando la ruta esté calculada
los ‘RoutePoints’ correspondientes a los puntos seleccionados
desaparecerán y contendrá ‘MultiLineStrings’ correspondientes a
los tramos de carretera de la ruta. Además, se guardará el estado de la
ruta explícitamente mediante un atributo de tipo entero y contendrá
métodos que convertirá la colección de geometrías en el formato de
intercambio con el servidor de rutas y que permitirán obtener las
indicaciones de la ruta.
Un diagrama simplificado de clases donde se pueden ver las entidades
necesarias y las relaciones entre ellas es el siguiente:
135
Diagrama 75 - Diagrama de clases de rutas
Un mapa tendrá únicamente una ruta en memoria, así cada vez que se
solicite el cálculo de una nueva ruta, se destruirá si existe la ruta previa
en memoria.
Conociendo el modelo de geometrías y la máquina de estados, es trivial
la implementación de los casos de uso:
•
•
•
•
Establecer punto de inicio de ruta
Establecer punto de fin de ruta
Establecer punto de paso de ruta
Eliminar punto de paso de ruta
Bastará con actualizar el estado de la ruta en cada caso, añadir o
eliminar el punto seleccionado de nuestra colección de geometrías y
tras cada acción volver a pintar la pantalla del mapa para refrescar los
cambios.
136
7.3.5.1.1 Diseño de la interfaz de usuario de Selección de puntos
de ruta
La pantalla contará con un formulario con BorderLayout. Colocaremos
en la zona NORTE, un botón para seleccionar la ubicación de origen y
en la zona SUR un botón para seleccionar la ubicación de destino. En
caso, de ya estar seleccionados los botones estarán deshabilitados y
mostrarán el icono del punto al que representan y sus coordenadas.
En la zona CENTRO tendremos una lista con los puntos de paso que se
vayan añadiendo. La lista está formada por RoutePoints. Un
RoutePoint no es más que un Point con un icono representativo del
punto en cuestión.
El menú de la pantalla deberá ser coherente con el resto de menús de
la aplicación. Así, acciones compartidas por otras pantallas deberán
tener el mismo nombre y el mismo código de acceso para que el
usuario pueda asociar siempre cada acción al mismo código entre
pantallas.
Se ha desarrollado un componente personalizado ‘CommandEnable’ que
permite habilitar o deshabilitar un comando de menú. Es importante
tener en cuenta la máquina de estados de una ruta para deshabilitar
las acciones que no estén disponibles según el estado de la ruta.
Llegados a este punto es conveniente explicar algunos detalles de la
implementación de la interfaz de usuario. En el capítulo 6 se explicaba
el paradigma seguido por LWUIT para la implementación de listas, bien,
en nuestro caso hemos aprovechado esa funcionalidad y la hemos
extendido para conseguir un determinado comportamiento.
En el siguiente diagrama podemos ver como se han extendido las clases
que implementan MVC en LWUIT:
137
Diagrama 76 - Diagrama de clases de la estructura MVC para puntos de ruta
Por un parte tenemos la clase TickerList que extiende a List. Esta
clase será el controlador y su objetivo es conseguir que el elemento
seleccionado pueda ser animado. Normalmente las pantallas de los
teléfonos móviles son pequeñas y puede que necesitemos mostrar
información que es más grande que la pantalla, LWUIT resuelve este
problema permitiendo desplazar los contenedores, pero, para listas
puede resultar incómodo. TickerList contendrá un método que
indicará cuándo el elemento seleccionado debe ser animado y en tal
caso se desplazará automáticamente como una marquesina.
Por otra parte, tenemos la clase RoutePointRenderer que corresponde
a la vista. Implementa dos interfaces: ListCellRenderer y
TickerRenderer. La primera interfaz nos permite saber cómo pintar
138
cada elemento, en nuestro caso, necesitamos pintar RoutePoints y lo
haremos pintando su icono representativo y sus coordenadas en un
contenedor con dos etiquetas (com.sun.lwuit.Label). Al implementar
TickerRenderer, la clase sabrá cómo pintar el elemento seleccionado
cuándo éste sea más grande que el tamaño de la pantalla y a qué
velocidad debe animarlo.
Finalmente, para el modelo tenemos la clase PointListModel, que no
es más que un wrapper de FeatureCollection, nuestra clase con las
geometrías, de esta manera, podemos acceder a la información de
cada RoutePoint.
Diagrama 77 - Layout de formulario de selección de puntos de ruta
7.3.5.2 Cálculo de rutas
El cálculo de rutas dada su complejidad, se realiza en un servicio
externo al dispositivo móvil, el subsistema de rutas. Para ello es necesario
establecer un formato de petición de cálculo y un formato de respuesta
de la ruta, que cliente y servidor deberán conocer. Como ya se ha visto
la comunicación se realizará mediante servicios web SOAP. A
continuación se describen los formatos de solicitud y respuesta utilizando
el formato GeoJSON y la actividad a realizar para calcular rutas desde
el dispositivo móvil.
7.3.5.2.1 Formato GeoJSON de una solicitud
139
Diagrama 78 - Ejemplo de cadena GeoJSON de solicitud de ruta
En el cuadro podemos ver un ejemplo de una cadena GeoJSON que
representa una colección de dos puntos. Esta cadena junto con el tipo
de ruta elegido por el usuario serán los parámetros que se enviarán al
servicio web.
7.3.5.2.2 Formato GeoJSON de una respuesta
Diagrama 79 - Ejemplo de cadena GeoJSON de respuesta del servidor de rutas
La respuesta del servicio web será una FeatureCollection. Cada
Feature contendrá un MultiLineString representando los tramos de
carretera o calle, además, se obtendrán los atributos necesarios para
obtener las indicaciones de la ruta.
Para realizar la conversión de nuestro modelo de geometrías a formato
GeoJSON y viceversa se diseña la clase GoeJSONParser que utiliza la
librería de código libre org.json.me.*
140
Un esquema simplificado de la transformación es el siguiente:
GeoJSONParser
GeoJSONString
geom.FeatureCollection
org.json.me.*
7.3.5.2.3 Actividad para el cálculo de rutas
El flujo de trabajo que debe seguir la aplicación para el cálculo de rutas
es el siguiente:
1. El usuario puede añadir o eliminar puntos según el estado de la
ruta (ver máquina de estados de una ruta).
2. Cada vez que se produzca esta situación, se actualiza el estado
de la ruta. El mapa tendrá una capa que contendrá las
geometrías de la ruta, se añade o elimina el punto de un
‘MultiPoint’ que tendrá en memoria.
3. Se vuelve a pintar la pantalla para actualizar el conjunto de
puntos que se muestran.
4. Se deberá seguir estrictamente la máquina de estados de una
ruta. En el momento en que una ruta tenga un punto de origen y
uno de destino o el usuario explícitamente seleccione calcular
ruta (la ruta debe estar en un estado desde el que se pueda
realizar el cálculo), el usuario seleccionará el tipo de la ruta.
5. Una vez seleccionado el tipo de ruta, utilizando la clase
GeoJSONParser, se realizará la transformación del ‘MultiPoint’
en un GeoJSONString con el formato descrito anteriormente.
6. A continuación se realizará la llamada al servicio web utilizando la
clase RouteTask que se ejecuta en segundo plano, para ello se
utilizará un hilo con un tiempo máximo de espera de 30 segundos.
Será la propia tarea la que comprobará qué método es necesario
llamar:
a. CalculateRoute: Si el ‘MultiPoint’ tiene sólo dos puntos.
b. CalculateRouteTSP: Si el ‘MultiPoint’ tiene más de dos
puntos.
7. Una vez se obtenga respuesta del servicio web, se realizará la
transformación inversa del GeoJSONString que devuelva, a
nuestro modelo de geometrías.
8. Se añadirá la FeatureCollection obtenida a la capa con las
geometrías de la ruta y se volverá a pintar la pantalla, para ver el
resultado de la ruta.
141
Excepciones
En 7. Si el servicio devuelve una excepción o se supera el tiempo
máximo de espera se mostrará el error en pantalla en un Dialog.
Diagrama 80 - Intercambio de geometrías entre cliente-servidor
142
Diagrama 81 - Diagrama de actividad de cálculo de rutas
7.3.5.3 Anular ruta
143
Anular ruta es un caso de uso sencillo en el que basta con llamar al
método destroy() de los FeatureCollection que representan los
puntos de ruta seleccionados por el usuario y el de la ruta propiamente
dicha en caso de existir.
Este método llamará iterativamente al método destroy() de su vector
de Features que a su vez destruirá su geometría y propiedades
asociadas.
Finalmente se volverá a pintar la pantalla.
144
7.3.5.4 Obtener indicaciones de ruta
Como hemos visto, al obtener del servicio web la respuesta al cálculo
de una ruta, también obtenemos los atributos de cada Feature que son
almacenados en memoria en la clase RouteProperties que no es más
que un contenedor de estas propiedades.
Diagrama 82 - Clase UML RouteProperties
De esta manera, es sencillo, recorrer cada par de Features de la ruta,
para obtener la secuencia de calles y distancia recorrida por la ruta.
También es posible obtener la dirección de giro entre cada dos tramos
(izquierda, derecha, recto) calculando el ángulo que forman las dos
últimas coordenadas de la última geometría de un Feature con la
primera coordenada de la primera geometría del siguiente Feature,
para ello, se utilizará la clase TurnUtil:
145
Diagrama 83 - Clase UML TurnUtil
La información textual de la indicación de cada tramo y el icono
representativo del giro se almacenará en dos atributos de la propia
clase Feature, ‘directions’ y ‘directionIcon’ respectivamente. Así,
es posible reutilizar nuestro modelo MVC para representar en pantalla
una FeatureCollection, cambiando únicamente el renderer para que
sepa cómo pintar los dos nuevos atributos.
146
Diagrama 84 - Diagrama de clases de la estructura MVC para representar las direcciones de una
ruta
En este caso la vista consistirá en un contenedor, con el icono
representativo del giro a la izquierda y un TextArea con la descripción
del tramo.
147
Diagrama
85
-
Layout
de
formulario
de
obtener
direcciones
de
ruta
148
7.4 Mostrar, buscar y consultar puntos de interés
Diagrama 86 - Componentes de puntos de interés en la arquitectura
En esta sección se especifica el diseño de los casos de uso buscar y
consultar puntos de interés.
En primer lugar se definirá qué es un punto de interés y qué sentido tiene
dentro de la aplicación.
En segundo lugar, cuál es el formato concreto de puntos de interés y
cómo se adaptará a las especificaciones de los dispositivos móviles.
Para ello, se estudiará una estructura de datos apropiada para el
almacenamiento de puntos.
Finalmente, se estudiarán diversas alternativas para la persistencia de la
información asociada a puntos de interés en el propio dispositivo que
permitan el desarrollo de los casos de uso.
7.4.1 Definición de puntos de interés
149
Un punto de interés o POI (Point of interest) es una localización puntual
que alguien puede encontrar útil o interesante. Normalmente viene
definido por sus coordenadas (latitud, longitud y altitud) y una
descripción textual. En nuestro caso, un punto de interés representará un
recurso turístico de interés para el visitante y estará formado por una
descripción textual de lo que representa, unas coordenadas x-y en el
sistema de referencia EPSG:23030 y una categoría.
El análisis, especificación y producción de puntos de interés tuvo lugar
en la empresa GeoDatum Consultores S.L. que colaboró en el desarrollo
del proyecto a través del subsistema de cartografía. Así, se definieron un
conjunto de categorías que representan recursos culturales y que
deberían poder ser consultadas tanto por el subsistema móvil como por
el visor web. En total, se contaba con una base de datos de 20.000
puntos de interés que fueron proporcionados en un fichero de texto
plano con un formato conocido por las dos partes.
La gestión de tal cantidad de información supone un reto importante en
dispositivos con una capacidad de almacenamiento y de memoria tan
limitada. En primer lugar, es necesario especificar cómo accederá la
aplicación móvil a la información referente a puntos de interés.
7.4.2 Formato inicial de ficheros de puntos de interés
Se acordó que los puntos de interés irían codificados en ficheros de
texto de la siguiente manera:
•
•
•
Cada línea del fichero representará un punto de interés.
Cada punto de interés constará de 5 atributos separados por
comas.
Los atributos serán los siguientes y en el siguiente orden:
1. ID: Un valor entero con el identificador del punto de interés.
2. X: Coordenada x del punto de interés codificada en
EPSG:23030, con los decimales separados por un punto.
3. Y: Coordenada y del punto de interés codificada en
EPSG:23030, con los decimales separados por un punto.
4. Descripción: Descripción textual del punto de interés.
5. Categoría: La categoría vendrá representada por un
código numérico de acuerdo a la siguiente tabla.
150
Tabla 8 - Categorías de puntos de interés
Cada categoría vendrá representada por un icono, de manera que el
usuario podría identificar visualmente cada punto de interés.
151
Un ejemplo de punto de interés codificado es el siguiente:
0, 188100.261476000010000, 4228290.274530000100000, LOS ARCOS, 2
7.4.3 Localización de puntos de interés
La especificación del caso de uso Consultar información, cambió a lo
largo del proyecto. En un principio, se limitaba a realizar una petición al
servicio WMS a través de GetFeatureInfo, procesar la respuesta y
mostrarla en pantalla. Posteriormente, para evitar realizar peticiones a
través de internet que suelen ser lentas en los dispositivos móviles, se
decidió que la aplicación contaría con toda la información en memoria
y la gestión se haría en local. Además de esto, el usuario debería de
poder visualizar en pantalla los puntos de interés que correspondieran a
la zona del mapa que estuviera en pantalla.
Desde el punto de vista del tiempo de respuesta, resulta poco
recomendable realizar la búsqueda sobre la información tal cual es
proporcionada, ya que ello implicaría en el peor de los casos tener que
recorrer el fichero entero con los 20.000 registros hasta encontrar lo que
necesitamos mostrar. Esto en un dispositivo móvil puede tener un coste
de varios segundos (incluso minutos) o puede resultar imposible en
dispositivos que cuenten con poca memoria disponible para
aplicaciones Java, ya que el fichero ocupa algo más de 1000 Kbytes y
no se podría cargar completamente en memoria. Además, la
experiencia de usuario se ve perjudicada, ya que con cada
desplazamiento sobre el mapa habría que realizar sucesivas búsquedas
que dificultarían la interacción con la aplicación.
Así, es necesario contar con un diseño eficiente, además de imponer
algunas restricciones, que permita consumir el menor número de
recursos y con unos tiempos de respuesta aceptables, del orden de 5-10
segundos (o menos) para búsquedas en todo el espacio de búsqueda y
que la percepción del usuario sea de fluidez durante la navegación. Es
importante pues conocer en primer lugar qué posibilidades ofrece J2ME
para el almacenamiento de datos, en segundo lugar elegir una
estructura de datos adecuada para almacenarlos en memoria y por
último dada la naturaleza del formato de puntos de interés
proporcionados (un único fichero con mucha información) realizar la
transformación necesaria para adecuar ese formato a uno que sea más
cómodo de manipular.
7.4.3.1 Almacenamiento de puntos de interés
7.4.3.1.1 Índices espaciales
152
Un índice espacial es una estructura de datos jerárquica que se basa en
el principio de descomposición recursiva del espacio. Se utiliza para
optimizar consultas espaciales tales como: el vecino más cercano,
conjunto de elementos cercanos a una posición o dentro de un área,
etc. Permite ir al grano y no tener que visitar cada vez los n elementos
existentes.
Los índices espaciales se pueden clasificar atendiendo a tres de sus
propiedades:
1. El tipo del dato en que actúan.
2. El principio que guía el proceso de descomposición.
3. La resolución.
7.4.3.1.2 Diseño de un índice espacial específico a partir de un
Quadtree
La familia Quadtree se usa para representar puntos, áreas, curvas,
superficies y volúmenes en bloques regulares (no tiene porqué usar
árboles). La descomposición puede hacerse en partes iguales en cada
nivelado (regular), o puede depender de los datos de entrada. La
resolución de la descomposición, en otros términos, el número de
tiempos en que el proceso de descomposición es aplicado, puede
tratarse de antemano, o puede depender de las propiedades de los
datos de entrada.
Los dos tipos más común de Quadtree para representar puntos son el
‘Point-Quadtree’, el ‘PR-Quadtree’ y el ‘Bucket PR-Quadtree’.
En un QuadTree de puntos, el centro de una subdivisión está siempre en
un punto. Al insertar un nuevo elemento, el espacio queda divido en
cuatro cuadrantes, y al repetir el proceso, el espacio igual se divide en
cuatro cuadrantes, lo que limitado por la división superior y así
sucesivamente. Al final, en cada hoja habrá un único punto
representado por sus coordenadas. El desarrollo de éstos fue motivado
por la necesidad de guardar datos que se insertan con valores idénticos
o similares
153
Diagrama 87 - QuadTree de puntos
El PR-Quadtree es una adaptación del Quadtree para la representación
de puntos en una región. Difiere del Point-Quadtree en las divisiones no
dependen de los datos de entrada, sino que son fijas.
Diagrama 88 - PR-QuadTree
Un Bucket PR-Quadtree es un PR-Quadtree en el que se puede
especificar la capacidad de cada cuadrante. Un ejemplo con
capacidad de tres puntos por cuadrante:
154
Diagrama 89 - Bucket PR-QuadTree
En general, la representación escogida depende de la tarea específica
que uno quiera ejecutar con un grupo de puntos. En nuestro caso
deberemos realizar dos operaciones:
1. Encontrar los puntos incluidos en una región.
2. Encontrar el punto más cercano a uno dado.
Las propiedades de nuestro Quadtree serán las siguientes:
1. El tipo del dato en que actúan: geom.Point
2. El principio que guía el proceso de descomposición: Cada región
se subdividirá en cuatro regiones iguales de manera similar a un
Bucket PR-Quadtree.
3. La resolución: Cada cuadrante incluirá un máximo de 100 puntos
y un mínimo de uno.
Como ya hemos comentado resulta inviable procesar todo el fichero de
puntos de interés en el dispositivo móvil y aunque tengamos una
estructura de datos que permita optimizar la búsqueda de igual manera
resulta inviable cargar en memoria todos los datos.
La solución que se propone a este problema comprende varios pasos:
1. En un primer paso, realizar una operación de pre-procesado del
fichero de puntos de interés, insertando cada punto en el
Quadtree. Esta operación se realizará por medio de una
aplicación Java externa desarrollada especialmente para esa
tarea.
155
2. A continuación, guardar la información de cada hoja del
Quadtree en ficheros independientes, de esta manera, tendremos
multitud de ficheros con un máximo de cien puntos de interés
cada uno que representarán regiones concretas del espacio.
3. Por último, persistir una versión simplificada del Quadtree que será
la que carguemos en memoria del dispositivo móvil y sobre el que
haremos las búsquedas. Se guardará el árbol, pero en vez de
guardar los puntos que hay en las hojas, simplemente
guardaremos el nombre del fichero que corresponde a la
información que contiene la hoja, de esta manera, al realizar una
búsqueda obtendremos un conjunto de ficheros donde se
encontrarán los puntos que necesitamos.
7.4.3.1.3 Pre-procesado de puntos de interés
Mediante una aplicación J2SE realizada para el caso, se tomará el
fichero con los 20.000 puntos de interés, se cargarán en memoria en el
Quadtree diseñado y posteriormente se persistirá la información en
ficheros de menos de 100 puntos de interés por fichero. Además se
guardará un fichero con la estructura del Quadtree simplificada para
interactuar con la aplicación móvil.
156
Diagrama 90 - Diagrama de clases de Quadtree complejo para pre-procesado de puntos de
interés
Inicializaremos el Quadtree con la máxima extensión del espacio de
puntos de interés y el máximo número de puntos de interés por nodo
(por fichero) que hemos dicho que serán 100.
Un QuadtreeNode sabrá cuando subdividirse mediante su método
‘split’ y sabremos si es una hoja con ‘hasChildren’.
Por último un QuadtreeNode tendrá un QuadtreeBox que representará
la región que contiene dentro.
Una vez tengamos la estructura de datos con todos los puntos de interés
cargados, habrá que persistir cada hoja en un fichero.
El siguiente árbol representa una estructura simplificada de cómo
quedaría un hipotético Quadtree.
Diagrama 91 - Representación de un Quadtree con un árbol y sobre un plano
El criterio para particionar un nodo en otros cuatro es si el número de
puntos en su interior es mayor a 100. Así tendremos que en cada nodo
hoja hay menos de 100 puntos. Además cada nodo representa un
fichero que contiene los puntos de interés.
Al persistir el Quadtree tendríamos, 19 ficheros correspondientes a cada
hoja, más un fichero con la estructura del árbol, que nos servirá para
cargarla en la aplicación móvil y realizar las búsquedas.
En nuestro caso, tenemos 619 ficheros que corresponden a un Quadtree
de 619 hojas.
La versión reducida del Quadtree se persistiría de la siguiente manera
(suponiendo el espacio de búsqueda igual a -90,-90,90,90 en
EPSG:4326):
-90,-90,90,90|1|-1|-1|-1|2|3|4|5|6|-1|11|12|13|14|1|19|7|8|9|10|15|16|17|18
157
En primer lugar, se codifican las coordenadas del espacio de búsqueda,
a continuación, partiendo del nodo raíz, se persiste cada nivel del árbol
de la siguiente manera:
•
•
Si el nodo es una hoja se persiste el nombre del fichero que
contiene los puntos de interés, numerados desde 1.
Si el nodo es una rama se persiste con un -1.
7.4.3.1.4 Acceso aleatorio a ficheros
A la hora de persistir la información de las hojas del Quadtree en
ficheros, se presentan varios problemas.
El tamaño de los ficheros debe ser tan pequeño como sea posible para
que la operación de leerlos desde el dispositivo móvil sea lo suficiente
rápida, de ahí, que limitáramos la capacidad de cada hoja a cien
puntos de interés. Sabemos que coordenadas y categoría por ser tipos
numéricos se pueden codificar con un tamaño constante, pero la
descripción por ser una cadena puede tener un tamaño variable.
Además, cuando el usuario navegue por el mapa y se tengan que
mostrar puntos de interés sólo necesitaremos las coordenadas para
situarlos y la categoría para representarlos, por tanto, no tiene sentido
persistir la descripción en el mismo fichero ya que supondría una
penalización de tiempo.
Si persistimos las descripciones en otro fichero a parte, necesitaremos
guardar por cada punto de interés, la posición del primer carácter de su
descripción en el fichero, para poder acceder a ésta cuando sea
necesario. El problema viene porque en J2ME no existe acceso aleatorio
a ficheros, por tanto, si la descripción de un punto de interés comienza
en el byte 80.000 del fichero de descripciones, implicaría llegar a esa
posición leyendo el fichero, operación que resulta muy ineficiente. Para
resolver esta situación haremos lo siguiente:
•
•
•
Guardar con cada punto de interés la posición relativa de su
descripción que servirá como índice para acceder a ésta.
En vez de tener un único fichero de descripciones,
descomponerlo en ficheros de tamaño fijo, por ejemplo, 1024
bytes.
Con las posiciones relativas y ficheros de tamaño fijo, podemos
simular acceso pseudo-aleatorio a ficheros mediante las
siguientes operaciones:
Partiendo de un punto de interés cuya descripción comience en
el byte 80.000, calculamos cúal es el fichero de descripciones con:
158
offset / tamFichero
80.000/1024 = 78
Sabiendo que la descripción está en el fichero número 78, podemos
calcular la posición relativa dentro del fichero con:
offset % tamFichero
80.000 % 1024 = 128
Así pues, sólo habrá que recorrer 128 bytes del fichero número 78 para
obtener la descripción del punto de interés.
7.4.3.1.5 Formato de los ficheros generados
Tanto los ficheros de los puntos de interés como los de las descripciones
se nombrarán con un valor numérico comenzando desde el uno. Se
colocarán en carpetas diferentes conocidas por la aplicación, ‘descr’
para los ficheros de descripción y ‘poi’ para los ficheros con los puntos
de interés y el índice espacial.
En los ficheros de puntos de interés escribiremos datos de tamaño fijo y
por
tanto
se
escribirán
en
binario,
utilizando
la
clase
java.io.DataOutputStream.
El
formato
de
cada
registro
correspondiente a un punto de interés será:
CoordenadaX
double (8 bytes)
CoordenadaY
double (8 bytes)
Categoría
short (2 bytes)
OffSetDescripción
short (2 bytes)
Se necesitan 20 bytes para codificar un punto de interés.
Las descripciones son cadenas de tamaño variable, por tanto,
transformaremos la cadena en bytes y escribiremos con la clase
java.io.OutputStream. Se utilizará el carácter ‘|’ para separar
cadenas entre sí. La lectura se hará carácter a carácter hasta encontrar
el carácter de separación de cadena. El formato cada descripción es:
Descripción + ‘|’
Tamaño variable teniendo en cuenta que cada carácter son 2 bytes
Hay que tener en cuenta que, debido a que el tamaño de los ficheros
de descripciones es fijo, es posible que una descripción empiece en el
final de un fichero y finalice en el principio del siguiente. En cualquier
caso, habrá que leer tantos bytes sean necesarios hasta encontrar el
carácter ‘|’ aunque ello implique abrir varios ficheros.
7.4.4 Diseño de los casos de uso de puntos de interés
159
La abstracción utilizada en la aplicación para representar los puntos de
interés es la siguiente:
Diagrama 92 - Diagrama de clases jerarquía Point – POI
Un punto de interés extiende a la geometría ‘Point’ y tiene cuatro
propiedades que son: categoría, descripción, Offset del fichero de
descripciones (que se ha explicado anteriormente) e inRoute que indica
si el punto de interés forma parte de una ruta o no.
Además, la clase POI redefine el método draw ya que un POI tendrá
una representación diferente (icono) dependiendo de su categoría.
160
La gestión de puntos de interés se realizará desde la capa con
información vectorial ‘LayerVect’, así pues, es necesario añadir
métodos para acceder a la colección de puntos de interés (que será un
FeatureCollection, ya que un punto de interés se representa como
una geometría) y métodos para resolver los casos de uso:
Diagrama 93 - Clase UML LayerVect
•
•
•
Con ‘addPOIS’: Añadiremos una colección de puntos de interés
para ser pintada sobre la capa.
requestPOIS: Se utilizará para buscar y mostrar los POIS
correspondientes a un determinado Extent.
searchPOIS: Realizará la búsqueda por categoría y descripción.
Cada tarea que implica puntos de interés será ejecutada en
background sobre el ThreadPool:
161
Diagrama 94 - Diagrama de clases de jerarquía de tareas
7.4.4.1 Visualización de puntos de interés
El siguiente diagrama de clases representa la versión simplificada para
la aplicación móvil del Quadtree donde sólo conocemos la estructura
de directorios y el espacio de búsqueda:
162
Diagrama 95 - Diagrama de clases de Quadtree simplificado para la aplicación móvil
La estructura de datos se carga recursivamente, leyendo el fichero con
el índice espacial en el que tenemos las coordenadas del espacio de
búsqueda y las hojas con los ficheros.
A este Quadtree le podemos preguntar mediante getPois qué archivos
cumplen una determinada búsqueda, pasando en el parámetro
‘bounds’, las coordenadas del espacio sobre el que queremos buscar.
La búsqueda se hará recursivamente desde el nodo raíz, sobre todo el
espacio de búsqueda, descendiendo por el Quadtree hasta llegar a las
163
hojas que se ajusten a las coordenadas en ‘bounds’. El resultado
obtenido será un Vector de enteros, que representará los ficheros a
deserializar, para obtener los puntos de interés que cumplen con la
búsqueda.
Así pues, para resolver el caso de uso, basta con calcular la región sobre
la que queremos realizar la búsqueda mediante el método getExtent()
de la clase ViewPort, que nos devuelve el extent del Mapa y pasar este
extent a getPois() del Quadtree que nos devolverá la colección de
ficheros que deberemos leer y deserializar su contenido, es decir, los
puntos de interés en su interior.
Hay 3 circunstancias en las que necesitaremos mostrar los puntos de
interés en el mapa mientras estamos navegando por el mapa, en los
dos últimos niveles de zoom:
1. Cuando hacemos ‘pan’ sobre el mapa.
2. Cuando acercamos el mapa.
3. Cuando alejamos el mapa.
Pan sobre el mapa
Diagrama 96 - Diagrama de secuencia de pan en la capa vectorial
Cada vez que se hace pan sobre el mapa, la capa vectorial
preguntará al Tree qué archivos necesita mostrar en la pantalla.
164
A continuación, se cancelarán las tareas del ThreadPool que tuvieran
que ver con POIs y se asignará una tarea con la lista de archivos a
deserializar.
El ThreadPool arrancará la tarea asíncronamente y ésta, buscará los
archivos en disco, y creará una FeatureCollection con la información
que se debe mostrar en pantalla.
Por último, se asignará esta colección a la capa vectorial, que cada vez
que haya que pintar el mapa será recorrida y pintada cada geometría
en su posición.
Acercar el mapa
Para el nivel máximo de zoom, bastará con restringir los puntos de
interés que tengamos en memoria, iterando sobre la colección de
puntos y desechando aquellos que no están dentro del nuevo Extent,
así evitamos volver acceder a disco.
Alejar el mapa
Los puntos de interés sólo se muestran en los dos niveles de zoom más
cercanos, así que en el penúltimo nivel de zoom haremos una
búsqueda sobre el quadtree con el extent del mapa.
7.4.4.2 Consulta de información
La consulta de información se hace sobre el punto de interés más
cercano al centro de la pantalla.
La búsqueda se hará sobre la colección de puntos de interés existente
en memoria y se utilizará la distancia euclídea para determinar qué
punto de interés es el más cercano con una tolerancia de 20 píxels, esto
es, si a menos de 20 píxels no hay ningún punto de interés no se mostrará
ninguna información, en caso contrario de haber más de un punto de
interés se obtendrá el más cercano.
La búsqueda de la descripción se hará mediante una tarea que se
ejecutará en un hilo independiente y recibirá como parámetros:
•
•
La colección de puntos de interés en memoria
El viewport para poder obtener las coordenadas del centro de la
pantalla.
165
Una vez encontrado el punto de interés en cuestión acceder a su
descripción con el sistema de pseudo-acceso aleatorio a ficheros que
hemos diseñado es simple. La clase POI tiene un atributo que nos
permite obtener fácilmente su descripción:
/**
* This attribute contains de position of the first byte into the poi's
description
* file in order to perform pseudo-random access to files
*/
public long posDesc;
La fórmula a utilizar es la siguiente:
posDesc / tamFichero = x
Sabiendo que la descripción está en el fichero x, podemos calcular la
posición relativa dentro del fichero con:
posDesc % tamFichero = y
Así pues, sólo habrá que recorrer y bytes del fichero número x para
obtener la descripción del punto de interés.
Diagrama 97 - Layout de formulario consulta de información
166
7.4.4.3 Búsqueda de puntos de interés
Para acelerar la búsqueda de puntos de interés se imponen dos
restricciones:
1. El Extent sobre el que se realizará la búsqueda tiene una
tolerancia de 5 km. Desde el punto central de la pantalla. Esto es
así, para que la búsqueda sobre el Quadtree sea lo más rápida
posible, además, para el usuario se entiende que le interesa
encontrar puntos de interés lo más cercanos posible a su
localización actual.
2. En segundo lugar, se limitan las búsquedas a los 50 primeros
puntos de interés encontrados.
El proceso de búsqueda de interés es análogo al que se produce al
visualizar los puntos de interés sobre el mapa, pero, en este caso sólo se
cargan en memoria los POIs cuya descripción o categoría coincidan
con los de la búsqueda. En este caso, la colección de puntos de interés
obtenida no se mostrará en pantalla, sino que se mostrará como una
lista en un formulario en el que aparecerán ordenados por cercanía
(distancia euclídea) al centro, para ello, se implementa el algoritmo
quicksort.
Una vez más, para representar en pantalla la información referente a
puntos de interés, reutilizaremos el esquema que hemos utilizado
durante toda la aplicación, siendo únicamente necesario implementar
un ‘Renderer’ que pintará de cada punto de interés su icono y su
descripción:
167
Diagrama 98 - Diagrama de clases de la estructura MVC para puntos de interés
Diagrama 99 - Layout de formulario de búsqueda de puntos de interés
168
8. Despliegue de la aplicación
8.0 Introducción
En este capítulo se enumeran y describen las herramientas y fases
necesarias para el despliegue de la aplicación sobre el dispositivo móvil.
8.1 Herramientas
El despliegue de la aplicación consiste en la obtención de los archivos
binarios ejecutables sobre el teléfono móvil a partir del código fuente.
Netbeans ofrece utilidades que permiten hacer el proceso de
despliegue de forma sencilla. Algunas de estas utilidades son:
•
•
•
•
•
Ant como herramienta que dirige el proceso de despliegue.
Consiste en definir mediante un fichero xml las fases que forman el
despliegue y qué acciones se deben tomar en cada fase.
Un preverificador.
Un emulador por defecto: Sun Wireless Toolkit CLDC
ProGuard como ofuscador de código.
La herramienta jarsigner para firmar aplicaciones.
Además todas estas herramientas pueden ser activadas o configuradas
desde la propia interfaz de Netbeans.
8.2 Compilación
Esta fase consiste en la obtención de los byte codes de java (archivos
.class) utilizando el compilador javac.
8. 3 Preverificación
Esta fase se realiza tras la compilación. La idea es añadir al fichero clase
generado por javac nuevo código que identifique la clase como válida
(pasa a ser una clase verificada).
8.4 Emulación
La emulación es un aspecto muy importante durante el despliegue de
aplicaciones J2ME, aunque debemos pensar en la emulación como un
proceso en el que podemos comprobar el comportamiento de la
aplicación en un entorno similar al del dispositivo, pero no cómo una
169
reproducción fidedigna de este entorno. Es decir, en general, desde el
PC podremos emular algunas características del dispositivo como:
tamaño de la pantalla, cantidad de memoria disponible, librerías con
las que cuenta, etc. Pero la aplicación a nivel de rendimiento, siempre
se comportará mejor en el dispositivo emulado que en el dispositivo real.
También resulta interesante combinar un entorno de emulación con el
de monitorización de los recursos de la aplicación aplicando un
‘profiler’, de esta manera es posible optimizar de manera genérica el
comportamiento en tiempo de ejecución del código J2ME que estamos
generando, detectando cuellos de botella u optimizando código que
consume la mayoría del tiempo de CPU.
Netbeans trae por defecto un emulador de dispositivos móviles de SUN,
Sun Wireless Toolkit CLDC.
8.4.1 Emulación de posicionamiento GPS
Un ejemplo práctico de la importancia de la emulación, es la
posibilidad de simular el posicionamiento GPS desde el propio
ordenador, de otra manera, sería muy complicado el poder depurar
este aspecto ya que habría que probar directamente sobre el
dispositivo y al aire libre.
170
Diagrama 100 - Simulación de localización GPS en Sprint SDK
8.5 Ofuscación
El proceso de ofuscación se ha utilizado tradicionalmente para que
fuera más costoso decompilar el código binario de una aplicación.
Consiste en sustituir todas las cadenas del código (variables, nombres de
clase, nombre de paquetes, etc.) por otras en general más sencillas.
Este proceso, además, tiene una utilidad especial en aplicaciones J2ME,
ya que al sustituir unas cadenas más largas por otras más cortas, se
reduce el tamaño del código binario generado y el tamaño del jar
disminuye, hecho que hemos visto que es de vital importancia al
desarrollar una aplicación para dispositivos móviles.
8.6 Firma de la aplicación
Firmar la aplicación implica obtener un certificado (firma digital) de una
entidad certificadora, de manera que el modelo de seguridad de J2ME
valide esa firma digital y asocie nuestra aplicación a un dominio seguro.
Así, podemos acceder a ciertas funcionalidades del API de J2ME que
de otra manera no sería posible.
171
En nuestro caso, es necesario acceder continuamente a disco (leer y
escribir ficheros), operación que en muchos teléfonos está restringida a
menos que la aplicación esté firmada.
Aún así, el modelo de seguridad de los teléfonos móviles en muchas
ocasiones está limitado por parte del fabricante o la operadora
telefónica que nos suministra el teléfono y son ellos en última instancia
los que deciden qué funcionalidades del API pertenecen a qué
dominio.
8.7 Empaquetado
El empaquetado consiste en la obtención de los ficheros JAD y JAR.
El fichero JAD (Java Application Descriptor), generalmente, se utiliza
para la instalación OTA de la aplicación o bien para la instalación de
aplicaciones firmadas.
Los atributos más importantes que contiene son, el nombre de los
MIDlets que contiene la aplicación, el tamaño del jar y la propia firma
digital.
El archivo JAR es un archivo comprimido que contiene el código
compilado, los archivos de recursos de la aplicación (imágenes,
archivos de idioma, etc.) y que puede contener a su vez otros archivos
JAR.
172
9. Manual de usuario
9.0 Introducción
En este capítulo se incluye el manual de usuario de la aplicación,
explicando cada una de las acciones que el usuario podrá realizar.
9.1 Arranque de la aplicación
Para arrancar la aplicación acceda al menú de aplicaciones del
teléfono móvil. Si la instalación ha tenido éxito, aparecerá un icono de
nombre 'Sigatex Móvil' desde donde podrá arrancar la aplicación.
La primera vez que se arranca Sigatex Móvil, se descargará
automáticamente la información correspondiente a puntos de interés
desde Internet, esta operación puede tardar varios minutos,
dependiendo del teléfono móvil.
Diagrama 101 - Pantalla inicial de la aplicación
Ha de tener en cuenta, que la utilización de la aplicación supone un
acceso a servicios de banda con el consiguiente consumo de ancho de
banda que le será facturado por su operador de telefonía móvil.
173
Diagrama 102 - Pantalla de advertencia de consumo de ancho de banda
Una vez ha arrancado la aplicación aparecerá la pantalla del mapa,
donde se pueden distinguir:
• En el centro el componente mapa, sobre el que podemos
navegar.
• En el lado izquierdo una barra indicando el nivel de zoom actual.
• En el centro de la pantalla un icono indicador que sirve para situar
el punto de la pantalla sobre el que queremos consultar
información.
• Por último, en la parte inferior el menú principal de la aplicación:
Diagrama 103 - Pantalla del mapa
9.2 Navegación de mapa
174
Es posible desplazar el mapa en cuatro direcciones: arriba, abajo,
izquierda, derecha. También es posible incrementar o decrementar el
nivel de zoom del mapa.
Para el desplazamiento utilice las flechas de su teléfono móvil.
Para aumentar el nivel de zoom (acercarse) utilice la tecla #
(almohadilla) y para alejarse utilice la tecla * (asterisco). El mapa tiene
un nivel máximo y un nivel mínimo de zoom, por tanto, si llega al nivel
máximo (o mínimo) de zoom, no podrá seguir acercando (o alejando) el
mapa. El nivel de zoom actual se muestra en una barra lateral a la
izquierda de la pantalla.
Diagrama 104 - Teclas de navegación
9.3 Cálculo de rutas
La aplicación permite calcular dos tipos de rutas de visita:
•
•
Ruta de visita entre dos puntos. Se obtienen indicando un punto
'desde aquí' y otro 'hasta aquí'. Al indicar los dos puntos (en
cualquier orden), la ruta se calcula automáticamente. Una vez
calculada la ruta es posible cambiar el punto de origen ('desde
aquí') o destino ('hasta aquí'), calculándose automáticamente
una nueva ruta.
Ruta de visita pasando por varios puntos. Se obtienen indicando
un punto 'desde aquí' y varios puntos 'pasando por aquí'. Tras
indicar los puntos de paso deseados, se deberá dar la orden de
'obtener ruta' para calcular la ruta más rápida que pasa por todos
los puntos intermedios de paso indicados.
9.4 Menú principal
El menú principal de la aplicación presenta el siguiente aspecto:
175
Diagrama 105 - Menú principal
Para desplegar el menú de la aplicación utilice el botón de acción en
su teléfono situado bajo el texto 'Menú'. El menú de la aplicación se
desplegará mostrando las opciones disponibles.
Diagrama 106 - Tecla menú
Cuando la acción de un comando de menú en la pantalla del mapa
no está disponible, ésta se deshabilita, de manera que no es posible
seleccionarla.
A continuación se detallan las acciones del menú principal.
9.4.1 Ruta desde aquí
La opción 'Ruta desde aquí' permite establecer el punto de origen de
una ruta en el centro actual de la pantalla. Este punto quedará
marcado con una señal de color verde.
176
Si ya había marcado un punto destino ('hasta aquí'), al establecer 'Ruta
desde aquí', se calculará automáticamente la ruta entre los dos puntos.
Para ello se le mostrará la pantalla 'Selección de tipo de ruta' donde
podrá seleccionar 'A pie' o 'En coche'. A continuación debe pulsar la
opción 'Ok', para obtener en la pantalla el mapa con la ruta.
Diagrama 107 - Punto de origen
9.4.2 Ruta pasando por aquí
Permite establecer un punto intermedio de visita por el que desea que
pase la ruta. Queda marcado con una señal de color azul. Cuando en
una ruta, únicamente hemos establecido el destino, este comando
permanecerá deshabilitado. Una ruta puede tener cero o más puntos
intermedios. En caso de tener uno o más puntos intermedios, el último
punto marcado será considerado como el punto destino de la ruta.
Diagrama 108 - Punto de origen y dos puntos de paso sobre el mapa
177
Al indicar puntos intermedios de visita, la ruta no se calcula
automáticamente hasta que usted dé la orden 'Obtener ruta'.
9.4.3 Ruta hasta aquí
Establece el punto de destino de la ruta. Queda señalado con una
marca de color rojo. Si hemos marcado algún punto intermedio en
nuestra ruta, el comando 'Ruta hasta aquí' permanecerá deshabilitado
y el último punto intermedio será considerado como el destino de la
ruta.
Si ya había marcado un punto origen ('desde aquí'), al establecer 'Ruta
hasta aquí', se calculará automáticamente la ruta entre los dos puntos.
Para ello se le mostrará la pantalla 'Selección de tipo de ruta' donde
podrá seleccionar 'A pie' o 'En coche'. A continuación debe pulsar la
opción 'Ok', para obtener en la pantalla el mapa con la ruta.
Diagrama 109 - Ruta calculada sobre el mapa
9.4.4 Obtener ruta
La aplicación calculará la ruta óptima de visita (más rápida) que pase
por los puntos que ha señalado previamente. Para que esté habilitado,
debe de haber señalado al menos un punto de partida y uno de visita.
En tal caso, la aplicación mostrará la pantalla de 'Selección de tipo de
ruta' donde podrá seleccionar 'A pie' o 'En coche', a continuación debe
pulsar la opción 'Ok', en ese momento la aplicación calculará la ruta
óptima y la mostrará en la pantalla sobre el mapa.
Si ha seleccionado un punto de partida y otro de destino mediante los
comandos 'Ruta desde aquí' y 'Ruta hasta aquí', la aplicación le llevará
automáticamente a la pantalla de 'Selección de tipo de ruta'. Cuando
se encuentre en esta situación podrá recalcular la ruta, cambiando
178
tanto el punto de partida como el punto de destino con los comandos
'Ruta desde aquí' y 'Ruta hasta aquí'.
Diagrama 110 - Selección de tipo de ruta
Diagrama 111 - Ruta calculada
9.4.5 Obtener indicaciones
Este comando estará habilitado únicamente cuando haya calculado
una ruta previamente; es decir, cuando tenga una ruta pintada en
pantalla. En tal caso, se mostrará una pantalla en la que podrá
consultar las indicaciones para seguir dicha ruta.
179
Diagrama 112 - Formulario obtener direcciones de ruta
Podremos centrar el mapa sobre cualquiera de los tramos de la ruta,
seleccionando en el formulario el tramo deseado y el comando de
menú ‘centrar en mapa’.
9.4.6 Anular ruta
Cuando tengamos en nuestro mapa alguna marca de punto de
partida, destino o paso de nuestra ruta, con esta acción, eliminaremos
dichos puntos y restableceremos el estado de nuestra ruta a vacía. Así
mismo, si teníamos unan ruta calculada, ésta se borrará de la pantalla,
así como todos sus puntos, ya sean puntos que hemos seleccionado o
puntos de interés (Ver sección 'Consulta información'). Este comando
únicamente estará habilitado cuando tengamos una ruta calculada o
hayamos marcado algún punto de ruta.
9.4.7 Selección puntos ruta
Este comando siempre está habilitado y muestra la pantalla de
'Selección de puntos de ruta'.
Desde esta pantalla puede gestionar sus puntos de ruta, es decir, puede
consultar los puntos que ha marcado sobre el mapa, añadir o eliminar
puntos de paso, o establecer tanto el punto de partida como el de
destino, siempre que sea posible.
180
Diagrama 113 - Formulario selección de puntos de ruta
Existen varias opciones:
Diagrama 114 - Menú contextual de selección de puntos de ruta
9.4.7.1 Ruta vacía
Si no ha marcado todavía ningún punto de nuestra ruta. Desde esta
pantalla tendrá tres opciones:
•
Situar el foco sobre el botón 'Seleccione ubicación de origen'.
Dicho botón le llevará al mapa, desde donde podrá navegar
hasta el punto que desee marcar y con la opción de menú
seleccionar, marcará el punto de origen con una señal verde y
volverá a la pantalla de 'Selección de puntos de ruta', en la que
aparecerá el punto que acaba de señalar. Una vez señalado el
181
punto de origen de una ruta, sólo es posible eliminarlo desde la
opción 'Anular ruta'.
•
Situar el foco sobre el botón 'Seleccione ubicación de destino'.
Dicho botón le llevará al mapa, desde donde podrá navegar
hasta el punto que desee marcar y con la opción de menú
seleccionar, marcará el punto de destino con una señal roja y
volverá a la pantalla de 'Selección de puntos de ruta', en la que
aparecerá el punto que acaba de señalar. Una vez señalado el
punto de destino de una ruta, sólo es posible eliminarlo desde la
opción 'Anular ruta'.
•
Pulsar el comando de menú 'Añadir punto de paso'. Dicho
comando le llevará al mapa, desde donde podrá navegar hasta
el punto que desee marcar y con la opción de menú seleccionar,
marcará el punto de destino con una señal azul y volverá a la
pantalla de 'Selección de puntos de ruta', en la que aparecerá el
punto que acabamos de señalar.
9.4.7.2 Ruta con punto de origen
Si ya ha seleccionado el punto de origen de nuestra ruta, existen varias
posibilidades:
•
•
•
Seleccionar ubicación de destino, tal y como se ha descrito
anteriormente.
Añadir punto de paso (desde el menú). Dicho comando le llevará
al mapa, donde podrá seleccionar un punto de paso que se
añadirá a la ruta.
Anular ruta. Dicho comando eliminará el punto de origen y le
llevará a la pantalla del mapa.
9.4.7.3 Ruta con punto de destino
Si ha seleccionado únicamente el punto de destino existen dos
posibilidades:
•
•
Seleccionar ubicación de origen, tal y como se ha descrito
anteriormente.
Anular ruta. Dicho comando eliminará el punto de destino y le
llevará a la pantalla del mapa.
9.4.7.4 Ruta con punto de paso
Si únicamente ha seleccionado uno o más puntos de paso tendrá las
siguientes opciones:
•
Seguir añadiendo puntos de paso.
182
•
•
•
•
Anular la ruta, con lo que eliminará los puntos de paso
seleccionados previamente.
Seleccionar punto de origen tal y como se ha descrito
previamente.
Si colocamos el foco sobre alguno de los puntos de paso de la
lista que aparece en pantalla, aparecerá un nuevo comando de
menú 'Eliminar punto de paso', seleccionando dicho comando,
aparecerá un mensaje de confirmación que aceptándolo
permitirá eliminar el punto de paso seleccionado de su ruta.
Cuando la ruta únicamente tenga puntos de paso seleccionados,
la acción 'Seleccionar ubicación de destino' permanecerá
deshabilitada, ya que se tomará como ubicación de destino el
último punto de paso seleccionado. Así mismo, el comando
'Calcular ruta' mostrará el mensaje 'No hay puntos suficientes para
calcular la ruta', hasta que no tenga seleccionada la ubicación
de origen.
9.4.7.5 Ruta con punto de origen y uno o más puntos de
paso
En este caso, tendrá habilitados los siguientes comandos:
•
•
•
•
Calcular ruta, esta orden le llevará a la pantalla de 'Selección de
tipo de ruta'.
Añadir punto de paso, le permitirá seguir seleccionando puntos
de paso sobre el mapa.
Anular ruta, eliminará todos los puntos de la ruta.
Colocando el foco sobre un punto de paso de los que aparecen
en la lista, aparecerá el comando de menú 'Eliminar punto de
paso' ya descrito previamente.
9.4.7.6 Ruta con punto de origen y punto de destino
En este caso tendremos dos opciones, 'Calcular ruta' o 'Anular ruta'.
Desde la pantalla de 'Selección puntos ruta' en cualquier momento
podrá volver al mapa a seguir navegando, con la orden 'Volver', los
puntos seleccionados permanecerán en el mapa, hasta que no se
utilice el comando 'Anular ruta'.
9.4.8 Consultar información
En la aplicación se muestran puntos de interés turísticos de la Región de
Extremadura (también llamados POI: Point of Interest). Los puntos de
interés se muestran con un símbolo según la categoría a la que
pertenecen. Los puntos de interés se muestran solamente a partir de un
183
determinado nivel de zoom. Si no ve puntos de interés, acérquese más
haciendo zoom.
Diagrama 115 - Puntos de interés sobre el mapa
Diagrama 116 - Cargando información
Diagrama 117 - Elementos encontrados
184
La orden 'Consulta información' solicita información acerca de los
puntos más cercanos al centro de la pantalla. Tras seleccionar esta
orden del ménu de la aplicación, se le mostrará un mensaje indicándole
si
se
han
encontrado
puntos
de
interés
cercanos.
En caso afirmativo, se le mostrará una pantalla con una lista de los
puntos cercanos, en la que se incluye la descripción asociada a los
puntos de interés.
Diagrama 118 - Formulario consultar información
9.4.8.1 Menú contextual de puntos de interés turísticos
Diagrama 119 - Menú contextual de consulta de información
Con las flechas arriba y abajo del teléfono puede seleccionar uno de los
puntos que se muestran en la lista. Una vez seleccionado un punto,
podrá acceder al menú de acciones sobre ese punto de interés,
pulsando la tecla de su teléfono situada bajo el texto menú. Las
opciones que se muestran son:
185
1. Punto de origen. Permite establecer el punto de interés como
punto de origen ('desde aquí') de una ruta.
2. Punto de paso. Permite establecer el punto de interés como
punto de visita intermedio ('pasando aquí') de una ruta.
3. Punto de destino. Permite establecer el punto de interés como
punto de destino ('hasta aquí') de una ruta.
4. Centrar en mapa. Centra el mapa exactamente en el punto de
interés. Si aparecen varios puntos muy cercanos o superpuestos,
puede acercarse haciendo zoom; el punto seleccionado se
mantedrá siempre en el centro de la pantalla.
5. Volver. Cierra la lista de puntos de interés buscados y vuelve al
mapa.
En esta pantalla el menú varía en función del estado en el que se
encuentra la ruta y el punto de interés. Se detallan a continuación los
posibles casos:
•
•
Si un punto ya pertenece a la ruta, la única acción posible sobre
él será 'Centrar en mapa', con este comando se mostrará en el
centro del mapa el punto de interés seleccionado.
Si un punto no pertenece a la ruta, el menú dispondrá de otros
comandos en función del estado de la ruta. Consulte la sección
F.7 'Selección puntos ruta' para más información.
Si tiene una ruta calculada en pantalla, al acceder a la pantalla de
'Consulta de información', la única acción posible sobre los puntos de
interés será 'Centrar en mapa', tanto si el punto pertenece a la ruta
como si no. Si tiene una ruta calculada y desea utilizar un punto de
interés como punto de referencia de una nueva ruta, primero deberá
Anular la ruta desde el menú de la pantalla del mapa (ver F.5).
9.4.9 Obtener localización
Activa el GPS interno del teléfono móvil, en caso de existir. Desde este
momento, la aplicación intentará obtener a través del GPS la
localización del teléfono móvil, situándola sobre el mapa.
Periódicamente se irá obteniendo la localización del móvil, desplazando
el mapa según sea conveniente.
Cuando se active el menú de la pantalla del mapa, o se acceda a
cualquier otra pantalla, el GPS se desactivará para economizar la
batería de su teléfono móvil. Existen otros dos casos en los que el GPS
será desactivado por la aplicación:
•
Al volver a la pantalla del mapa desde la pantalla 'Selección
puntos ruta' para seleccionar un punto de ruta. Esto es así, para
186
evitar recentrados del mapa y que pueda seleccionar el punto
que desee.
•
Al volver a la pantalla del mapa desde la pantalla 'Consultar
información' tras haber pulsado el comando 'Centrar en mapa'. El
mapa quedará centrado en el punto seleccionado y para volver
a activar el GPS habrá que hacerlo manualmente desde el menú
de la pantalla del mapa.
También podrá desactivar manualmente la localización desde el menú
de la aplicación. La opción 9 pasa a ser 'Detener GPS' cuando éste se
encuentra activo. Seleccione esta opción para desconectar el uso del
GPS.
9.4.10 Buscar POI (Puntos de Interés)
Esta opción permite buscar puntos de interés turísticos existentes en la
aplicación. Para ello se muestra una pantalla de introducción de
información de búsqueda.
Diagrama 120 - Selección de categoría de búsqueda de puntos de interés
187
Diagrama 121 - Formulario Buscar POI
En la pantalla encontrará dos secciones:
•
•
En la parte superior una lista desplegable donde podremos
seleccionar la categoría de puntos de interés por la que
queremos filtrar.
Debajo del desplegable aparece un cuadro de texto dónde
introducir las palabras de búsqueda a buscar. La aplicación
buscará puntos de interés que contengan la cadena introducida
de la categoría seleccionada. En caso de dejarla en blanco, se
mostrarán los puntos de interés que coincidan únicamente con la
categoría seleccionada.
Para seleccionar una categoría, sitúe el foco sobre el desplegable y
pulse el botón de 'acción' del teléfono (normalmente el botón central).
Podrá ver las categorías y seleccionar una de ellas con las flechas arriba
o abajo del teléfono. Para marcar la selección presionar de nuevo el
botón central.
A continuación, puede situar el foco sobre la caja de texto y con el
botón central iniciar la edición de texto.
Cuando termine la edición, con el comando 'Buscar' se iniciará la
búsqueda de puntos de interés que coincidan con los parámetros
seleccionados y se mostrará en una nueva ventana en la que se
mostrará el icono representativo de la categoría y una pequeña
descripción del punto. Para poder ver las acciones disponibles sobre los
puntos de interés, deberá navegar por la lista con las flechas
(arriba/abajo) del teléfono. Siempre que un elemento de la lista tenga
el foco podrá acceder a su menú asociado.
9.4.11 Salir
188
Cierra la aplicación
9.5 Teclas de acceso rápido
•
•
•
•
Menús. Cada comando de menú lleva asociado un número
indicativo de la tecla que lo ejecuta. Por ejemplo, el menú
principal consta de 12 comandos, numerados desde 1 hasta 12.
Para acceder al comando de menú número '8. Consultar
información', basta con desplegar el menú y a continuación,
pulsar la tecla 8 del teléfono móvil. Este comportamiento es el
mismo para todos los menús de la aplicación.
Desplazamientos: Los desplazamientos en el mapa se realizan con
las cuatro flechas de dirección del teléfono móvil.
# Zoom más (acercarse).
* Zoom menos (alejarse).
9.6 Resumen de teclas para BlackBerry
•
•
•
•
•
•
TrackBall. Tanto los comandos de menú, como las listas de los
formularios pueden recorrerse con el TrackBall del dispositivo, para
seleccionar un comando se puede hacer click con el TrackBall.
También es posible navegar por el mapa.
Menús. El acceso a los comandos de menú también puede
realizarse con el teclado numérico, destacar que en el caso de
BlackBerry para activarlo previamente hay que presionar la tecla
'ALT'.
w Zoom más (acercarse).
r Zoom menos (alejarse).
Alternativamente es posible navegar por el mapa con las teclas 'E'
(desplazar arriba), 'S' (izquierda), 'F' (derecha), 'X' (abajo), que en
la mayoría de dispositivos representan las cuatro direcciones del
mapa.
El acceso a los botones de menú, se realiza con las teclas que
están debajo de estos, es decir, 'Q' para el botón izquierdo del
menú, 'P' para el botón derecho.
9.7 Menú Conexión en BlackBerry
189
Diagrama 122 - Formulario conexión para BlackBerry
En BlackBerry es posible seleccionar varias opciones para realizar las
conexiones HTTP que permitan cargar los mapas en pantalla.
Las opciones disponibles son las siguientes:
1. Conexión por defecto a través de BlackBerry MDS
2. Conexión directa a través de la pila TCP
3. Conexión a través de WIFI (Es posible que necesite actualizar la
política de seguridad de su BlackBerry)
4. Conexión explícita a través de BlackBerry MDS
5. Conexión alternativa a través de MDS
Nota: Actualmente la aplicación no permite la conexión a través de BIS
190
10.
Manual de instalación
10.0 Introducción
Los diferentes manuales de instalación de la aplicación: sobre teléfonos
móviles, sobre BlackBerry y sobre Windows Mobile.
10.1 Instalación sobre teléfonos móviles
10.1.1 Instalación OTA (Over-the-air)
Este tipo de instalación consiste en la descarga (e instalación
automática) de la aplicación desde Internet. Para proceder a la
instalación, acceda al link suministrado del fichero SIGATEXRutas.jad a
través del navegador de su teléfono. La instalación se iniciará
automáticamente.
10.1.2 Instalación manual
Es posible descargar directamente los archivos SIGATEXRutas.jar y
SIGATEXRutas.jad a un ordenador y realizar la instalación manual de la
aplicación transfiriéndola al teléfono móvil, bien mediante Bluetooth, a
través del gestor de aplicaciones que proporcione el fabricante o
transfiriendo la aplicación a la tarjeta de memoria del teléfono móvil.
Para ello consulte el manual del teléfono para instalar aplicaciones.
10.1.3 Versión firmada vs Versión sin firmar
Se proporcionan dos versiones de la aplicación:
•
•
Una versión firmada digitalmente con un certificado de seguridad
de Thawte.
Una versión sin firmar.
El motivo de firmar la aplicación es que las directivas de seguridad de
los teléfonos móviles, generalmente, no permiten el acceso a algunas
funcionalidades de la máquina virtual (como puede ser el acceso a
ficheros en disco) para aplicaciones no firmadas. Por tanto, es necesario
firmar digitalmente la aplicación para poder, por ejemplo, guardar los
mapas descargados en la tarjeta de memoria del teléfono sin que éste
nos esté preguntando continuamente si deseamos acceder al sistema
de ficheros.
191
Aún así, hay teléfonos que no reconocen la firma digital y por tanto,
para poder ejecutar la aplicación se proporciona una versión sin firmar,
en la que los mapas no son guardados en memoria, lo que supone un
mayor acceso a Internet. En cualquier caso, para poder instalar la
versión firmada es necesario hacerlo mediante el archivo .JAD.
10.1.4 Posibles problemas con la instalación
Debido a la gran variedad de dispositivos existentes en el mercado es
posible que la aplicación no se instale correctamente. Algunos teléfonos
no permiten instalar aplicaciones firmadas, otros no dejan instalar
aplicaciones sin firmar y otros no permiten la instalación de aplicaciones
de terceros. En cualquier caso es recomendable consultar el manual del
fabricante del teléfono móvil o directamente con el proveedor del
teléfono si hay algún problema no descrito en este manual.
A continuación se explican de manera general los pasos a seguir y
posibles incidencias que pueden ocurrir durante la instalación:
• En primer lugar, es recomendable si ya hay una versión instalada en el
teléfono, no instalar encima otra versión, es decir, primero eliminar la
anterior versión. Esto es especialmente importante en el caso de
BlackBerry ya que puede dar lugar a errores en la instalación.
• Se proporcionan dos versiones de la aplicación, una versión firmada y
otra sin firmar(1). Se recomienda intentar instalar en primer lugar la
versión firmada. La ventaja de esta versión es que permite almacenar
en la memoria del teléfono los mapas que se van descargando.
(1) Para BlackBerry existe una única versión sin firmar, consultar el
Manual de instalación para BlackBerry.
• Si el teléfono no permitiera la instalación de la versión firmada, es
recomendable comprobar si éste cuenta con el certificado raíz de
Thawte Premium Server (el proveedor que proporciona el certificado
para firmar la aplicación), en caso de no tenerlo, intentar actualizar el
firmware del dispositivo. Puede ocurrir que el teléfono tenga el
certificado raíz de Thawte pero la aplicación no se instale
correctamente, en este caso, consultar con el proveedor del teléfono
para comprobar si permite la instalación de aplicaciones firmadas por
terceros.
• En caso de que el teléfono no permita la instalación de la aplicación
firmada, proceder a la instalación de la versión sin firmar. En esta versión,
no se almacenan en caché los mapas descargados, con lo que el
acceso a Internet será mayor. Si el teléfono no permite la instalación de
la aplicación puede ser por dos motivos, o bien el tamaño del jar es
192
mayor del tamaño máximo permitido por el teléfono (para comprobarlo
consultar las especificaciones del dispositivo) o bien el teléfono no
permite la instalación de aplicaciones no firmadas.
• Si no se consigue instalar ninguna de las dos versiones, posiblemente el
teléfono no admita la instalación de aplicaciones de terceros, en
cualquier caso consulte con su proveedor.
• Para BlackBerry es recomendable actualizar a una versión del sistema
operativo mayor o igual a la 4.2
• Por último, en algunos dispositivos como SmartPhone o BlackBerry es
posible que la aplicación se instale, arranque, pero no cargue ningún
mapa. En ese caso, se deberá configurar el APN, para permitir el acceso
a conexiónes HTTP a la aplicación a través de un punto de acceso del
proveedor. En BlackBerry se puede configurar desde: Configuración>Opciones Avanzadas->TCP. Consulte con su proveedor los datos de la
configuración APN para su dispositivo(1). En cualquier caso, si la
aplicación no carga ningún mapa deberá comprobar que dispone de
acceso a internet, consulte con su proveedor.
NOTA: Es posible que tras realizar cambios de configuración en
BlackBerry (u otros teléfonos) se necesite resetear el dispositivo para que
éstos tengan efecto. Normalmente se suficiente con apagar el
dispositivo, quitar la batería varios segundos y volver a encender.
• En ocasiones muchos de los problemas descritos anteriormente se
solucionan actualizando el firmware del dispositivo a la última versión
proporcionada por el fabricante.
(1) Existe un listado de configuraciones APN para varios proveedores de
varios países:
http://www.flexispy.com/Mobile%20APN%20Setting%20to%20use%20GPR
S.htm
193
10. 2 Manual de instalación BlackBerry
10.2.1 Versión para BlackBerry
Para BlackBerry se proporciona una única versión que no va firmada
digitalmente, esto es así, porque los teléfonos BlackBerry no imponen
ninguna restricción a la máquina virtual Java.
10.2.2 Instalación OTA (Over-the-air)
Este tipo de instalación consiste en la descarga (e instalación
automática) de la aplicación desde Internet. Para proceder a la
instalación, acceda al link suministrado del fichero SIGATEXRutas.jad a
través del navegador de su teléfono. La instalación se iniciará
automáticamente.
10.2.3 Instalación manual
Es posible descargar directamente los archivos SIGATEXRutas.jar,
SIGATEXRutas.jad y los SIGATEX*.cod a un ordenador y realizar la
instalación manual de la aplicación transfiriéndola al teléfono móvil,
bien mediante Bluetooth, a través de BlackBerry Desktop Manager que
proporciona el fabricante o transfiriendo la aplicación a la tarjeta de
memoria del teléfono móvil. Para ello consulte el manual de BlackBerry
para instalar aplicaciones.
10.2.4 Configuración de BlackBerry
Una vez instalada la aplicación es recomendable realizar los siguientes
pasos de configuración.
•
•
En
Configuración->Opciones
de
seguridad->Permisos
de
aplicación, seleccionar la aplicación SIGATEX, presionar el botón
Menú y luego en Editar permisos, poner en todos los campos
permitir.
En
Configuración->Opciones
de
seguridad->Servidor
de
seguridad, cambiar el estado a Activado
Cuando ejecutemos la aplicación, nos aparecerán dos mensajes, uno
advirtiendo de que la aplicación va a acceder al sistema de ficheros
(conexiones file), deberemos elegir la opción ‘Permitir’ y no volverá a
preguntar más. Luego saldrá otro mensaje advirtiendo de que la
aplicación quiere acceder a conexiones HTTP, elegir también Permitir.
10.2.5 Posibles problemas con la instalación
194
•
•
•
•
Si se produce algún error durante la instalación es conveniente
asegurarse de que no había una versión anterior instalada. Si ya
había otra versión instalada, ir a: Menú->Configuración->Opciones
avanzadas->Aplicaciones, a continuación seleccionar SIGATEX y
desde el Menú seleccionar la opción Eliminar. Es posible que tras
realizar esta acción tenga que reiniciar su BlackBerry.
Si la aplicación se instala, pero no se ve correctamente el mapa,
los menús, o la interfaz de usuario es posible que tenga una
versión antigua del sistema operativo, es recomendable actualizar
a una versión de BlackBerry OS superior a la 4.2.
Si la aplicación se instala con éxito pero no puede visualizar
mapas es posible que su BlackBerry no esté configurada
correctamente para que aplicaciones Java accedan a internet.
Pruebe desde el menú de la aplicación Configuración>Conexiones las distintas opciones de conexión recargando cada
vez el mapa haciendo zoom más o zoom menos
Si ninguna de las opciones hace que la aplicación descargue
información desde Internet, configure el APN de su BlackBerry
para permitir el acceso a conexiones HTTP a la aplicación a través
de un punto de acceso del proveedor. Se puede configurar
desde: Configuración->Opciones Avanzadas->TCP. Consulte con
su proveedor los datos de la configuración APN para su
dispositivo[1] y la tarifa por la descarga de datos.
Nota: Actualmente, la aplicación NO soporta la descarga de datos a
través de BlackBerry Internet Service (BIS).
•
Si intenta descargar mapas vía wifi (Seleccionando la opción
interface=wifi desde el menú Configuración->Conexiones de la
aplicación) y sale un mensaje de error advirtiendo de que la
operación va en contra de su IT Policy, es debido a que la política
de seguridad de su BlackBerry no permite el acceso a conexiones
HTTP a través de wifi de aplicaciones J2ME.
En este caso, puede actualizar la política de seguridad a una menos
restrictiva que permita el acceso a través de wifi. Consultar el
documento Actualizar política de seguridad en BlackBerry [2]
•
En muchos casos, sobre todo cuando cambie propiedades de
configuración, es posible que necesite resetear su BlackBerry. Para
ello, apague la BlackBerry, quite la batería unos segundos y
vuelva a encenderla.
[1] Existe un listado de configuraciones APN para varios proveedores de
varios países:
195
http://www.flexispy.com/Mobile%20APN%20Setting%20to%20use%20GPR
S.htm
[2]https://confluence.prodevelop.es/pages/viewpage.action?pageId=6
029357
196
10.3 Manual de instalación Windows Mobile
10.3.1 Máquina virtual Java
Para el correcto funcionamiento de SIGATEX en dispositivos con
Windows Mobile es necesario instalar la máquina virtual de IBM, J9 para
MIDP 2.0
Nota: Actualmente, IBM no distribuye la máquina virtual J9 directamente
desde su página web.
10.3.2 Instalación de J9
Para instalar J9 en Windows Mobile deberá transferir al sistema de
archivos los directorios bin y lib.
Además para habilitar el acceso a ficheros (JSR-75) hay que realizar los
siguientes pasos:# Descargar este jar [1] de IBM.
1. Abrir
el
jar
y
copiar
el
archivo
fixed\ive2.2\runtimes\wm2003\arm\midp2\bin\fileconn.dll en la carpeta
bin\ de J9 en Windows Mobile.
fixed\ive2. Copiar
2.2\runtimes\wm2003\arm\midp2\lib\jclMidp20\ext\fc.jar en la
carpeta lib\jclMidp20\ext\ de J9 en Windows Mobile.
[1]http://service.boulder.ibm.com/ibmdl/pub/software/pervasive/updat
es/571/techs/features/com.ibm.weme.wm2003.arm.pdapfc.runtime22_5.7.1/wsdd5.0.jar
10.3.3 Instalación de SIGATEX con J9
A continuación, deberá ejecutar el archivo emulator.exe que se
encuentra dentro de la carpeta bin. Aparecerá una pantalla en la que
se indicará que introduzca la URL donde se encuentra la aplicación que
quiere instalar, deberá indicar la ruta donde se encuentra el archivo
SIGATEXRutas.jar, si está en la raíz del dispositivo, entonces teclear:
file:///SIGATEXRutas.jar
Es posible que durante la instalación aparezcan varios mensajes con
advertencias, en tal caso, aceptar todos. Finalmente aparecerá un
mensaje indicando que la aplicación se ha instalado con éxito.
Seguidamente, deberá configurar los permisos de la aplicación. Desde
el menú Actions->Permissions deberá permitir las siguientes conexiones:
HTTP, File Read y File Write.
197
198
11.
Requisitos del dispositivo móvil
11.0 Introducción
Como es imposible probar una aplicación en todos los teléfonos es
conveniente comprobar qué teléfonos cumplen con los requisitos de la
aplicación.
11.1 Requisitos mínimos
Los requisitos del terminal móvil (teléfono) para el funcionamiento del
subsistema móvil son los siguientes:
•
•
•
•
Teléfono móvil con máquina virtual Java Micro Edition (Java ME).
Configuración CLDC 1.1
Perfil MIDP 2.0
Transmisión de datos GPRS
11.2 Requisitos recomendados adicionales
•
•
•
•
JSR-179 Location API para soporte local de GPS.
Transmisión de datos 3G (UMTS) o 3,5G (HSDPA).
JSR-75 para acceso a ficheros en disco
JSR-172 para acceder a servicios web (cálculo de rutas)
11.3 Requisitos de la máquina virtual
Es importante que la máquina virtual Java del teléfono cumpla con los
siguientes requisitos, de lo contrario no será posible la jecución de la
aplicación.
•
•
Tamaño del heap Java: Para teléfonos con tamaño del heap
Java estático, al menos 2 Mb, aunque lo recomendable son
teléfonos con heap dinámico de manera que el límite en Mb para
cargar la aplicación en memoria viene marcada por el espacio
libre de la memoria del teléfono.
Tamaño máximo del JAR: Para la aplicación firmada 447Kb, para
la aplicación sin firmar 990Kb. Esto supone un gran impedimento
sobretodo en teléfonos más antiguos en los que se limitaba el
tamaño máximo de aplicaciones a unos cuantos Kb.
199
12.
Testing sobre dispositivos reales
12.0 Introducción
Resultado del testing sobre dispositivos reales.
12.1 Listado de teléfonos probados
Teléfono
Sistema
¿Se instala?
operativo/Java
¿Arranca? Códigos de error
BlackBerry
Curve
Sí. Hay que
8310,
BlackBerry OS >
BlackBerry
instalar con Sí
4.2
Pearl 8110,
jad+jar+cod
BlackBerry
8210...
LG KU990
La
versión
firmada no.
CLDC 1.1/MIDP
La versión sin No
2.0
firmar
tampoco
Motorola
V3X
La
versión
CLDC 1.1/MIDP firmada no.
Sí
2.0
La versión sin
firmar sí
Nokia N73,
Nokia 6110
Symbian
Navigator,
3rd ed.
Nokia
6120...
Nokia
NGage
Nokia S40 3rd
CLDC Sí
Nokia 6280 ed./
1.1/MIDP 2.0
Probablemente hay
una versión anterior
COD
instalada. Desintalar
string
la versión anterior
de la aplicación y
volver a instalar
Autenticación fallida.
Tamaño
del
JAR
supera el tamaño
máximo
Funcionalidades
que no van
Peculiaridades
Con
GPRS
va
bastante lenta la
carga de tiles. No
he probado GPS. La
caché en disco a
veces
da
excepciones.
Hay que configurar sí
o sí el APN del
proveedor
para
acceder a Internet.
Para acceder a WIFI
hay que actualizar la
política de seguridad,
ver
documentación
en el manual de
instalación. Los MIDlets
para BlackBerry no
necesitan
firmarse.
Con
versiones
del
sistema
operativo
anteriores a la 4.2 hay
un bug en LWUIT que
hace que no se pinte
la pantalla completa.
-
gvSIG Phone sin firmar
sí que se instala (son
500Kb). El tamaño
máximo del jar es
1Mb, instalando la
versión sin firmar de
990Kb
tampoco
funciona
Autenticación fallida
No reconoce
firma de Thawte
No va JSR-75. Da
OutOfMemoryError
al abrir cualquier
la formulario.
Tampoco llega a
cargar todos los tiles
(se
queda
sin
memoria)
Creo los Motorola
utilizan una librería
nativa para acceder
a ficheros. La demo
de LWUIT también da
OutOfMemoryError al
abrir
cualquier
formulario.
Al
arrancar
la
aplicación
solicita
que demos acceso a
Internet
repetidas
veces y al final la
aplicación se cierra.
Instalando
desde
Internet dice 'Archivo
JAR no válido' ->
Instalar
desde
el
ordenador con Nokia
PC
Suite
o
por
Bluetooth
La aplicación no
consigue conectar
con
la
configuración
de
En principio va todo
Internet
seleccionada.
Seleccionar
otra
configuración.
Antes de ejecutar la
aplicación hay que
configurar
los
permisos. Reconoce la
firma de Thawte
No
Error del sistema
-
-
No
Aplicación no válida
(No
reconoce
la
firma). El tamaño del
archivo
es
muy
grande.
No
deja
escribir en disco con
lo cual no hay
acceso a puntos de
interés.
Ofuscando
la
versión firmada se
puede instalar con
el jar y el cable del
teléfono pero da
OutOfMemoryError.
gvSIG phone sí que se
instala con el cable,
da OutOfMemoryError
pero cambiando el
tamaño de la caché
ha funcionado. La
carga de tiles va más
rápida que en ningún
otro móvil (sólo tiene
conexión GPRS). No
funciona la caché en
disco.
'JAR
supera
tamaño máximo'
-
-
Sí. Tanto la
versión
S60 firmada
Sí
como
la
versión
sin
firmar
Symbian S60 1st
ed. / CLDC 1.0 No
/ MIDP 1.0
907
Invalid
illegal
host
starts with '/'
Solución
Samsung
CLDC 1.1/MIDP La
versión
No
SGH E250V 2.0
firmada no
el
-
-
200
se instala. La
versión
sin
firmar
da
error:
'JAR
supera
el
tamaño
máximo'
No va el cálculo de
rutas
porque
el
teléfono no tiene
JSR-172. Al navegar
gvSIG
Phone
se
en el nivel de POIS
queda en la pantalla
aparecen
de splash
excepciones,
es
posible que haya
algún
problema
con JSR-75
Samsung
SGH Z150
La
versión
firmada no
CLDC 1.1/MIDP
se instala. La 2.0
versión
sin
firmar sí
-
-
Samsung
ZV60
CLDC 1.1/MIDP
Sí
2.0
-
Da
OutOfMemoryError
al hacer zoom si está activado el
escalado del mapa
Deja configurar todos
los permisos aunque la
aplicación no esté
firmada.
-
-
Carga los tiles muy
rápido
El
rendimiento
es
bastante pobre en la
máquina virtual por
defecto
de
WM.
Instalando
J9
van
todas
las
funcionalidades
y
conecta a Internet.
Hay que añadir a
mano las librerías JSR75 en J9
Sí
Sony
Ericsson
K800
CLDC 1.1/MIDP
Sí
2.0
Sí
Error en la operación
Puede ser porque el
teléfono
tiene
demasiadas
aplicaciones
instaladas.
Eliminando algunas
se resuelve
Sony
Ericsson
G502
CLDC 1.1/MIDP
Sí
2.0
Sí
-
-
La
versión
HTC
Windows
firmada no.
Touch,
Mobile 5/JVM
Sí
La versión sin
HTC TyTN... Esmertec JBed
firmar sí
-
-
En general no va el
acceso a ficheros
JSR-75.
Hay
problemas con los
POIs. Con JBed no
conecta a Internet
Windows
Palm Treo
Mobile 6/ JVM Sí
500v
Esmertec JBed
Sí
-
-
-
Sólo he probado la
versión sin firmar y
funciona bien.
Nokia S40 3rd
Nokia 6300 ed./
CLDC No
1.1/MIDP 2.0
No
Aplicación no válida
(No
reconoce
la firma).
-
-
Nokia N95
-
-
-
-
-
-
-
Nokia E70
-
-
-
-
-
-
-
Nokia 5800
Nokia S60 5th
Sí
edition
Sí
StackOverFlowError
Parece ser que hay
un
problema
al
cargar el archivo
del índice espacial recursivamente.
Habría que hacerlo
iterativamente
Al instalar transfiriendo
por bluetooth gvSIG
phone
firmado
aparece
el
error:
Faltan
atributos
obligatorios. Pasando
lor archivos a la
carpeta 'intalls' de la
tarjeta de memoria se
instala sin problemas.
No
he
probado
instalación OTA
Tabla 9 - Testing de teléfonos
12.2 Resumen
Teléfono
Comentario
Nokia S60
Se reconoce la firma y funciona todo
No reconoce la firma, la versión sin firmar funciona pero hay
restricciones de memoria
Nokia S40
Sony
Ericsson
Se reconoce la firma y funciona todo
Motorola
No reconoce la firma y la versión sin firmar arranca pero es
imposible utilizarla
201
Samsung
BlackBerry
Windows
Mobile
•
No reconoce la firma, la versión sin firmar funciona pero hay
problemas con los puntos de interés, no va el cálculo de rutas (no
hay JSR-172)
Funciona todo
En WM 6.1 funciona en versiones anteriores no. Con J9 sí que
funciona
12.3 Conclusiones del testing
La premisa 'write once, run everywhere' no es cierta. ¿Por qué?
1. Diferentes dispositivos con diferente
restricciones de la memoria disponible.
hardware
provoca
2. Bugs/distinta implementación de las máquinas virtuales.
3. La existencia de librerías opcionales supone un problema de
compatibilidad.
4. Restricciones por parte de las operadoras, ellas deciden qué se
puede instalar y qué no.
5.
Restricciones
por
certificados+permisos.
•
el
modelo
de
seguridad:
Soportar todos los teléfonos móviles es imposible. ¿Qué se puede
hacer?
1. Disminuir el tamaño del jar de la aplicación y la memoria
necesaria para su correcto funcionamiento. Actualmente, la
aplicación funciona bien en teléfonos que no imponen
restricciones en el tamaño del jar y en la cantidad de memoria
para aplicaciones Java. En el resto o bien no se instala porque la
aplicación es muy grande o bien da continuos mensajes
OutOfMemoryError durante la ejecución.
2. Detectar los posibles bugs e ir corrigiéndolos. Por ejemplo, se
detectó que en la implementación de JSR-172 en Nokia no se
devolvía el carácter ']', hubo que parchear la aplicación para
solucionarlo.
3. Utilizar librerías opcionales limita la compatibilidad. Actualmente
se utilizan:
JSR-75 para el acceso a ficheros que presenta problemas
de permisos ya que es una librería restringida por la mayoría
de operadoras.
202
JSR-172 para servicios web (cálculo de rutas). Muchos
móviles directamente no la implementan, por tanto, no hay
acceso a cálculo de rutas.
JSR-179 para GPS. Generalmente todos los móviles con GPS
la implementan.
4. No se puede luchar contra el modelo de negocio de las
operadoras, por tanto, no se puede hacer nada a parte de
flashear el móvil o algo parecido.
5. El certificado Thawte de momento, sólo ha sido reconocido en
teléfonos Nokia S60 y en Sony Ericsson. El principal problema está
en que la librería JSR-75 necesita permisos que en la mayoría de
teléfonos sólo se pueden obtener por aplicaciones firmadas y esta
librería es la que permite navegar por el mapa sin necesidad de
conexión de datos.
•
¿Qué medidas concretas tomar?
1. Aplicando un ofuscador se reduce el tamaño del jar en
apróximadamente 200Kb, quedando la aplicación firmada en
450Kb (un tamaño aceptable). La aplicación sin firmar queda en
990Kb y prescindiendo de los puntos de interés quedaría en 430
Kb, la gestión de puntos de interés en local es un lastre que limita
la compatibilidad.
2. Prescindir de las imágenes (iconos y splash) en el jar disminuiría
su tamaño. Las imágenes se pueden descargar de Internet al
arrancar la aplicación por primera vez.
3. Mejorar el rendimiento de la aplicación implica refactorizar y
aplicar un conjunto de optimizaciones en el código.
4. Mediante un profiler se observa que el 50% del tiempo de CPU
se consume en operaciones de entrada/salida (conexiones HTTP y
acceso a disco) y el 30% en operaciones de pintado de pantalla.
El 20% restante se utiliza en el resto de la lógica de la aplicación.
Se podría estudiar cómo optimizar la entrada/salida (quizás
utilizando conexiones persistentes ¿?) y para el pintado utilizar
buffers o 'clipping'.
5. La librería gráfica LWUIT tiene un tamaño aproximado de 200Kb.
Se podría intentar reducir el tamaño de LWUIT haciendo una
compilación mínima de la librería prescindiendo de componentes
que no se utilicen.
203
6. Es posible firmar una misma aplicación con diferentes
certificados de diferentes entidades siempre que se utilice la
misma clave pública. Se podría firmar la aplicación con Thawte +
Verisign para aumentar la compatibilidad de la aplicación
firmada.
204
13.
Conclusiones y ‘future work’
Conclusiones
Los objetivos previos al desarrollo del subsistema móvil y los problemas
surgidos durante el desarrollo se han superado con éxito.
Se ha desarrollado una aplicación completamente funcional y de
código abierto, soportada por gran cantidad de dispositivos móviles,
que permite consultar información geográfica de Extremedura, calcular
rutas entre diversos puntos, buscar y consultar información de recursos
turísticos y culturales de la comunidad y aprovechar la geolocalización
a través de GPS.
A pesar del éxito es importante comentar cuáles han sido las
dificultades y cómo se han superado:
•
Respecto al hardware:
Hoy en día coexisten en el mercado una gran cantidad de dispositivos
completamente heterogéneos en cuanto a sus características.
Previamente a comenzar el desarrollo se propuso una aplicación
dirigida a teléfonos con máquina virtual J2ME (CLDC 1.1 - MIDP 2.0), en
la práctica se ha visto que, soportar absolutamente todos los teléfonos
es una tarea casi imposible y que requiere emplear una cantidad de
recursos que no es en absoluto rentable. Esto es debido principalmente
a tres motivos:
1. La especificación J2ME deja lugar a la interpretación.
2. Las implementaciones de los fabricantes tienen bugs,
algunas veces conocidos y otras no. Por ejemplo, durante el
desarrollo se descubrió que los teléfonos Nokia (S60 3rd
edition) al utilizar el paquete de web services, ignoraban en
las respuestas del servidor el carácter ']', con lo que era
imposible parsear la respuesta GeoJSON del servidor de
rutas y hubo que hacer un 'workaround' para resolver ese
bug.
3. La rápida evolución del mercado de teléfonos móviles
hace que coexistan teléfonos modernos con características
muy avanzadas con teléfonos muy limitados.
La solución a este problema es marcar un conjunto de dispositivos como
objetivo y desarrollar para ellos. En nuestro caso, se ha restringido el
conjunto de dispositivos mediante unos requisitos mínimos que algunos
205
de los teléfonos en el mercado no soportan, pero que aún así, cubre la
mayoría de modelos recientes.
•
Respecto a la tecnología:
Se ha comentado a lo largo del documento la problemática de J2ME,
yo lo resumiría en: "sí, se puede desarrollar aplicaciones J2ME pero no
puedes tener la certeza de que luego tu aplicación se comporte igual
en todos los dispositivos".
Por suerte, hoy en día (sobre todo desde la aparición de MIDP 2.0), los
dispositivos se comportan mucho mejor que antes. Aún así, hay
cuestiones que no están en la mano del desarrollador el poder resolver:
1. Las implementaciones de las interfaces de usuario son
diferentes en la mayoría de dispositivos, esto hasta ahora
hacía que los desarrolladores (sobre todo las grandes
empresas) crearán sus propias librerías de componentes.
Actualmente, LWUIT resuelve este problema.
2. Existen demasiados paquetes opcionales. Esto implica que
las máquinas virtuales de los teléfonos no tienen porqué
implementarlas y en muchos casos restringe las
posibilidades en cuanto a desarrollo. En nuestro caso se
utilizan: JSR-75 (acceso a ficheros), JSR-179 (GPS) y JSR-172
(Web services) que sustentan el núcleo funcional de la
aplicación.
3. El modelo de seguridad de J2ME impone todavía más
restricciones a los desarrolladores, y en parte, es uno de los
motivos por los que J2ME no ha tenido tanta repercusión
como debería. A grandes rasgos, el modelo de seguridad
implica que el acceso a ciertas APIs de la máquina virtual,
requiere pertenecer a cierto dominio de seguridad. Esto
implica firmar la aplicación mediante un certificado de
seguridad (firma digital), una vez más este hecho no hace
más que fragmentar el ecosistema de dispositivos, no todos
soportan firmas, no todos permiten acceso a ciertas APIs,
etc. Además, operadoras y fabricantes se reservan dos
dominios de seguridad exclusivos.
•
A nivel funcional:
Desarrollar para dispositivos móviles no es lo mismo que desarrollar para
PC o para web y es algo que hay que tener en mente durante todo el
proceso.
206
Por una parte, la limitación de recursos lleva a tomar decisiones de
diseño en favor del ahorro de los mismos y en detrimento de la
modularidad, el diseño orientado a objetos, etc. Por ejemplo, en nuestro
caso se diseñó un índice espacial optimizado para dispositivos con muy
pocos recursos.
Por otra parte, hay que tener en cuenta la usabilidad de la aplicación.
Un usuario de un dispositivo móvil se comporta de distinta manera que
el usuario de un PC. Rara vez quiere configurar nada, necesita acceder
a la información rápidamente. Por ejemplo, una aplicación que tarde
más de 10 segundos en arrancar, que haya que perder un minuto en
configurarla o que el acceso a cierta funcionalidad (por ejemplo
consultar la información de un punto de interés), tarde más de 5
segundos es candidata a no ser usada nunca más y fracasará. Así
mismo, la usabilidad debe ser intuitiva que no requiera demasiado
tiempo (o ninguno) de aprendizaje.
Por último, a pesar de que los dispositivos han evolucionado mucho, hay
que tener claro que hay muchas cosas que no se pueden hacer en un
móvil. El objetivo debería ser aprovechar la conectividad de los
dispositivos móviles para convertirlos en cliente de servicios pesados
para soportar ‘ese tipo de cosas’. En nuestro caso, cliente de WMS y
cliente de servicio de rutas.
SIGATEX Móvil fue presentado en las terceras jornadas de software libre
de Girona por Miguel Montesinos, Director Técnico de Prodevelop y
tanto el código fuente como los binarios serán publicados y liberados
con licencia GPL en breve por la Consejería de Cultura y Turismo de la
Junta de Extremadura.
Future work
Tras el desarrollo de SIGATEX móvil, desde Prodevelop, se han dado
varios pasos más hacia delante en cuanto a desarrollo de SIG libre para
dispositivos móviles, abriendo un nuevo abanico de plataformas sobre
las que desarrollar proyectos geoespaciales.
Los objetivos que se han querido ampliar son:
1. Optimizar la gestión de recursos de la aplicación para
soportar más teléfonos.
2. Permitir al usuario consultar, configurar y consumir la
información geográfica de servidores de tiles, servidores
WMS y servidores WMS-c.
3. Soportar servicios de rutas y búsqueda de direcciones
globales.
207
4. Permitir reproyectar información geográfica (localización
GPS, rutas y puntos de interés) a distintos sistemas de
referencia de coordenadas en función de la capa actual.
Para ello, aprovechando la filosofía del software libre, SIGATEX
evolucionó a gvSIG phone, una aplicación SIG para J2ME con las
siguientes características (ADJUNTAR CAPTURAS):
•
Formularios para configurar capas WMS, WMS-c con soporte
para la operación WMS GetCapabilities.
Diagrama 123 - Formulario GetCapabilities
208
Diagrama 124 - Capa PNOA
•
Capas de servidores de tiles preconfiguradas: Open street
maps, Yahoo maps, Microsoft maps.
Diagrama 125 - Capas preconfiguradas
Diagrama 126 - Capa OSM
209
•
Soporte a YOURS (Yet another routing service): Servicio de
cálculo de rutas libre de Open Street Maps.
•
Soporte a Namefinder: Servicio de
direcciones libre de Open Street Maps.
búsqueda
de
Diagrama 127 - NameFinder en gvSIG phone
•
Utilización del paquete de reproyección de gvSIG Mobile
sobre gvSIG phone.
210
Con esto tenemos una aplicación completamente funcional y más
versátil, que reutiliza gran parte de la funcionalidad y arquitectura de
SIGATEX y dirigida también a usuarios de carácter turístico pero con la
posibilidad de consultar información a nivel global.
Actualmente, se está desarrollando un 'port' de gvSIG phone a la
plataforma libre de Google, Android. El objetivo es mantener la
funcionalidad pero aprovechando la mayor potencia de los nuevos
dispositivos sobre el sistema operativo Android.
Así mismo, dado el carácter libre de gvSIG phone ya hay
desarrolladores que han mostrado su interés en desarrollar nuevas
funcionalidades, tales como, acceso a servicios de rutas de transporte
público, consumo de APIs de plataformas web 2.0 (Twitter), etc.
Tanto gvSIG phone como gvSIG mini, serán publicados y liberados por
Prodevelop bajo licencia GPL próximamente y han sido presentados
con gran interés por parte de la audiencia en las terceras jornadas de
software libre de Girona (LINK)
211
A. Índice
1.
PRESENTACIÓN DEL PROYECTO ......................................................................................... 2
1.1 INTRODUCCIÓN ............................................................................................................................2
1.2 SISTEMAS DE INFORMACIÓN GEOGRÁFICA .....................................................................................2
1.3 ADAPTACIÓN DEL SIG DE LA CONSEJERÍA DE CULTURA Y TURISMO .................................................2
1.4 DESCRIPCIÓN INFORMAL DEL SUBSISTEMA MÓVIL ............................................................................2
1.5 ORGANIZACIÓN DEL DOCUMENTO ................................................................................................3
2.
COMPONENTES DEL SISTEMA DE INFORMACIÓN GEOGRÁFICA ................................... 5
2.0 INTRODUCCIÓN ............................................................................................................................5
2.1 DESCRIPCIÓN DE COMPONENTES ..................................................................................................5
2.2 DIAGRAMA DE COMPONENTES ......................................................................................................5
2.3 INTERACCIÓN Y DEPENDENCIA CON OTROS SUBSISTEMAS ................................................................6
3.
ANÁLISIS DE REQUISITOS .................................................................................................... 7
3.1 INTRODUCCIÓN ............................................................................................................................7
3.2 DIAGRAMA UML DE CASOS DE USO ..............................................................................................7
3.3 ACTORES .....................................................................................................................................7
3.4 DESCRIPCIÓN DE CASOS DE USO ...................................................................................................9
3.4.1 Caso Uso Anular Ruta ............................................................................................... 9
3.4.2 Caso Uso Consultar Información........................................................................... 10
3.4.3 Caso Uso Eliminar Punto de Paso de Ruta ........................................................... 12
3.4.4 Caso Uso Establecer Punto de Paso de Ruta ...................................................... 13
3.4.5 Caso Uso Establecer Punto Fin de Ruta ............................................................... 15
3.4.6 Caso Uso Establecer Punto Inicio de Ruta ........................................................... 17
3.4.7 Caso Uso Obtener Indicaciones Ruta .................................................................. 19
3.4.8 Caso Uso Obtener Localización............................................................................ 20
3.4.9 Caso Uso Mostrar POIs ............................................................................................ 21
3.4.10 Caso Uso Buscar POIs ........................................................................................... 22
3.4.11 Caso Uso Selección de Puntos para Ruta ......................................................... 23
3.4.12 Caso Uso Calcular Ruta........................................................................................ 25
3.4.13 Caso Uso Visualizar Mapas................................................................................... 26
3.4.14 Caso Uso Detener GPS ......................................................................................... 27
3.4.15 Caso Uso Centrar mapa ...................................................................................... 28
4.
ARQUITECTURA DE LA APLICACIÓN ................................................................................ 29
4.0 INTRODUCCIÓN ......................................................................................................................... 29
4.1 DIAGRAMA DE BLOQUES DE LA ARQUITECTURA ............................................................................ 29
4.2 DESCRIPCIÓN DE BLOQUES DE LA ARQUITECTURA......................................................................... 30
5.
TECNOLOGÍA PARA EL DESARROLLO DE APLICACIONES EN DISPOSITIVOS MÓVILES 32
5.1 INTRODUCCIÓN ......................................................................................................................... 32
5.2 J2ME ....................................................................................................................................... 32
5.2.1 Arquitectura de J2ME ............................................................................................. 32
5.2.2 Configuración.......................................................................................................... 33
5.2.2.1 CDC ....................................................................................................................... 34
5.2.2.2 CLDC...................................................................................................................... 34
5.2.2.3 Diferencias entre CLDC 1.0 y CLDC 1.1 ...........................................................................35
5.2.3 Perfil........................................................................................................................... 36
5.2.3.1 Mobile Information Device Profile.....................................................................................36
5.2.3.2 Características .....................................................................................................................37
212
5.2.3.3 Desarrollo con MIDP ............................................................................................................38
5.2.3.4 Diferencias entre MIDP 1.0 y 2.0........................................................................................40
5.2.3.5 Conectividad .......................................................................................................................40
5.2.3.6 Funcionalidad multimedia y de juego ............................................................................41
5.2.3.9 MIDlet y Ciclo de vida de un MIDlet ................................................................................45
5.2.4 Paquetes opcionales.............................................................................................. 46
5.2.5 Máquinas virtuales .................................................................................................. 47
5.3 BUENAS PRÁCTICAS.................................................................................................................... 51
5.3.1 Compatibilidad vs complejidad ........................................................................... 51
5.3.2 A nivel de usuario .................................................................................................... 52
5.3.3 A nivel de rendimiento y eficiencia ...................................................................... 53
5.3.4 A nivel de memoria................................................................................................. 55
5.3.5 A nivel de arquitectura........................................................................................... 55
5.3.6 A nivel de interfaz.................................................................................................... 56
6. DESARROLLO DE INTERFACES DE USUARIO PARA DISPOSITIVOS MÓVILES....................... 57
6.1 INTRODUCCIÓN ......................................................................................................................... 57
6.2 FRAGMENTACIÓN DE DISPOSITIVO. ............................................................................................. 57
6.3 LWUIT (SWING PARA TELÉFONOS MÓVILES)................................................................................. 59
6.3.1 Paradigma de programación de LWUIT .............................................................. 60
6.3.1.1 Formularios, componentes y contenedores...................................................................60
6.3.1.2 Distribuciones (Layouts) ......................................................................................................62
6.3.1.3 Listas y el paradigma MVC: Independizar el modelo de la vista ...............................64
6.3.2 Estilos y temas .......................................................................................................... 66
6.3.3 Componentes personalizados............................................................................... 68
6.3.3.1 CommandEnable ................................................................................................................69
6.3.3.2 TickerList .................................................................................................................................69
6.4 FLUJO DE CONTROL DE LA INTERFAZ DE USUARIO .......................................................................... 70
7. DESARROLLO DE LA APLICACIÓN ........................................................................................ 72
7.0 INTRODUCCIÓN ......................................................................................................................... 72
7.1 CASOS DE USO DE CARTOGRAFÍA ............................................................................................... 72
7.1.1 Diseño de la arquitectura que permite la visualización de mapas ................. 74
7.1.1.1 Servicios WMS-c (Web Map Service – caché) ...............................................................74
7.1.1.2 ¿Qué es un tile? ...................................................................................................................75
7.1.1.3 Diferencia entre un servidor WMS y uno cacheado.....................................................76
7.1.1.4 Arquitecturas de tiles y dispositivos móviles ....................................................................82
7.1.1.5 Operaciones WMS ...............................................................................................................83
7.1.1.5.1 GetCapabilities ............................................................................................................83
7.1.1.5.2 GetMap .........................................................................................................................86
7.1.1.6 Conversión de coordenadas entre sistemas de referencia........................................86
7.1.1.6.1 La clase Math en CLDC 1.1 .......................................................................................87
7.1.1.7 Arquitectura de tiles ............................................................................................................87
7.1.1.7.1 La clase Map, gestión de la información geográfica y proceso de pintado .89
7.1.1.7.2 La clase ViewPort, correspondencia entre coordenadas del mundo real y
píxels ..............................................................................................................................................91
7.1.1.7.3 La clase Layer, el concepto de capa en SIG ........................................................92
7.1.1.7.4 La clase Grid, gestión del mínimo número de tiles................................................94
7.1.1.7.5 La clase Tile, abstracción de una tesela.................................................................97
7.1.1.7.6 La clase Extent .............................................................................................................98
7.1.1.8 Diseño sistema eficiente de gestión de tiles...................................................................99
7.1.1.8.1 La clase ThreadPool, gestión de hilos para operaciones bloqueantes ............99
7.1.1.8.1 Jerarquía de tareas en background .....................................................................102
7.1.1.9 Diseño de cache de teselas............................................................................................103
7.1.1.9.1 Diseño de caché de tiles en disco.........................................................................104
7.1.1.9.2 JSR-75 vs RecordStore ...............................................................................................104
7.1.1.9.3 Almacenamiento en disco ......................................................................................106
7.1.1.9.4 Conversión de coordenadas a tiles.......................................................................106
7.1.1.9.5 Conversión de tiles a quadkeys ..............................................................................108
7.1.1.9.6 Diseño caché de tiles LRU en memoria.................................................................110
213
7.1.1.10 El proceso de pintado ....................................................................................................111
7.1.2 Diseño de los casos de uso de cartografía ....................................................... 113
7.1.2.1 Navegar por el mapa .......................................................................................................113
7.1.2.2 Centrar mapa.....................................................................................................................115
7.2 OBTENER LOCALIZACIÓN Y DETENER GPS ................................................................................. 117
7.2.1 JSR-179 Location API ............................................................................................. 117
7.2.2 Diseño del caso de uso ........................................................................................ 119
7.2.3 Interfaz de usuario del caso de uso.................................................................... 122
7.3 CASOS DE USO DE RUTAS.......................................................................................................... 123
7.3.1 Introducción........................................................................................................... 123
7.3.2 Geometrías ............................................................................................................ 124
7.3.2.1 Point......................................................................................................................................124
7.3.2.2 Multipoint.............................................................................................................................125
7.3.2.3 LineString..............................................................................................................................126
7.3.2.4 MultiLineString .....................................................................................................................126
7.3.2.5 Feature.................................................................................................................................126
7.3.2.6 FeatureCollection ..............................................................................................................127
7.3.3 Definiendo con detalle una ruta......................................................................... 127
7.3.3.1 Tipos de puntos de una ruta............................................................................................128
7.3.3.2 Diagrama de transición de estados ..............................................................................128
7.3.4 Interacción con el servicio de rutas.................................................................... 130
7.3.4.1 Geometrías y atributos......................................................................................................130
7.3.4.2 Servicios web SOAP ...........................................................................................................131
7.3.4.2.1 Ventajas de los servicios Web .................................................................................132
7.3.4.2.2 Razones para crear servicios Web .........................................................................133
7.3.4.3 Intercambio de geometrías.............................................................................................133
7.3.4.3.1 Elección de un formato de intercambio de geometrías: GeoJSON...............133
7.3.5 Diseño de los casos de uso de rutas................................................................... 135
7.3.5.1 Selección de puntos de ruta ...........................................................................................135
7.3.5.1.1 Diseño de la interfaz de usuario de Selección de puntos de ruta ...................137
7.3.5.2 Cálculo de rutas.................................................................................................................139
7.3.5.2.1 Formato GeoJSON de una solicitud ......................................................................139
7.3.5.2.2 Formato GeoJSON de una respuesta....................................................................140
7.3.5.2.3 Actividad para el cálculo de rutas ........................................................................141
7.3.5.3 Anular ruta...........................................................................................................................143
7.3.5.4 Obtener indicaciones de ruta.........................................................................................145
7.4 MOSTRAR, BUSCAR Y CONSULTAR PUNTOS DE INTERÉS ................................................................ 149
7.4.1 Definición de puntos de interés........................................................................... 149
7.4.2 Formato inicial de ficheros de puntos de interés ............................................. 150
7.4.3 Localización de puntos de interés ...................................................................... 152
7.4.3.1 Almacenamiento de puntos de interés ........................................................................152
7.4.3.1.1 Índices espaciales .....................................................................................................152
7.4.3.1.2 Diseño de un índice espacial específico a partir de un Quadtree .................153
7.4.3.1.3 Pre-procesado de puntos de interés .....................................................................156
7.4.3.1.4 Acceso aleatorio a ficheros ....................................................................................158
7.4.3.1.5 Formato de los ficheros generados........................................................................159
7.4.4 Diseño de los casos de uso de puntos de interés ............................................. 159
7.4.4.1 Visualización de puntos de interés .................................................................................162
7.4.4.2 Consulta de información..................................................................................................165
7.4.4.3 Búsqueda de puntos de interés ......................................................................................167
................................................................................................................................................... 168
8. DESPLIEGUE DE LA APLICACIÓN ........................................................................................ 169
8.0 INTRODUCCIÓN ....................................................................................................................... 169
8.1 HERRAMIENTAS ........................................................................................................................ 169
8.2 COMPILACIÓN ........................................................................................................................ 169
8. 3 PREVERIFICACIÓN .................................................................................................................. 169
8.4 EMULACIÓN ............................................................................................................................ 169
8.4.1 Emulación de posicionamiento GPS .................................................................. 170
8.5 OFUSCACIÓN.......................................................................................................................... 171
214
8.6 FIRMA DE LA APLICACIÓN ........................................................................................................ 171
8.7 EMPAQUETADO ....................................................................................................................... 172
9.
MANUAL DE USUARIO ..................................................................................................... 173
9.0 INTRODUCCIÓN ....................................................................................................................... 173
9.1 ARRANQUE DE LA APLICACIÓN................................................................................................. 173
9.4 MENÚ PRINCIPAL ..................................................................................................................... 175
9.4.1 Ruta desde aquí .................................................................................................... 176
9.4.2 Ruta pasando por aquí ........................................................................................ 177
9.4.3 Ruta hasta aquí ..................................................................................................... 178
9.4.4 Obtener ruta .......................................................................................................... 178
9.4.5 Obtener indicaciones........................................................................................... 179
9.4.6 Anular ruta.............................................................................................................. 180
9.4.7 Selección puntos ruta........................................................................................... 180
9.4.7.1 Ruta vacía...........................................................................................................................181
9.4.7.2 Ruta con punto de origen ...............................................................................................182
9.4.7.3 Ruta con punto de destino..............................................................................................182
9.4.7.4 Ruta con punto de paso ..................................................................................................182
9.4.7.5 Ruta con punto de origen y uno o más puntos de paso...........................................183
9.4.7.6 Ruta con punto de origen y punto de destino ............................................................183
9.4.8 Consultar información .......................................................................................... 183
9.4.8.1 Menú contextual de puntos de interés turísticos .........................................................185
9.4.9 Obtener localización ............................................................................................ 186
9.4.10 Buscar POI (Puntos de Interés)........................................................................... 187
9.4.11 Salir ........................................................................................................................ 188
9.5 TECLAS DE ACCESO RÁPIDO ..................................................................................................... 189
9.6 RESUMEN DE TECLAS PARA BLACKBERRY ................................................................................... 189
9.7 MENÚ CONEXIÓN EN BLACKBERRY........................................................................................... 189
10.
MANUAL DE INSTALACIÓN ........................................................................................ 191
10.0 INTRODUCCIÓN ..................................................................................................................... 191
10.1 INSTALACIÓN SOBRE TELÉFONOS MÓVILES ................................................................................ 191
10.1.1 Instalación OTA (Over-the-air)........................................................................... 191
10.1.2 Instalación manual ............................................................................................. 191
10.1.3 Versión firmada vs Versión sin firmar ................................................................. 191
10.1.4 Posibles problemas con la instalación.............................................................. 192
10. 2 MANUAL DE INSTALACIÓN BLACKBERRY ................................................................................. 194
10.2.1 Versión para BlackBerry...................................................................................... 194
10.2.2 Instalación OTA (Over-the-air)........................................................................... 194
10.2.3 Instalación manual ............................................................................................. 194
10.2.4 Configuración de BlackBerry............................................................................. 194
10.2.5 Posibles problemas con la instalación.............................................................. 194
10.3 MANUAL DE INSTALACIÓN WINDOWS MOBILE......................................................................... 197
10.3.1 Máquina virtual Java .......................................................................................... 197
10.3.2 Instalación de J9 ................................................................................................. 197
10.3.3 Instalación de SIGATEX con J9 .......................................................................... 197
11.
REQUISITOS DEL DISPOSITIVO MÓVIL ........................................................................ 199
11.0 INTRODUCCIÓN ..................................................................................................................... 199
11.1 REQUISITOS MÍNIMOS.............................................................................................................. 199
11.2 REQUISITOS RECOMENDADOS ADICIONALES ............................................................................ 199
11.3 REQUISITOS DE LA MÁQUINA VIRTUAL ...................................................................................... 199
12.
TESTING SOBRE DISPOSITIVOS REALES....................................................................... 200
12.0 INTRODUCCIÓN ..................................................................................................................... 200
12.1 LISTADO DE TELÉFONOS PROBADOS ......................................................................................... 200
12.2 RESUMEN .............................................................................................................................. 201
215
12.3 CONCLUSIONES DEL TESTING .................................................................................................. 202
13.
CONCLUSIONES Y ‘FUTURE WORK’ ............................................................................ 205
A.
ÍNDICE .............................................................................................................................. 212
B.
ÍNDICE DE FIGURAS......................................................................................................... 217
C.
ÍNDICE DE TABLAS ........................................................................................................... 220
D.
BIBLIOGRAFÍA .................................................................................................................. 221
216
B. Índice de figuras
Diagrama 1 - Componentes del sistema de información geográfica de la Junta de
Extremadura.......................................................................................................................................6
Diagrama 2 - Diagrama UML de casos de uso...........................................................................7
Diagrama 3 - Arquitectura de la aplicación............................................................................ 30
Diagrama 4 - Tecnologías JAVA ................................................................................................. 33
Diagrama 5 - J2ME = CLDC + MIDP + paquetes opcionales ............................................... 37
Diagrama 6 - Arquitectura de aplicaciones para dispositivos móviles .............................. 39
Diagrama 7 - Diagrama jerarquía de interfaces de conectividad en J2ME..................... 41
Diagrama 8 - Ciclo de vida de un MIDlet ................................................................................. 46
Diagrama 9 - J2ME vs J2SE ........................................................................................................... 47
Diagrama 10 - Relación entre compatibilidad y complejidad en el desarrollo con J2ME
........................................................................................................................................................... 52
Diagrama 11 - Bloque interfaz usuario móvil ............................................................................ 57
Diagrama 12 - Diagrama de componentes LWUIT ................................................................. 60
Diagrama 13 - Formulario LWUIT.................................................................................................. 61
Diagrama 14 - Formulario + Labels
Diagrama 15 - Checkbox + RadioButton. 61
Diagrama 16 - BorderLayout........................................................................................................ 62
Diagrama 17 - BoxLayout horizontal
Diagrama 18 - BoxLayout vertical .......... 63
Diagrama 19 - FlowLayout ........................................................................................................... 63
Diagrama 20 - GridLayout 2x2..................................................................................................... 64
Diagrama 21 - DefaultListCellRenderer .................................................................................... 65
Diagrama 22 - LisCellRenderer complejo.................................................................................. 66
Diagrama 23 - Distribución de un componente..................................................................... 67
Diagrama 25 - Ejemplo theme 2 ...................... 68
Diagrama 26 - Editor de recursos de LWUIT .............................................................................. 68
Diagrama 27 - Clase UML CommandEnable ........................................................................... 69
Diagrama 28 - Diagrama de clases de Listas tipo marquesina............................................ 70
Diagrama 29 - Diagrama de flujo de interfaz de usuario ...................................................... 71
Diagrama 30 - Componente mapa en la arquitectura......................................................... 72
Diagrama 31 - Componentes para visualizar mapas en la arquitectura........................... 74
Diagrama 32 - Origen de coordenadas de tiles en Google Maps ..................................... 76
Diagrama 33 - Numeración de tiles en Google Maps ........................................................... 76
Diagrama 34 - La Tierra como una esfera y relación latitud-longitud ................................ 78
Diagrama 35 - La Tierra en un plano según la proyección de Mercator........................... 78
Diagrama 36 - Pirámida de tiles .................................................................................................. 80
Diagrama 37 - Relación entre número de tiles y niveles de zoom ...................................... 80
Diagrama 38 - Origen de coordenadas de tiles según la recomendación TMS.............. 82
Diagrama 39 - Parámetros de un tile ......................................................................................... 85
Diagrama 40 - Diagrama de clases de arquitectura de tiles ............................................... 88
Diagrama 41 - Clase UML Map ................................................................................................... 91
Diagrama 42 - Clase UML Viewport ........................................................................................... 92
Diagrama 43 - Diagrama de clases de capa.......................................................................... 94
Diagrama 44 - Clase UML Grid .................................................................................................... 96
Diagrama 45 - Ejemplo de Grid para un tamaño de pantalla de 240x320 ....................... 96
Diagrama 46 - Diagrama de clases de teselas........................................................................ 97
Diagrama 47 - Clase UML Extent................................................................................................. 99
Diagrama 48 - Multithreading en la arquitectura ................................................................... 99
Diagrama 49 - Clase UML ThreadPool ..................................................................................... 100
Diagrama 50 - Diagrama UML de jerarquía de tareas......................................................... 102
Diagrama 51 - Diagrama de niveles de cache..................................................................... 103
Diagrama 52 - Diagrama de actividad de obtener tile ...................................................... 104
Diagrama 53 - Diagrama de origen de coordenadas según la recomendación TMS. 107
Diagrama 54 - Estructura de directorios de caché ineficiente .......................................... 108
217
Diagrama 55 - Diagrama de correspondencia entre quadkeys ....................................... 108
Diagrama 56 - Estructura de directorios de caché eficiente ............................................. 109
Diagrama 57 - Clases implicadas en el proceso de pintado del mapa .......................... 112
Diagrama 58 - Diagrama de secuencia de navegación de mapa – parte 1................ 113
Diagrama 59 - Diagrama de secuencia de navegación de mapa – parte 2................ 114
Diagrama 60 - Diagrama de secuencia de centrar mapa con cambio de zoom ....... 115
Diagrama 61 - Diagrama de secuencia de centrar mapa sin cambio de zoom.......... 116
Diagrama 62 - Localización GPS en la arquitectura............................................................. 117
Diagrama 63 - Diagrama de clases del paquete gps ......................................................... 120
Diagrama 64 - Diagrama de transición de estados de la clase LocationData.............. 121
Diagrama 65 - Componentes de rutas en la arquitectura.................................................. 123
Diagrama 66 - Interfaz UML IGeometry ................................................................................... 124
Diagrama 67 - Clase UML Point................................................................................................. 125
Diagrama 68 - Clase UML MultiPoint ........................................................................................ 126
Diagrama 69 - Clase UML LineString......................................................................................... 126
Diagrama 70 - Clase UML MultiLineString ................................................................................ 126
Diagrama 71 - Diagrama de clases del modelo de geometrías ....................................... 127
Diagrama 72 - Diagrama de transición de estados de una ruta....................................... 129
Diagrama 73 - Componente HTTP/Web service en la arquitectura.................................. 132
Diagrama 74 - Componentes de rutas en la arquitectura.................................................. 134
Diagrama 75 - Diagrama de clases de rutas ......................................................................... 136
Diagrama 76 - Diagrama de clases de la estructura MVC para puntos de ruta ........... 138
Diagrama 77 - Layout de formulario de selección de puntos de ruta ............................. 139
Diagrama 78 - Ejemplo de cadena GeoJSON de solicitud de ruta.................................. 140
Diagrama 79 - Ejemplo de cadena GeoJSON de respuesta del servidor de rutas ....... 140
Diagrama 80 - Intercambio de geometrías entre cliente-servidor .................................... 142
Diagrama 81 - Diagrama de actividad de cálculo de rutas.............................................. 143
Diagrama 82 - Clase UML RouteProperties ............................................................................. 145
Diagrama 83 - Clase UML TurnUtil ............................................................................................. 146
Diagrama 84 - Diagrama de clases de la estructura MVC para representar las
direcciones de una ruta ............................................................................................................. 147
Diagrama 85 - Layout de formulario de obtener direcciones de ruta ............................. 148
Diagrama 86 - Componentes de puntos de interés en la arquitectura........................... 149
Diagrama 87 - QuadTree de puntos ........................................................................................ 154
Diagrama 88 - PR-QuadTree...................................................................................................... 154
Diagrama 89 - Bucket PR-QuadTree ........................................................................................ 155
Diagrama 90 - Diagrama de clases de Quadtree complejo para pre-procesado de
puntos de interés.......................................................................................................................... 157
Diagrama 91 - Representación de un Quadtree con un árbol y sobre un plano.......... 157
Diagrama 92 - Diagrama de clases jerarquía Point – POI ................................................... 160
Diagrama 93 - Clase UML LayerVect ....................................................................................... 161
Diagrama 94 - Diagrama de clases de jerarquía de tareas ............................................... 162
Diagrama 95 - Diagrama de clases de Quadtree simplificado para la aplicación móvil
......................................................................................................................................................... 163
Diagrama 96 - Diagrama de secuencia de pan en la capa vectorial ............................ 164
Diagrama 97 - Layout de formulario consulta de información .......................................... 166
Diagrama 98 - Diagrama de clases de la estructura MVC para puntos de interés ...... 168
Diagrama 99 - Layout de formulario de búsqueda de puntos de interés ....................... 168
Diagrama 100 - Simulación de localización GPS en Sprint SDK.......................................... 171
Diagrama 101 - Pantalla inicial de la aplicación .................................................................. 173
Diagrama 102 - Pantalla de advertencia de consumo de ancho de banda............... 174
Diagrama 103 - Pantalla del mapa.......................................................................................... 174
Diagrama 104 - Teclas de navegación ................................................................................... 175
Diagrama 105 - Menú principal ................................................................................................ 176
Diagrama 106 - Tecla menú ...................................................................................................... 176
Diagrama 107 - Punto de origen............................................................................................... 177
Diagrama 108 - Punto de origen y dos puntos de paso sobre el mapa .......................... 177
218
Diagrama 109 - Ruta calculada sobre el mapa.................................................................... 178
Diagrama 110 - Selección de tipo de ruta ............................................................................. 179
Diagrama 111 - Ruta calculada ............................................................................................... 179
Diagrama 112 - Formulario obtener direcciones de ruta .................................................... 180
Diagrama 113 - Formulario selección de puntos de ruta .................................................... 181
Diagrama 114 - Menú contextual de selección de puntos de ruta.................................. 181
Diagrama 115 - Puntos de interés sobre el mapa ................................................................. 184
Diagrama 116 - Cargando información.................................................................................. 184
Diagrama 117 - Elementos encontrados................................................................................. 184
Diagrama 118 - Formulario consultar información ................................................................ 185
Diagrama 119 - Menú contextual de consulta de información......................................... 185
Diagrama 120 - Selección de categoría de búsqueda de puntos de interés................ 187
Diagrama 121 - Formulario Buscar POI .................................................................................... 188
Diagrama 122 - Formulario conexión para BlackBerry ......................................................... 190
Diagrama 123 - Formulario GetCapabilities ........................................................................... 208
Diagrama 124 - Capa PNOA ..................................................................................................... 209
Diagrama 125 - Capas preconfiguradas ................................................................................ 209
Diagrama 126 - Capa OSM ....................................................................................................... 209
Diagrama 127 - NameFinder en gvSIG phone....................................................................... 210
219
C. Índice de tablas
Tabla 1 - Número de zoom vs número de tiles......................................................................... 81
Tabla 2 - Comparación OSM - WMS-c ....................................................................................... 81
Tabla 3 - Parámetros de GetCapabilities.................................................................................. 83
Tabla 4 - Parámetros GetMap ..................................................................................................... 86
Tabla 5 - Comparación RMS vs JSR-75..................................................................................... 106
Tabla 6 - Tabla de permisos de JSR-179................................................................................... 119
Tabla 7 - Tabla de posibilidades de puntos de ruta ............................................................. 130
Tabla 8 - Categorías de puntos de interés.............................................................................. 151
Tabla 9 - Testing de teléfonos .................................................................................................... 201
220
D. Bibliografía
The JavaME Frequently Asked Questions List
http://bellsouthpwp.net/m/c/mcpierce/javamefaq.html#provisioning_nokia_handsets
Introduction to OTA Application Provisioning
http://developers.sun.com/mobility/midp/articles/ota/
WMS Tile Caching
http://wiki.osgeo.org/wiki/WMS_Tile_Caching#Calculating_Valid_Tile_Extents_for_a_Giv
en_Request
Techniques for displaying and caching tiled map data on constrained-resource
services
http://www.patentstorm.us/patents/7315259/fulltext.html
OpenLayers: Free Maps for the Web
http://openlayers.org/
Targeting GPS - Integrating J2ME, GPS, and the Wireless Web
http://java.sys-con.com/node/36895
Java ME UI Frameworks
http://wiki.forum.nokia.com/index.php/Java_ME_UI_Frameworks
Shai's Java & LWUIT Blog
http://lwuit.blogspot.com/
LWUIT Tutorial
https://lwuit.dev.java.net/nonav/tutorial/forms.html
LWUIT Home
https://lwuit.dev.java.net/
J2ME Polish Documentation
http://www.j2mepolish.org/cms/leftsection/documentation.html
Hilos Java
http://www.scribd.com/doc/2875431/hilos-Java
J2ME Game Optimization Secrets
http://www.developer.com/java/j2me/article.php/10934_2234631_2
How to abort or cancel a http connection
http://discussion.forum.nokia.com/forum/showthread.php?s=&threadid=35252
ThreadPool test
http://www.java2s.com/Code/Java/Threads/ThreadPoolTest.htm
J2ME: Lo que no cuentan los libros ni los tutoriales o Cosas que nunca te dije
http://weblog.linkingpaths.com/2005/12/19/j2me-lo-que-no-cuentan-los-libros-ni-lostutoriales-o-cosas-que-nunca-te-dije/
221
J2ME + HttpConnection
http://devoc.wordpress.com/2007/09/12/j2me-httpconnection/
Basic Network Programming in J2ME MIDP
http://www.informit.com/articles/article.aspx?p=131116&seqNum=4
Improving Swing Performance
http://billharlan.com/pub/papers/Improving_Swing_Performance.html
Desarrollo de un mecanismo de serialización en J2ME
Celeste Campo Vázquez, Rosa Ma García Rioja, Guillermo Diez-Andino Sancho
Departamento. Ingeniería Telemática - Universidad Carlos III de Madrid
Avda. Universidad 30 Leganés (Madrid), España
fceleste, rgrioja, [email protected]
http://www.it.uc3m.es/celeste/papers/Serializacion.pdf
Using JavaScript Object Notation (JSON) in Java ME for Data Interchange
http://java.sun.com/developer/technicalArticles/javame/json-me/
JSON in Java
http://www.json.org/java/
The GeoJSON Format Specification
http://geojson.org/geojson-spec.html
GeoJSON Implementations
http://wiki.geojson.org/Main_Page#Example_Implementations
Implementing a Local Cache to Manage Resources
http://developers.sun.com/mobility/midp/articles/imagecache/
Externalizing Resources - Persisting Images in RMS
http://developers.sun.com/mobility/midp/ttips/imagesinrms/
Accessing a Resource over HTTP
http://developers.sun.com/mobility/midp/ttips/httpgetmethod/
Game Programming Crash Course (for J2ME): MIDlet
http://koderko.dk/J2METutorial/midlet.asp
Sun J2ME Wireless Toolkit
http://www.mobilefish.com/emulators/j2me_wt/j2me_wt_quickguide_22_emulator.html
Octree Search
http://www.codeproject.com/KB/recipes/OctreeSearch.aspx
Overcoming Challenges in Mobile J2ME Development
http://www.informit.com/articles/article.aspx?p=170448
Java Performance Tuning
http://www.javaperformancetuning.com/tips/j2me.shtml#REF22
MIDlet jar signing (a tutorial) Revised
http://www.spindriftpages.net/blog/dave/2006/06/18/midlet-jar-signing-a-tutorialrevised/
222
MIDlet size optimization
http://supremej2me.bambalam.se/guides/size-optimization/
Optimizing for Speed in J2ME :: Extreme Tips for Lightning-Fast MIDlets
http://j2medevcorner.wordpress.com/2007/03/13/optimizing-for-speed-in-j2meextreme-tips-for-lightning-fast-midlets/
J2ME & Gaming
http://www.kiv.zcu.cz/~pesicka/mkz/J2MEGameDevelop.pdf
Tips for better GPS usage
http://europe.nokia.com/get-support-and-software/product-support/nokia-n95/tips-forbetter-gps-usage
Sun Java Wireless Toolkit - Location Demo
http://developers.sun.com/mobility/wtk/demos/wtk-lapi.html
The GDI Coordinate Systems
http://www.functionx.com/visualc/gdi/gdicoord.htm
Bing Maps Tile System
http://msdn.microsoft.com/en-us/library/bb259689.aspx
Open Geospatial Consortium Inc.
Date: 2005-11-22
Reference number of this OGC™ document: OGC 05-008
Version: 1.0.0
Category: OpenGIS® Implementation Specification
Editor: Arliss Whiteside
OpenGIS® Web Services Common Specification
Open Geospatial Consortium Inc.
Date: 2006-03-15
Reference number of this document: OGC® 06-042
Version: 1.3.0
Editor: Jeff de la Beaujardiere
OpenGIS® Web Map Server Implementation Specification
OGC Compatible
Geographical Information Systems
Web Services
Indiana University Computer Science Department,
Bloomington, IN, 47405
Ahmet Sayar, Marlon Pierce and Geoffrey Fox
{ asayar, mpierce, gfc}@cs.indiana.edu
Open GIS Consortium Inc.
Date: 2001-11-27
Reference number of this OpenGIS® project document: OGC 01-068r2
Version: 1.1.1
Status: Revision Proposal
Editor: Jeff de La Beaujardière
Web Map Service Implementation Specification
223
MIDP 2.0: Signed MIDlet Developer's Guide
Version 2.0; October 31st, 2006
Quadtrees - Hierarchical Grids
By Sariel Har-Peled, August 24, 2008¬
The Skip Quadtree:
A Simple Dynamic Data Structure
For Multidimensional Data
David Eppstein, Michael T. Goodrich, and Jonathan Z. Sun
Univ. of California, Irvine
Donald Bren School of Information and Computer Sciences
Implementing a map based simulator for the location API for
J2ME
D. PARSONS
Institute of Information & Mathematical Sciences
Massey University at Albany, Auckland, New Zealand
MIDP: FileConnection API Developer's Guide
Version 2.0; October 31st, 2006
Over The Air User Initiated
Provisioning Recommended Practice
for the Mobile Information Device Profile
Version 1.0
May 7, 2001
Please send comments to [email protected]
Real-Life Use of JSR 179:
Location API for the
J2ME™ Platform
Ryan Wick
Zane Lyon
Sean Sheedy
NEXTEL
http://developer.nextel.com
Historia y estado actual del futuro estándar
Web Map Tiling Service del OGC
Joan Masó1, Núria Julià1 y Xavier Pons2.
1Centre de Recerca Ecològica i Aplicacions Forestals (CREAF)
Universitat Autònoma de Barcelona (UAB)
Facultad de Ciencias, 08193 Bellaterra (Barcelona)
[email protected], [email protected]
2Departament de Geografia
Universitat Autònoma de Barcelona (UAB)
08193 Bellaterra (Barcelona)
[email protected]
Mobile Information
Device Profile
for Java™ 2 Micro Edition
Version 2.0
JSR 118 Expert Group
[email protected]
Java Community
224
What’s in MIDP 2.0: A Guide for Java™
Version 1.0; September 15, 2003
225

Sigatex Móvil - SIG para dispositivos móviles - Index of

Transcripción

Documentos relacionados

diagrama de mollier del vapor de agua