SIGATEX Móvil. SIG para dispositivos móviles. de la Junta de Extremadura

Transcripción

1 SIGATEX Móvil SIG para dispositivos móviles de la Junta de Extremadura Alumno: Alberto Romeu Carrasco Director: Miguel Montesinos Prodevelop Tutor: Vicente Pelechano DSIC (UPV)

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 3.4 Descripción de casos de uso 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

10 3.4.2 Caso Uso Consultar Información Descripción El turista, desde su aplicación consulta información alfanumérica sobre un elemento mostrado en pantalla. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. El turista debe encontrarse en un nivel de zoom sobre el mapa, en el cual se muestren puntos de interés. Post-condiciones Se muestra una lista con los atributos alfanuméricos del (los) elemento(s) cercano(s) al centro de la pantalla. Además se mostrará un icono representativo de la categoría correspondiente a cada punto de interés. Escenario principal El turista, desde la aplicación, accede al menú de consultar información. La aplicación comprueba si se encuentra en un nivel de zoom en el que se pueda consultar información y recupera los datos de los puntos de interés cercanos al centro (a un radio de 50 píxeles). Una vez realizada la búsqueda, la aplicación muestra un mensaje indicando el número de elementos encontrados y a continuación una ventana con una lista de todos aquellos elementos encontrados mostrando un icono representativo de la categoría, la descripción del punto de interés y la distancia al centro. El listado deberá aparecer ordenado por distancia al centro de la pantalla, de más cercano a menos cercano y contendrá como máximo los 50 primeros elementos encontrados. Excepciones Si el usuario se encuentra en un nivel de zoom en el que no aparecen puntos de interés se le informará de que no se ha encontrado información. Si el resultado de la petición de información es nulo (no se ha encontrado ningún elemento a una distancia pixel solicitado), se 10

11 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

12 3.4.3 Caso Uso Eliminar Punto de Paso de Ruta Descripción El turista, desde su aplicación elimina un punto de paso de ruta. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. Se deben haber establecido previamente puntos de paso de ruta. El usuario había dado la orden de eliminar un punto de paso en el caso de uso Selección de Puntos para Ruta Post-condiciones Se actualiza el conjunto de puntos de paso y el estado de la ruta si se ve afectado. No se calcula una nueva ruta. Se hará cuando el usuario expresamente así lo indique. Escenario principal Tras recibir la orden de eliminar un punto de paso, se borra del conjunto de puntos de paso y se actualiza el estado de la ruta si ha cambiado. 12

13 3.4.4 Caso Uso Establecer Punto de Paso de Ruta Descripción El turista, desde su aplicación define un punto de paso intermedio de una ruta. Por punto intermedio se entiende aquél que no es necesariamente el origen o fin de la ruta. Utilizado para el cálculo de ruta pasando por N puntos. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. Post-condiciones Se dispone de un punto de paso de ruta en memoria, y se actualiza el estado interno de la ruta. Escenario principal El turista, desde la aplicación, selecciona la opción de menú Ruta pasando por aquí y la aplicación obtiene las coordenadas locales (X, Y) y muestra un icono representativo de punto de paso sobre el centro de la pantalla. No se llama a Selección de Puntos para Ruta. Lo deberá hacer posteriormente de forma manual el usuario cuando haya finalizado de establecer todos los puntos de paso. Escenario alternativo 1 El usuario, estando consultando un elemento con X-Y, como una ficha de información de un POI (Punto de Interés), selecciona la opción de menú Establecer como paso de ruta. La aplicación realiza el mismo proceso que en el caso de seleccionar el punto central de la pantalla. Escenario alternativo 2 El usuario, estando en la ventana de Seleccionar Puntos para Ruta, había seleccionado la opción Añadir punto de paso. La aplicación le muestra el mapa habilitando una opción del teléfono Seleccionar, para que el usuario navegue (zooms, pans) y ejecute dicha opción seleccionándose el punto central de la pantalla (ojo, debe haber icono en el centro). 13

14 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

15 3.4.5 Caso Uso Establecer Punto Fin de Ruta Descripción El turista, desde su aplicación define el punto de destino (fin) de una ruta. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. Post-condiciones Se dispone de un punto destino de ruta en memoria, y se actualiza el estado interno de la ruta. Si ya se disponía de Punto de Partida, el resultado de actualizar el estado interno de la ruta será realizar una llamada a Selección de Tipo de Ruta. Escenario principal El turista, desde la aplicación, selecciona la opción de menú Ruta hasta aquí y la aplicación obtiene las coordenadas locales (X, Y) y muestra un icono representativo de punto de destino sobre el centro de la pantalla. Si ya se había establecido previamente un punto de partida (tanto si no había punto de destino, como si ya lo había -y por tanto ruta calculada- ), se calcula automáticamente la ruta llamando al caso de uso de Selección de Tipo de Ruta. Escenario alternativo 1 El usuario, estando consultando un elemento con X-Y, como una ficha de información de un POI (Punto de Interés), selecciona la opción de menú Establecer como fin de ruta. La aplicación realiza el mismo proceso que en el caso de seleccionar el punto central de la pantalla. Escenario alternativo 2 El usuario, estando en la ventana de Seleccionar Puntos para Ruta (ver caso de uso Selección de Puntos para Ruta), había seleccionado la opción Seleccionar Ubicación referida a Punto de Destino. La 15

16 aplicación le muestra el mapa habilitando una opción del teléfono Seleccionar, para que el usuario navegue (zooms, pans) y ejecute dicha opción seleccionándose el punto central de la pantalla (ojo, debe haber icono en el centro). Una vez seleccionado el punto, se debe mostrar un icono representativo de punto de destino sobre el centro de la pantalla, y automáticamente se volverá a abrir la ventana de Seleccionar Puntos para Ruta, con el Punto de Destino ya seleccionado. 16

17 3.4.6 Caso Uso Establecer Punto Inicio de Ruta Descripción El turista, desde su aplicación define el punto de partida (inicio) de una ruta. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. Post-condiciones Se dispone de un punto origen de ruta en memoria, y se actualiza el estado interno de la ruta. Si ya se disponía de Punto de Destino, el resultado de actualizar el estado interno de la ruta será realizar una llamada a Selección de Tipo de Ruta. Escenario principal El turista, desde la aplicación, selecciona la opción de menú Ruta desde aquí y la aplicación obtiene las coordenadas locales (X, Y) y muestra un icono representativo de punto de inicio sobre el centro de la pantalla. Si ya se había establecido previamente un punto de destino (tanto si no había punto de partida, como si ya lo había -y por tanto ruta calculada- ), se calcula automáticamente la ruta llamando al caso de uso de Selección de Tipo de Ruta. Escenario alternativo 1 El usuario, estando consultando un elemento con X-Y, como una ficha de información de un POI (Punto de Interés), selecciona la opción de menú Establecer como inicio de ruta. La aplicación realiza el mismo proceso que en el caso de seleccionar el punto central de la pantalla. Escenario alternativo 2 El usuario, estando en la ventana de Seleccionar Puntos para Ruta (ver caso de uso Selección de Puntos para Ruta), había seleccionado la opción Seleccionar Ubicación referida a Punto de Partida. La aplicación 17

18 le muestra el mapa habilitando una opción del teléfono Seleccionar, para que el usuario navegue (zooms, pans) y ejecute dicha opción seleccionándose el punto central de la pantalla (ojo, debe haber icono en el centro). Una vez seleccionado el punto, se debe mostrar un icono representativo de punto de inicio sobre el centro de la pantalla, y automáticamente se volverá a abrir la ventana de Seleccionar Puntos para Ruta, con el Punto de Partida ya seleccionado. En este escenario se deberá controlar que no se produzca re-centrado por nuevas posiciones del GPS hasta que el usuario seleccione la posición. 18

19 3.4.7 Caso Uso Obtener Indicaciones Ruta Descripción El turista, desde su aplicación solicita las instrucciones de una ruta ya obtenida. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. Previamente se ha solicitado un cálculo de ruta (entre 2 puntos o pasando por N puntos), con resultado positivo. Como resultado de ese cálculo, el servidor ha devuelto un identificador de la ruta. Post-condiciones Se muestran al usuario las instrucciones de la ruta en pantalla. Escenario principal El turista, tras haber calculado un ruta (ver caso de uso Selección de Puntos para Ruta), y verla gráficamente en pantalla, con el menú activa la opción de Obtener indicaciones. La aplicación obtendrá las indicaciones de la ruta a partir de los atributos de las geometrías de la ruta que se obtienen al solicitar la ruta al servidor. Una vez calculadas las indicaciones, se mostrará una ventana indicando el origen y destino de la ruta, los pasos intermedios y su coste. Excepciones La ruta ha sido anulada previamente. En este caso, la opción de menú debería estar desactivada, y no se debería permitir entrar en este caso de uso 19

20 3.4.8 Caso Uso Obtener Localización Descripción El turista, con su teléfono móvil obtiene su posición actual utilizando el receptor GPS interno del teléfono. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación en funcionamiento en su teléfono móvil y un receptor interno GPS. Post-condiciones Se centra el mapa en la localización del usuario. Escenario principal El turista tiene la aplicación abierta. Activa desde un menú la opción de Obtener localización. La aplicación se conecta al GPS, indica el estado de la conexión mediante un icono, y cuando se ha fijado posición (se tienen coordenadas), se re-centra el mapa y, en su caso, se solicitan los mapas necesarios de fondo al servidor. La localización se muestra mediante un símbolo (tipo cruz o similar), y se mantiene activa hasta que el usuario desactiva la conexión con el GPS. De forma periódica, la posición se va actualizando, realizando desplazamientos sobre el mapa con las sucesivas posiciones. Excepciones Si el teléfono no cuenta con un receptor GPS interno o no es posible establecer la conexión por motivos de hardware, mostrar un mensaje al usuario advirtiendo de tal situación. 20

21 3.4.9 Caso Uso Mostrar POIs Descripción El turista, desde su aplicación al navegar sobre el mapa puede visualizar los iconos representativos de las categorías de los puntos de interés sobre su posición real sobre el mapa. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación en funcionamiento en su teléfono móvil. Post-condiciones Se muestran en el mapa iconos representativos de cada categoría de puntos de interés. Escenario principal El turista tiene la aplicación abierta. Al hacer zoom sobre el mapa o navegar desplazándolo, se encuentra en el nivel máximo o el nivel anterior al máximo. La aplicación realiza una búsqueda de puntos de interés contenidos en la extensión de la pantalla. Si encuentra puntos de interés los pinta en la pantalla. 21

22 Caso Uso Buscar POIs Descripción El turista, desde su aplicación solicita buscar puntos de interés (POIs - Points Of Interest-) cercanos a la posición central del mapa. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación en funcionamiento en su teléfono móvil. Post-condiciones Se muestran un listado con los 50 primeros puntos de interés encontrados. Escenario principal El turista tiene la aplicación abierta y solicita buscar puntos de interés. Se le muestra una pantalla donde puede seleccionar la categoría por la que quiere filtrar o todas y una caja de texto donde introducir la descripción a buscar. En caso de dejarla en blanco se buscará cualquier descripción. Los puntos de interés encontrados se mostrarán en un listado. Excepciones Si no se encuentran puntos de interés que cumplan con el filtro se mostrará un mensaje informando al usuario. 22

23 Caso Uso Selección de Puntos para Ruta Descripción El turista, desde su aplicación solicita la opción de menú selección puntos de ruta. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. Post-condiciones Se muestra una ventana con todos los puntos seleccionados para formar parte de una ruta. Escenario principal Al turista se le muestra automáticamente una pantalla con una lista de 3 elementos: Punto de partida/inicio. Si ha marcado previamente el punto de inicio, aparece un icono representativo y las coordenadas del punto. Si no, aparece un botón con un texto para que el usuario seleccione el punto de inicio. Puntos de paso. Si ha definido uno o más puntos de paso, se le muestra una lista donde para cada punto de paso marcado le aparece un icono representativo y las coordenadas de cada punto. Punto de destino/fin. Si ha marcado previamente el punto de destino, aparece un icono representativo y las coordenadas del punto. Sino, aparece un botón con un texto para que el usuario seleccione el punto de destino. Esta pantalla debe contener opciones de menú para añadir/eliminar puntos de ruta, de acuerdo a los casos de uso relacionados con rutas. Es decir, si por ejemplo el punto de partida está vacío, se le muestra al usuario el texto Selecccionar ubicación, siendo éste un texto seleccionable (con puntero o botón central). Al ordenar (seleccionar el texto) Seleccionar ubicación se llamará al caso de uso Establecer Punto Inicio de Ruta o Establecer Punto Fin de Ruta, según se haya seleccionado en punto de partida o de destino. 23

24 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

25 Caso Uso Calcular Ruta Descripción El turista, desde su aplicación solicita calcular ruta. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación instalada y en funcionamiento. Previamente se han seleccionado un número suficiente de puntos para poder calcular una ruta. Post-condiciones Se obtiene del servidor la ruta solicitada y se pinta en pantalla. Escenario principal El turista, desde la aplicación, marca el punto de inicio y al menos otro punto de ruta. La aplicación muestra una pantalla para que el usuario seleccione el tipo de ruta: A pie. En coche. A continuación la aplicación realizará la solicitud de cálculo de rutas al servidor, pasando los puntos y el tipo de ruta, y le indicará la usuario que la solicitud está en curso (mediante un icono animado, un mensaje...). Excepciones Si el usuario no ha seleccionado al menos el punto de inicio y un punto más, no se permitirá el cálculo de ruta. Si pasado un tiempo (time-out) no se recibe respuesta del servidor, se informará al usuario. Si se recibe respuesta del servidor indicando que la respuesta no ha podido ser calculada, se informará al usuario de ello. 25

26 Caso Uso Visualizar Mapas Descripción El turista, con su teléfono móvil puede navegar por la cartografía, puntos de interés y consultando información alfanumérica asociada. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación descargada e instalada en su teléfono móvil, así como acceso a Internet (GPRS/UMTS) para cargar mapas y datos. Post-condiciones Se visualizan mapas y fichas de datos. Escenario principal El turista abre la aplicación. Se le muestra un mapa de Extremadura con cartografía base. El usuario puede realizar navegación gráfica sobre el mapa haciendo zoom más, menos, desplazamientos (pan). 26

27 Caso Uso Detener GPS Descripción El turista, con su teléfono móvil solicita detener el re-centrado del mapa desde la localización del GPS. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación descargada e instalada en su teléfono móvil, debe haber solicitado Obtener localización GPS. Post-condiciones El mapa deja de obtener el centro desde el GPS. Escenario principal El turista desde la opción de menú Detener GPS solicita detener el recentrado desde el GPS. Escenario alternativo 1 El turista desde la pantalla Selección de puntos de ruta, solicita establecer punto de inicio, punto de destino o punto intermedio. La aplicación automáticamente detiene el GPS, para que el usuario pueda navegar por el mapa libremente y seleccionar el punto que desee. Escenario alternativo 2 El turista selecciona la opción Centrar en mapa sobre cualquier entidad para que el mapa se centre sobre ella. La aplicación detendrá el re-centrado GPS. Escenario alternativo 3 Mientras el usuario está en el menú principal de la aplicación o en cualquier formulario que no sea el del mapa, la aplicación detendrá el GPS. 27

28 Caso Uso Centrar mapa Descripción El turista, con su teléfono móvil puede solicitar centrar el mapa sobre cualquier entidad de un formulario sobre la que pueda colocar el foco y que disponga de coordenadas. Actores Turista usuario de la aplicación móvil. Condiciones Precondiciones El turista debe tener la aplicación descargada e instalada en su teléfono móvil y encontrarse en un formulario con entidades con coordenadas. Post-condiciones El mapa se re-centra sobre la entidad seleccionada. Escenario principal El turista coloca el foco sobre una entidad con coordenadas (por ejemplo, un punto de una ruta o un tramo de una ruta), solicita centrar el mapa y se muestra la pantalla del mapa con el centro en la entidad seleccionada. 28

29 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

30 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

31 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

32 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 Arquitectura de J2ME La arquitectura Java TM 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 J2EE TM, que está orientado a entornos corporativos o J2SE TM, 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

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

34 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) 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 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: 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

35 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 Implementation TM : 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 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

36 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) 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 PersonalJava TM 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

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

38 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 o aplicación. 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

39 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

40 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 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 Conectividad Se definen seis interfaces básicos de conectividad: 40

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

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

43 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: o o 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. Descriptor de aplicación: 43

44 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

45 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

46 o Justo antes de llamar al método MIDlet.startApp(). Destruido (Destroyed): El MIDlet ha liberado todos sus recursos y terminado. A este estado se entra: o Cuando se termina el método MIDlet.destroyApp() excepto si el argumento incondicional tiene el valor false y se lanza una excepción MIDletStateChangeException. El método destroyapp() liberará los recursos que se estén empleando y dejará la instancia en una situación que permita que se libere mediante le recolector de basura. o Cuando el método MIDlet.notifyDestroyed() responde correctamente a la aplicación. El MIDlet debe haber ejecutado las operaciones equivalentes al método MIDlet.destroyApp() antes de invocar a MIDlet.notifyDestroyed(). o En este estado sólo se entrará una vez. Diagrama 8 - Ciclo de vida de un MIDlet 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

47 bases de datos. Dado que son modulares, los fabricantes de dispositivos pueden incorporarlos según los vayan necesitando para mejorar las características soportadas 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

48 o microedition.configuration Nombre y versión de configuración soportada, con valor predeterminado "CLDC- 1.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.*: 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

49 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

50 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

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

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

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

54 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

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

56 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

57 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

58 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

59 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

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

61 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 Diagrama 15 - Checkbox + RadioButton 61

62 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

63 Diagrama 17 - BoxLayout horizontal vertical Diagrama 18 - BoxLayout 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

64 Diagrama 20 - GridLayout 2x2 de la vista Listas y el paradigma MVC: Independizar el modelo 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

65 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

66 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 ) 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 . Además el elemento seleccionado es dibujado con una imagen a la derecha y un fondo de otro color 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

67 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

68 Diagrama 24 - Ejemplo theme 1 Diagrama 25 - Ejemplo theme 2 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 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

69 seleccionables por el usuario y por otra parte, la necesidad de representar listas con contenido animable CommandEnable La clase CommandEnable extiende la clase Command de LWUIT y añade la posibilidad de que el comando esté habilitado o no TickerList Diagrama 27 - Clase UML CommandEnable 69

70 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

71 Diagrama 29 - Diagrama de flujo de interfaz de usuario 71

72 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

73 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

74 de mapas Diseño de la arquitectura que permite la visualización Diagrama 31 - Componentes para visualizar mapas en la arquitectura 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

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

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

77 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

78 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

79 Width: 256 px Height: 256 px Format: image/png SRS: EPSG:4326 BoundingBox: , Resolutions: , En el nivel más alto de resolución hay dos tiles. Global spherical Mercator: La proyección de Mercator. Los parámetros son: Width: 256 px Height: 256 px Format: image/png SRS: OSGEO:41001 BoundingBox: Resolutions: 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

80 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

81 Nivel de zoom Número de tiles 0 1 tile cubre el mundo entero 1 2x2 tiles 2 4x4 tiles N 2 n x2 n 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) Subsistema servidor de mapas (WMS TMS) No tiene un mecanismo de Tiene un mecanismo de descubrición de servicios. descubrimiento de servicios (GetCapabilities y a través de su URL) No tiene un mecanismo estándar de petición de mapas. Tiene un mecanismo estándar de petición de mapas (GetMap) Utiliza la proyección de Mercator. Puede utilizar cualquier proyección. Normalmente sirven una única capa correspondiente al mundo Pueden servir capas de cualquier temática. 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

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

83 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 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 GetCapabilities Los parámetros de una petición GetCapabilities son los siguientes: Un ejemplo de petición sería: Tabla 3 - Parámetros de GetCapabilities 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

84 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: y a la capa que nos interesa para la aplicación móvil desde: 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: 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

85 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: 0.jpeg En nuestro caso, utilizaremos la operación GetMap. 85

86 GetMap Tabla 4 - Parámetros GetMap Por ejemplo, la siguiente consulta, devolvería la imagen del Diagrama mage/jpeg&service=wms&version=&request=getmap&styles=&exce PTIONS=&SRS=EPSG:23030&BBOX= , , , &WIDTH=256&HEIGHT=256 referencia Conversión de coordenadas entre sistemas de 86

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

88 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

89 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 La clase Map, gestión de la información geográfica y proceso de pintado 89

90 90

91 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 La clase ViewPort, correspondencia entre coordenadas del mundo real y píxels 91

92 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 La clase Layer, el concepto de capa en SIG 92

93 93

94 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 La clase Grid, gestión del mínimo número de tiles 94

95 95

96 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

97 teselas conforme se navega por el mapa, para ello, se utilizará Multithreading 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

98 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 La clase Extent 98

99 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 Diseño sistema eficiente de gestión de tiles Diagrama 48 - Multithreading en la arquitectura La clase ThreadPool, gestión de hilos para operaciones bloqueantes 99

100 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

101 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

102 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 Jerarquía de tareas en background Diagrama 50 - Diagrama UML de jerarquía de tareas 102

103 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

104 Diagrama 52 - Diagrama de actividad de obtener tile 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 JSR-75 vs RecordStore Actualmente J2ME ofrece dos alternativas para persistir datos en la memoria del teléfono. 104

105 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 opciones de acuerdo a las necesidades de la aplicación: RMS JSR-75 Qué necesitamos? Es el mecanismo Es una librería opcional Sería conveniente un estándar de y es posible que no mecanismo lo más persistencia. todos los teléfonos la expandido posible. implementen. No requiere de ningún Es una librería Sería conveniente no permiso especial tanto restringida por el necesitar de ningún para leer como para sistema de permisos permiso especial. escribir. de J2ME. Por tanto, como mínimo será necesario firmar la aplicación y es posible que, en algunos casos, no sea suficiente. En general, muchos No hay restricción. La aplicación va a 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 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 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

106 almacenados desde fuera de la aplicación. acceder a ellos desde 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 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 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

107 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, double 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 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

108 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: 2 7 X2 7 = y resultaría ineficiente intentar acceder a esos ficheros 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

109 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

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

111 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. Al arrancar la aplicación, la caché está vacía. 2. Antes de cargar un nuevo tile se busca siempre en memoria. 3. Si está, se pone en primera posición. 4. 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é El proceso de pintado El siguiente diagrama muestra las clases involucradas en el proceso de pintado del mapa: 111

112 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

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

114 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

115 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

116 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

117 7.2 Obtener localización y detener GPS Diagrama 62 - Localización GPS en la arquitectura 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

118 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 javax.microedition.location.location Métodos protegidos por el permiso 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

119 javax.microedition.location.landmarkstore.w rite LandmarkStore.addLandmark(), LandmarkStore.deleteLandmark(), LandmarkStore.removeLandmarkFromCate gory(), LandmarkStore.updateLandmark() javax.microedition.location.landmarkstore.c ategory javax.microedition.location.landmarkstore.m anagement LandmarkStore.addCategory(), LandmarkStore.deleteCategory() LandmarkStore.createLandmarkStore(), LandmarkStore.deleteLandmarkStore() Tabla 6 - Tabla de permisos de JSR-179 En nuestro caso, bastará con agregar el permiso javax.microedition.location.location 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

120 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

121 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

122 Estando en el estado parado podemos volver al estado posicionando de tres maneras: 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 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 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

123 7.3 Casos de uso de rutas Diagrama 65 - Componentes de rutas en la arquitectura 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

124 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 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: Point Diagrama 66 - Interfaz UML IGeometry 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

125 Diagrama 67 - Clase UML Point Multipoint Un multipunto es un conjunto de puntos que constituyen una única geometría. 125

126 Diagrama 68 - Clase UML MultiPoint LineString Una línea es una colección de coordenadas x e y que unidas forman un tramo. Diagrama 69 - Clase UML LineString MultiLineString Una multilínea es un conjunto de líneas que forman una única geometría. Diagrama 70 - Clase UML MultiLineString Feature 126

127 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 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 Definiendo con detalle una ruta 127

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

129 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

130 Tabla 7 - Tabla de posibilidades de puntos de ruta 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 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

131 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 Servicios web SOAP 131

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

133 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 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 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. GeoJSON Elección de un formato de intercambio de geometrías: 133

134 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

135 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 Diseño de los casos de uso de rutas 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

136 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

137 de ruta Diseño de la interfaz de usuario de Selección de puntos 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

138 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

139 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 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 Formato GeoJSON de una solicitud 139

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

141 Un esquema simplificado de la transformación es el siguiente: GeoJSONParser GeoJSONString geom.featurecollection org.json.me.* 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

142 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

143 Diagrama 81 - Diagrama de actividad de cálculo de rutas Anular ruta 143

144 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

145 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

146 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

147 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

148 Diagrama 85 - Layout de formulario de obtener direcciones de ruta 148

149 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 Definición de puntos de interés 149

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

151 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

152 Un ejemplo de punto de interés codificado es el siguiente: 0, , , LOS ARCOS, 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 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 Almacenamiento de puntos de interés Índices espaciales 152

153 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. Quadtree Diseño de un índice espacial específico a partir de un 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

154 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

155 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

156 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 Pre-procesado de puntos de interés Mediante una aplicación J2SE realizada para el caso, se tomará el fichero con los 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

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

158 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 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 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 , calculamos cúal es el fichero de descripciones con: 158

159 offset / tamfichero /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 % 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 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 CoordenadaY Categoría OffSetDescripción double (8 bytes) double (8 bytes) short (2 bytes) 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 Diseño de los casos de uso de puntos de interés 159

160 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

161 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

162 Diagrama 94 - Diagrama de clases de jerarquía de tareas 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

163 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

164 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

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

166 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

167 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

168 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

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

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

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

172 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

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

174 Diagrama 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 Pantalla del mapa 9.2 Navegación de mapa 174

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

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

177 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 Punto de origen 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 Punto de origen y dos puntos de paso sobre el mapa 177

178 Al indicar puntos intermedios de visita, la ruta no se calcula automáticamente hasta que usted dé la orden 'Obtener ruta' 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 Ruta calculada sobre el mapa 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

179 tanto el punto de partida como el punto de destino con los comandos 'Ruta desde aquí' y 'Ruta hasta aquí'. Diagrama Selección de tipo de ruta Diagrama Ruta calculada 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

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

181 Diagrama Formulario selección de puntos de ruta Existen varias opciones: Diagrama Menú contextual de selección de puntos de ruta 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

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

183 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. paso Ruta con punto de origen y uno o más puntos de 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 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' 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

184 determinado nivel de zoom. Si no ve puntos de interés, acérquese más haciendo zoom. Diagrama Puntos de interés sobre el mapa Diagrama Cargando información Diagrama Elementos encontrados 184

185 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 Formulario consultar información Menú contextual de puntos de interés turísticos Diagrama 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

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

187 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 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 Selección de categoría de búsqueda de puntos de interés 187

188 Diagrama 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 Salir 188

189 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

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

191 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 Instalación sobre teléfonos móviles 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 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 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

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

193 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: S.htm 193

194 10. 2 Manual de instalación BlackBerry 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 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 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 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 Posibles problemas con la instalación 194

195 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

196 S.htm [2]

197 10.3 Manual de instalación Windows Mobile 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 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\ive- 2.2\runtimes\wm2003\arm\midp2\bin\fileconn.dll en la carpeta bin\ de J9 en Windows Mobile. 2. Copiar fixed\ive- 2.2\runtimes\wm2003\arm\midp2\lib\jclMidp20\ext\fc.jar en la carpeta lib\jclmidp20\ext\ de J9 en Windows Mobile. [1] es/571/techs/features/com.ibm.weme.wm2003.arm.pdapfc.runtime22_5.7.1/wsdd5.0.jar 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 198

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

200 12. Testing sobre dispositivos reales 12.0 Introducción Resultado del testing sobre dispositivos reales Listado de teléfonos probados Teléfono Sistema operativo/java Se instala? Arranca? Códigos de error Solución Funcionalidades que no van BlackBerry Curve 8310, BlackBerry OS > BlackBerry 4.2 Pearl 8110, BlackBerry LG KU990 Motorola V3X Nokia N73, Nokia 6110 Navigator, Nokia Nokia NGage Nokia 6280 Samsung SGH E250V CLDC 1.1/MIDP 2.0 CLDC 1.1/MIDP 2.0 Symbian 3rd ed. Sí. Hay que instalar con Sí jad+jar+cod La versión firmada no. La versión sin No firmar tampoco La versión firmada no. Sí La versión sin firmar sí Sí. Tanto la versión S60 firmada Sí como la versión sin firmar 907 Invalid COD illegal host string starts with '/' Probablemente hay una versión anterior instalada. Desintalar 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 Autenticación fallida No reconoce la firma de Thawte Con GPRS va bastante lenta la carga de tiles. No he probado GPS. La caché en disco a veces excepciones. No va JSR-75. Da OutOfMemoryError al abrir cualquier formulario. Tampoco llega a cargar todos los tiles (se queda sin memoria) Peculiaridades 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 da 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 Creo los Motorola utilizan una librería nativa para acceder a ficheros. La demo de LWUIT también da OutOfMemoryError al abrir formulario. cualquier Al arrancar la aplicación solicita que demos acceso a La aplicación no Internet repetidas consigue conectar veces y al final la Antes de ejecutar la con la aplicación se cierra. aplicación hay que configuración de Instalando desde En principio va todo configurar los Internet Internet dice 'Archivo permisos. Reconoce la seleccionada. JAR no válido' -> firma de Thawte Seleccionar otra Instalar desde el configuración. ordenador con Nokia PC Suite o por Bluetooth Symbian S60 1st ed. / CLDC 1.0 No No Error del sistema / MIDP 1.0 Nokia S40 3rd ed./ CLDC Sí 1.1/MIDP 2.0 CLDC 1.1/MIDP 2.0 No Aplicación no válida (No reconoce la Ofuscando la firma). El tamaño del versión firmada se archivo es muy puede instalar con grande. No deja - el jar y el cable del escribir en disco con teléfono pero da lo cual no hay OutOfMemoryError. acceso a puntos de interés. La versión firmada no No 'JAR supera el tamaño máximo' 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. 200

201 Samsung SGH Z150 Samsung ZV60 Sony Ericsson K800 Sony Ericsson G502 HTC Touch, HTC TyTN... Palm Treo 500v Nokia 6300 CLDC 1.1/MIDP 2.0 CLDC 1.1/MIDP 2.0 CLDC 1.1/MIDP 2.0 CLDC 1.1/MIDP 2.0 se instala. La versión sin firmar da error: 'JAR supera el tamaño máximo' La versión firmada no se instala. La versión sin firmar sí Sí Sí - Da OutOfMemoryError al hacer zoom si - está activado el escalado del mapa 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 Puede ser porque el teléfono tiene Sí Sí Error en la operación demasiadas aplicaciones instaladas. Eliminando algunas se resuelve - - Sí Sí La versión Windows firmada no. Mobile 5/JVM Sí - - La versión sin Esmertec JBed firmar sí Windows Mobile 6/ JVM Sí Sí Esmertec JBed Nokia S40 3rd ed./ CLDC No 1.1/MIDP 2.0 No 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 En general no va el defecto de WM. acceso a ficheros Instalando J9 van JSR-75. Hay todas las problemas con los funcionalidades y POIs. Con JBed no conecta a Internet. conecta a Internet Hay que añadir a mano las librerías JSR- 75 en J9 Aplicación no válida (No reconoce la firma). Nokia N Nokia E Nokia 5800 Nokia S60 5th edition 12.2 Resumen Sí Sí StackOverFlowError Parece ser que hay un problema al cargar el archivo del índice espacial - recursivamente. Habría que hacerlo iterativamente Tabla 9 - Testing de teléfonos Sólo he probado la versión sin firmar y funciona bien. 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 Teléfono Nokia S60 Nokia S40 Sony Ericsson Motorola Comentario Se reconoce la firma y funciona todo No reconoce la firma, la versión sin firmar funciona pero hay restricciones de memoria Se reconoce la firma y funciona todo No reconoce la firma y la versión sin firmar arranca pero es imposible utilizarla 201

202 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 hardware provoca restricciones de la memoria disponible. 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 el modelo de seguridad: certificados+permisos. 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

203 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

204 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

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

206 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

207 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

208 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 Formulario GetCapabilities 208

209 Diagrama Capa PNOA Capas de servidores de tiles preconfiguradas: Open street maps, Yahoo maps, Microsoft maps. Diagrama Capas preconfiguradas Diagrama Capa OSM 209

210 Soporte a YOURS (Yet another routing service): Servicio de cálculo de rutas libre de Open Street Maps. Soporte a Namefinder: Servicio de búsqueda de direcciones libre de Open Street Maps. Diagrama NameFinder en gvsig phone Utilización del paquete de reproyección de gvsig Mobile sobre gvsig phone. 210