Repositorio Institucional de Documentos

Proyecto Fin de Carrera Desarrollo de aplicación del sistema web de gestión de carreteras de Iternova para plataformas móviles Autor Francisco Javier Aguerri Moreno Ponente Antonio Valdovinos Bardají Director Jorge Casas Cañada Escuela de Ingeniería y Arquitectura Septiembre 2012 Resumen Desarrollo de aplicación del sistema web de gestión de carreteras de Iternova para plataformas móviles El presente proyecto fin de carrera pretende dar una respuesta a la problemática planteada por las tareas de mantenimiento generadas por un red de carreteras. Para ello, se ha realizado un módulo de agenda móvil integrado dentro del Sistema de Gestión Web de Carreteras de Iternova S.L., un sistema web SCADA (Supervisory Control and Data Acquisition) para la gestión y explotación de carreteras. La agenda de vialidad es el sistema encargado de gestionar la información relacionada con las operaciones de vialidad llevadas a cabo en la carretera. Éstas incluyen la actuación ante accidentes (tanto con afección a la calzada como sin afección), incidencias (animales muertos, objetos en la calzada, desprendimientos) o deterioros de vialidad (pavimentos, obras, señalización). El proyecto concretamente se centra en el desarrollo de una solución para plataformas móviles Android que permita afrontar con éxito toda la problemática que presenta la gestión telemática de una carretera (gestión de todos los datos e imágenes generados). Este sistema será la herramienta de los operarios encargados del mantenimiento de la carretera para la realización de las tareas pendientes, y de los supervisores para controlar la correcta ejecución del proceso. Las principales funcionalidades de este sistema son: Una agenda de tareas que agrupa y organiza todas las tareas pendientes de realizar. El operario sólo recibe las tareas asignadas al sector donde se encuentra, gracias a la inteligencia del motor de búsqueda que proporciona el sistema. La disposición del listado no es arbitrario, sino que se realiza una búsqueda ordenada, donde las tareas prioritarias aparecen primero. Gestión de formularios. Los formularios no son estáticos sino que se realiza una carga dinámica desde el servidor. El sistema debe garantizar que los cambios que haya en las fichas sean transparentes al usuario, por lo que la gestión de las bases de datos debe ser realizada cuidadosamente. El sistema debe asegurar el almacenamiento de la información en situaciones de ausencia de cobertura, y su envío al servidor en el momento oportuno. Diversas opciones de configuración, que permiten adaptar el funcionamiento de la aplicación a las necesidades del usuario y a la situación en la que nos encontremos. Es posible refrescar el listado de las tareas de manera automática de manera transparente para el usuario, así como el envío de la información pendiente cada cierto tiempo. También debe permitir realizar una adecuada limpieza de las bases de datos, y otras opciones de configuración menores. En el desarrollo se ha tenido en cuenta el entorno de utilización: este es el de una carretera convencional, donde a menudo nos encontraremos en situaciones de ausencia de cobertura o de baja velocidad de conexión. Para solventar estos problemas, la aplicación cuenta con diferentes modos de funcionamiento para afrontar con garantías todos los posibles escenarios. Es muy posible que, durante la jornada del operario en la carretera, no se disponga de cobertura, lo que genera un problema de gestión importante. Por un lado, el sistema debe seguir funcionando de manera autónoma sin conexión con el servidor, y por otro la información registrada debe quedar almacenada y ser enviada cuando se detecte conexión a Internet. También debe tenerse en cuenta que en ausencia de cobertura no es posible obtener geolocalización ni recursos externos, lo que genera una problemática adicional. Otro ejemplo de la gestión de la información en función de las condiciones se da en la transmisión de imágenes. Es posible configurar el envío de imágenes sólo en entornos de alta velocidad de conexión (redes Wi-Fi), ya que el consumo de datos en redes 3G es alto y ralentiza el manejo de la aplicación. El sistema también cuenta con un sistema de alerta configurable que avisa al usuario (sonido y vibración del dispositivo) cuando existen nuevas tareas. Estas alertas sólo aparecerán en el caso de que las nuevas tareas se sitúen en el sector en el que trabaja el usuario. Por último, existe también un sistema de roles que otorga diferentes privilegios (capacidad para dar de alta nuevas tareas, validación de tareas ya realizadas, etc) en función del tipo de usuario registrado. El Sistema de Gestión Web de Carreteras de Iternova S.L. que engloba el sistema de la agenda de vialidad, es pionero en la gestión de carreteras y está implantado en algunas de las carreteras más importantes de México (Atlacomulco-Maravatío, Sinaloa) y es también la solución elegida para la gestión de las carreteras de algunas regiones de España como Aragón, Valencia y Castilla La Mancha, entre otras. Índice de contenido Capítulo 1. INTRODUCCIÓN.......................................................................12 1.1. Objetivos del proyecto y la solución adoptada.........................................................14 1.2. Contexto profesional.................................................................................................15 1.3. Motivación.................................................................................................................17 1.4. Elementos innovadores............................................................................................17 1.5. Estructura de la memoria.........................................................................................18 Capítulo 2. TRABAJO PREVIO....................................................................20 2.1. Android......................................................................................................................22 2.2. jQuery y jQuery mobile.............................................................................................22 2.3. AJAX.........................................................................................................................23 2.4. PhoneGap.................................................................................................................25 2.5. LAMP........................................................................................................................25 Capítulo 3. DESARROLLO DE LA APLICACIÓN..........................................28 3.1. Escenario. Consideraciones previas........................................................................30 3.2. Arquitectura y elementos de la aplicación................................................................31 3.2.1. Registro (login) y salida (logout) en el sistema.................................................31 3.2.2. Menú principal...................................................................................................33 3.2.3. Lista de tareas...................................................................................................34 3.2.4. Ficha de la tarea................................................................................................37 3.2.5. Informes de actuación.......................................................................................38 3.2.6. Alta de nueva tarea...........................................................................................42 3.2.7. Opciones...........................................................................................................44 3.3. Plan de pruebas del sistema....................................................................................45 3.3.1. Instalación e inicio de la aplicación...................................................................46 3.3.2. Lista de tareas...................................................................................................47 3.3.3. Ficha de tarea....................................................................................................47 3.3.4. Informes de iniciación/finalización.....................................................................48 3.3.5. Alta de tareas....................................................................................................49 3.3.6. Opciones...........................................................................................................51 3.4. Elementos de apoyo a la aplicación.........................................................................52 3.4.1. Servidor.............................................................................................................52 3.4.2. Control de versiones y actualizaciones.............................................................53 3.4.3. Ficheros de configuración y librerías................................................................53 3.5. Problemas planteados durante el desarrollo del proyecto.......................................54 Capítulo 4. CONCLUSIONES.......................................................................56 4.1. Resultados obtenidos...............................................................................................58 4.2. Líneas futuras de desarrollo.....................................................................................58 4.2.1. Desarrollo de la aplicación móvil ″agenda de inspección″................................59 4.3. Valoración personal..................................................................................................59 Bibliografía.................................................................................................60 Anexo A.Manual de usuario de la agenda de vialidad (versión móvil).....64 A.1.Introducción...............................................................................................................66 A.2.Opciones del usuario.................................................................................................66 A.2.1.Acceso a la aplicación (login)............................................................................66 A.2.2.Inicialización y configuración de la aplicación...................................................67 A.2.3.Acciones con las tareas.....................................................................................71 A.2.4.Dar de alta incidencias.......................................................................................75 Anexo B.Elementos clave del código de la aplicación.............................78 B.1.Base de datos...........................................................................................................80 B.1.1.Tabla de usuarios...............................................................................................80 B.1.2.Tabla de reportes de actuación.........................................................................80 B.1.3.Tabla de nuevas tareas.....................................................................................82 B.1.4.Tabla de la lista de tareas..................................................................................83 B.2.Caché local................................................................................................................85 B.3.Librería de la aplicación............................................................................................86 B.3.1.Funciones genéricas para la gestión de la base de datos local........................86 B.3.2.Funciones específicas.......................................................................................88 B.3.3.Funciones de propósito general........................................................................89 Desarrollo de aplicación móvil Capítulo 1. INTRODUCCIÓN para gestión de carreteras 1.1. Objetivos del proyecto y la solución adoptada El objetivo de este proyecto fin de carrera es crear un sistema que ofrezca una solución telemática al problema de la gestión de incidencias en la carretera. Dicha solución consiste en el módulo agenda de vialidad, que será el sistema encargado de gestionar todas las tareas llevadas a cabo en la carretera como respuesta a las incidencias. El núcleo de nuestro sistema es una aplicación móvil, que se apoya en una arquitectura cliente-servidor. Es decir, tendremos múltiples usuarios (terminales) trabajando a la vez con la aplicación desarrollada que se comunican con el servidor, que actúa de elemento central. Esta aplicación móvil consiste en la versión para dispositivos portables (tablet, smartphones) del módulo de agenda del Sistema de Gestión Web de Carreteras (SGWC) de Iternova. Dicho módulo de agenda es el encargado de gestionar la información relacionada con las operaciones de vialidad llevadas a cabo en la carretera. El objetivo es mejorar la organización y el servicio ofrecido a los ciudadanos. Francisco Javier Aguerri Moreno 17 Figura 1. Diagrama de la arquitectura del sistema Capítulo 1. INTRODUCCIÓN Desarrollo de aplicación móvil para gestión de carreteras La aplicación debe solventar correctamente dos problemas principales: •A menudo nos encontramos en situaciones de baja capacidad de la red o directamente ausencia de la misma. •A pesar de lo anterior, el sistema debe ser fiable y ágil dado que la naturaleza del problema a resolver (incidencias en las carreteras) no admite un gran margen de error ni largas esperas. Debido a ello, se implementó una solución con las siguientes características: •Compatible para diferentes modelos de terminales. •Optimizada para minimizar los tiempos de carga, y agilizar el el uso de la aplicación por parte del usuario en entornos remotos. •Se tienen en cuenta los problemas de límites de ancho de banda y cobertura de las redes móviles, disponiendo de los mecanismos oportunos para agilizar la velocidad de la aplicación y evitar la pérdida de información por falta de conexión con el servidor e Internet. Respecto a la cobertura, la aplicación dispone de todos los elementos necesarios para permitir trabajar aún cuando ésta no exista (es decir, de forma autónoma), volviendo a sincronizar la información con los servidores cuando la conexión vuelva a estar disponible, de forma que se garantice la continuidad del funcionamiento. La aplicación permite a los operarios la actualización instantánea de las tareas en el mismo momento en que proceden a su actuación, al mismo tiempo que se controla la posición exacta en la que se encuentra, posibilitando el seguimiento de la resolución de las tareas por parte de la empresa para mantener el control sobre las actuaciones realizadas. 1.2. Contexto profesional El proyecto fin de carrera se realizó íntegramente en Iternova S.L. , una empresa de consultoría tecnológica especializada en soluciones tecnológicas innovadoras para la gestión de carreteras. Iternova es una empresa con una continua apuesta por la innovación, que les ha permitido desarrollar productos de gran éxito e implantación a nivel nacional, como el sistema SGWC (Primer sistema web de gestión integral para la explotación de carreteras), por el cual la empresa recibió el VIII premio nacional ACEX 2012 a la seguridad en conservación de carreteras, además de otros galardones como el premio sociedad de la información Aragón 2012 a la empresa del año. Francisco Javier Aguerri Moreno 18 Desarrollo de aplicación móvil Capítulo 1. INTRODUCCIÓN para gestión de carreteras SGWC de Iternova El presente proyecto fin de carrera, como ya hemos comentado brevemente, se enmarca en el Sistema de Gestión Web de Carreteras (SGWC) de Iternova. El SGWC se trata del primer Sistema Web SCADA (Supervisory Control And Data Acquisition) desarrollado para la gestión de la conservación y explotación de carreteras, e implantado a nivel nacional e internacional. El sistema plantea un importante salto cualitativo en la gestión de la explotación de carreteras, permitiendo acceder a toda la información de las mismas de una forma integrada: •Se trata de un sistema web (permite el acceso a la información en cualquier momento y lugar), multidispositivo (facilita la integración de hardware de cualquier fabricante), basado en código libre (no requiere de licencias ni mantenimientos), modular (se adapta a las necesidades de cualquier demarcación) y multiusuario (con diferentes roles de acceso a la información). •El sistema está basado en el concepto SaaS (Software as a Service), pudiendo ser adaptado a las necesidades de cada cliente. El innovador sistema desarrollado, formado por varios módulos, integra de una forma optimizada la gestión de todos los elementos de interés de las carreteras: •Módulo de información y gestión general de carreteras, con sus elementos más significativos inventariados y geolocalizados. •Módulo de gestión de la vialidad en tiempo real: sistema de gestión de flotas (GPS), de cámaras de explotación, estaciones meteorológicas, aforos, paneles de información, etc. •Módulos de comunicación, módulos de documentación (integra un completo gestor de expedientes), y funcionalidades avanzadas de gestión Web. •Módulo de agenda avanzada (para la gestión de las actuaciones programables y no programables de vialidad), y sistema de control y seguimiento de trabajos. Aquí es donde se integra el trabajo desarrollado en este PFC. El sistema SGWC se ha convertido en el sistema más avanzado de gestión de la Explotación y Conservación de carreteras, cuyo éxito está siendo avalado por su implantación paulatina en las principales provincias y comunidades autónomas españolas, tales como Aragón, Valencia, Murcia, Castilla La Mancha y Soria, así como en las principales carreteras de México (Atlacomulco-Maravatío, Sinaloa). Francisco Javier Aguerri Moreno 19 Capítulo 1. INTRODUCCIÓN Desarrollo de aplicación móvil para gestión de carreteras 1.3. Motivación La motivación para realizar este PFC en concreto vino por varias razones. La primera, era mi voluntad de realizar el PFC en el ámbito de una empresa. Primeramente, creo que es una estupenda oportunidad de entrar en contacto con el mundo laboral y adquirir una primera experiencia muy valiosa. Y segundo, porque creo que los conocimientos adquiridos en una empresa son mucho más cercanos a lo que se demanda en el mercado laboral. En segundo lugar, considero que las tecnologías estudiadas durante el desarrollo del proyecto son punteras hoy en día, y están muy presentes en el mercado laboral. Este PFC se basa en el desarrollo de una aplicación enfocada al uso en dispositivos móviles (tablets, smartphones). Estos dispositivos están ganando cuota de mercado día a día frente a medios más tradicionales como ordenadores de sobremesa en el ámbito de las TIC (Tecnologías de la Información y la Comunicación). Es obvio que de la misma manera, asistimos a un auge de las aplicaciones móviles. Existe una amplísima gama de ellas y cada día aparecen gran cantidad de otras completamente novedosas, algunas de ellas con muchísimo éxito a nivel mundial. Por estas razones, la formación que este proyecto ofrecía en este sector es una gran oportunidad. 1.4. Elementos innovadores Como ya se ha comentado anteriormente, el SGWC de Iternova es un sistema innovador en el ámbito de la gestión de la explotación de carreteras por tratarse de un sistema integral, flexible, y ubicuo. El presente PFC debe amoldarse pues a las características del sistema en el que se encuentra integrado. El trabajo desarrollado es un sistema pionero en el sector de la gestión de carreteras a nivel nacional e internacional por diversos motivos: •Al tratarse de información crucial para algo sensible como es las incidencias en las carreteras, el sistema está optimizado para funcionar de la manera más ágil posible, ofreciendo una interfaz sencilla de manejar, una gestión inteligente de la información introducida, y un sistema de alertas para que el usuario esté informado de los últimos sucesos. •La aplicación está pensada para funcionar en entornos de baja o nula conectividad, tratando de aprovechar el escaso ancho de banda disponible. Francisco Javier Aguerri Moreno 20 Desarrollo de aplicación móvil Capítulo 1. INTRODUCCIÓN para gestión de carreteras •Sistema de permisos y roles de usuario, que permiten ejercer el control sobre los trabajos realizados y aporta otro elemento optimizador, ya que la información intercambiada depende del tipo de usuario y se ajusta a lo que éste necesita, evitando enviar datos que no serán utilizados. 1.5. Estructura de la memoria La presente memoria se estructura en dos partes presentadas en el mismo tomo. En esta parte principal de la memoria se tratará de presentar el trabajo desarrollado en el proyecto de forma concisa, detallando los aspectos necesarios para una comprensión adecuada de este proyecto. Esta parte principal a su vez se divide en varios capítulos: 1. Introducción. Se tratarán todos los aspectos necesarios para entender el contexto, motivación y objetivos del proyecto. 2. Trabajo previo. Se comentarán los conocimientos previos que fueron necesarios antes de comenzar a realizar el proyecto. 3. Desarrollo de la aplicación. En este capítulo se detalla el trabajo realizado y se explican con detenimiento las necesidades que demanda el mismo y las soluciones aplicadas. 4. Conclusiones. Se presenta una reflexión sobre los resultados del proyecto y las posibles líneas de continuación del mismo. En cuanto a los anexos, contienen información no fundamental para una comprensión mínima del proyecto, pero muy útil si se pretende profundizar, sobre todo en los aspectos técnicos. La memoria del proyecto contiene los siguientes anexos: A) Manual de usuario de la aplicación. Se trata del manual de referencia entregado a nuestros clientes para guiarles en el uso del sistema. B) Elementos clave del código de la aplicación. Aquí se comentarán aspectos clave de la programación del sistema y el por qué de su importancia. Francisco Javier Aguerri Moreno 21 Capítulo 2. TRABAJO PREVIO El trabajo previo para el desarrollo de este proyecto fin de carrera ha consistido en el aprendizaje de un conjunto de tecnologías, si bien mientras en algunas de ellas se ha alcanzado un conocimiento bastante profundo de la materia (Javascript y sus frameworks -jQuery, jQuery mobile y PhoneGap- y HTML principalmente) en otros se han adquirido unos conocimientos suficientes para realizar el trabajo pero sin obtener un manejo completo de la tecnología (SQL, PHP) y en algunos sólo se han visto los conocimientos específicos que se necesitaban aplicar (CSS). Para una mejor comprensión de este proyecto, se presenta una descripción de las tecnologías empleadas durante el desarrollo del mismo. Desarrollo de aplicación móvil Capítulo 2. TRABAJO PREVIO para gestión de carreteras 2.1. Android Android es un sistema operativo inicialmente pensado para teléfonos móviles, al igual que iOS, Symbian y Blackberry OS. Lo que lo hace diferente es que está basado en Linux, un núcleo de sistema operativo libre, gratuito y multiplataforma. El sistema permite programar aplicaciones en una variación de Java1 llamada Dalvik. El sistema operativo proporciona todas las interfaces necesarias para desarrollar aplicaciones que accedan a las funciones del teléfono (como el GPS, las llamadas, la agenda, etc.) de una forma muy sencilla en un lenguaje de programación orientada a objetos muy conocido como es Java. Esta sencillez, junto a la existencia de herramientas de programación gratuitas, hacen que una de las cosas más importantes de este sistema operativo sea la cantidad de aplicaciones disponibles, que extienden casi sin límites la experiencia del usuario. Además Android incorpora de serie todas las herramientas necesarias para la creación y gestión de bases de datos SQLite, un motor de bases de datos muy popular en la actualidad por ofrecer características tan interesantes como su pequeño tamaño, no necesitar servidor, precisar poca configuración, ser transaccional y por supuesto ser de código libre. Una de las mejores características del sistema operativo Android es que es completamente libre. Es decir, ni para programar en este sistema ni para incluirlo en un teléfono hay que pagar nada. Y esto lo hace muy popular entre fabricantes y desarrolladores, ya que los costes para lanzar un teléfono o una aplicación son muy bajos. En febrero de 2011 se anunció la versión 3.0 de Android, llamada con nombre en clave Honeycomb, que está optimizado para tabletas en lugar de teléfonos móviles. 2.2. jQuery y jQuery mobile jQuery es un framework2 Javascript3. Cuando un desarrollador tiene que utilizar Javascript, generalmente tiene que preocuparse por hacer scripts compatibles con varios navegadores y para ello tiene que incorporar mucho código que lo único que hace es detectar el navegador del usuario, para hacer una u otra cosa dependiendo de si es Internet Explorer, Firefox, Opera, etc. Aquí jQuery es donde más nos puede ayudar, puesto que implementa una serie de clases (de programación orientada a objetos) que nos permiten programar sin preocuparnos del navegador con el que nos está visitando el usuario, ya que funcionan de exacta forma en todas las plataformas 1 Java es un lenguaje de programación orientado a objetos, independiente de la plataforma, con el que podemos realizar cualquier tipo de programa. En la actualidad es un lenguaje muy extendido y cada vez cobra más importancia tanto en el ámbito de Internet como en la informática en general. Está desarrollado por la compañía Sun Microsystems con gran dedicación y siempre enfocado a cubrir las necesidades tecnológicas más punteras. 2 Un framework es un producto que sirve como base para la programación avanzada de aplicaciones, que aporta una serie de funciones o códigos para realizar tareas habituales. Por decirlo de otra manera, son unas librerías de código que contienen procesos o rutinas ya listos para usar. Los programadores utilizan los frameworks para no tener que desarrollar ellos mismos las tareas más básicas, puesto que en el propio framework ya hay implementaciones que están probadas, funcionan y no se necesitan volver a programar. 3 Javascript es un lenguaje de programación orientado a objetos ampliamente utilizado en Internet. Se utiliza principalmente en su forma del lado del cliente, implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas, y en bases de datos locales al navegador, entre otros. Su uso en aplicaciones externas a la web, por ejemplo en documentos PDF, o aplicaciones de escritorio es también significativo. Francisco Javier Aguerri Moreno 25 Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras 3.1. Escenario. Consideraciones previas. Como ya se ha comentado anteriormente, nuestra aplicación tendrá que trabajar en un entorno de baja conectividad, a pesar de lo cual tendrá que seguir operativa de manera fiable. Pero es que aunque se disponga de conexión hay que tener en cuenta que el sistema será utilizado en México, donde las tarifas de datos tienen un gran coste y permiten anchos de banda pequeños. Esto nos condiciona de tal manera que hemos de tratar de aprovechar ese ancho de banda de la mejor manera posible, tratando de utilizar los momentos en los que dispongamos de red Wi-Fi para el envío de los datos más pesados y no imprescindibles (imágenes). Además de ésto, debemos tener en cuenta una serie de condiciones de nuestro cliente. Se trata de una empresa contratada para la gestión de algunas de las carreteras más importantes de México (Atlacomulco-Maravatío, Sinaloa) y desde el ministerio de aquel país se les imponen unos plazos de actuación en ocasiones muy ajustados que deben cumplir estrictamente. Los operarios de la empresa que realizan las tareas de mantenimiento tienen en su contrato de trabajo cláusulas por las cuales pueden ser económicamente penalizados si incurren en sucesivas faltas. Es por éstas razones por las que se ha tratado de hacer especial hincapié en la necesidad de realizar una aplicación ágil, que permita acceder a la información y manipularla en muy poco tiempo ya que los plazos son en ocasiones, de una hora, en la cual el operario debe darse cuenta de la nueva tarea, desplazarse hasta el lugar de la incidencia y rellenar los formularios adecuados. Con respecto a la tecnología de que disponen los operarios que harán uso de este sistema, disponen del terminal Samsung Galaxy Note, que proporciona un adecuado marco para el uso de la aplicación. Actualmente el sistema operativo utilizado es la versión 2.3.5 de Android, aunque en un futuro próximo la versión será la 4.0.4. Francisco Javier Aguerri Moreno 33 Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras 3.2. Arquitectura y elementos de la aplicación En este apartado veremos todas las pantallas y posibilidades que ofrece la aplicación y la lógica subyacente que hay detrás de cada una. Además, se mencionarán en multitud de ocasiones las tablas de la base de datos del dispositivo y las variables de la caché local. Podemos encontrar un listado y descripción de toda esta información en el anexo B. 3.2.1. Registro (login) y salida (logout) en el sistema Evidentemente, la agenda de vialidad y en general, todo el sistema SGWC es un sistema cerrado, por lo que debemos permitir el acceso sólo a ciertos usuarios. El sistema de registro permite al usuario identificarse para poder trabajar con la aplicación. Pantalla de registro Para realizar el registro (login), el sistema requiere de dos campos: nombre de usuario y contraseña. Estos datos son enviados al servidor con tecnología AJAX (es decir, en modo asíncrono) mediante el método POST (todas las peticiones al servidor que realiza esta aplicación utilizan el método POST), y el cliente (aplicación) recibe una respuesta en formato JSON (todas las respuestas recibidas del servidor tienen este formato) que contiene, entre otros, un campo que nos indica si el registro del usuario se ha recibido con éxito (OK) en el servidor o no (NOK). En caso afirmativo, se procede a guardar la información de registro del usuario (nombre de usuario y contraseña) en la tabla de usuarios de la base de datos del dispositivo, y avanzamos al menú principal de la aplicación. Además, cuando nos registramos con éxito en el sistema, cierta información (permisos de usuario, sector asociado a dicho usuario y otros) se guarda en la caché local del navegador (localStorage, una característica de HTML 5). Cabe destacar que la tabla de usuarios sólo guarda un único usuario, el último que se registró. Se adoptó esta solución por seguridad, de manera que no será posible recuperar información sensible (contraseña) de otros usuarios que anteriormente hayan utilizado el terminal, siempre y cuando hayan realizado la salida (logout) correctamente. Igualmente, comentar que la aplicación utiliza en todo momento (no sólo para el registro) conexiones mediante certificados de seguridad SSL, por lo que todos los Francisco Javier Aguerri Moreno 34 Figura 4. Pantalla de registro Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras datos sensibles se transmiten de forma segura. Registro automático (autologin) En nuestro sistema, se tuvo en cuenta también que la agilidad y comodidad en la aplicación móvil son muy valorables y en algunos casos, necesarias, dado que podemos tener plazos temporales que cumplir. En este contexto, nació la idea del módulo de autorregistro (autologin). Dicho módulo verifica al abrir la aplicación que existen datos de usuario en la tabla correspondiente y realiza el registro en el servidor de manera transparente para el usuario, llevándonos al menú principal sin pasar por la pantalla de registro. Si existiese algún problema durante el autorregistro, entonces sí que pasamos por la pantalla de registro, a fin de conseguir un ingreso correcto en el sistema. Ausencia de conexión Se dedicará un apartado específico para explicar el comportamiento del sistema en ausencia de cobertura, dado que es uno de los problemas fundamentales a los que se enfrenta nuestro servicio, como ya hemos comentado en varias ocasiones. En el caso del registro, distinguiremos dos situaciones: el caso de que estemos tratando de registrarnos en la pantalla correspondiente, y el caso del registro automático, dado que presentan diferencias importantes. En el registro automático En este caso, si disponemos de información almacenada en la tabla de usuarios, será posible acceder al sistema, manteniendo toda la configuración (permisos, etc) asociada al usuario que teníamos almacenado. Es decir, tenemos el mismo comportamiento que en el caso de un autorregistro con conexión, pero la aplicación mostrará un mensaje para avisarnos de dicha situación (ver figura 5). Esto significa que el servidor no sabe que nosotros estamos dentro del sistema. Esta situación se corrige cuando nuestro terminal entra en una zona de cobertura y realiza una petición de cualquier tipo al servidor. Podríamos pensar que dicha petición será rechazada por el servidor al provenir de un usuario que aparentemente no está registrado, sin embargo, cada vez que se realiza una petición al servidor de cualquier naturaleza hacemos primero una petición de autorregistro, de manera que el servidor siempre tiene información actualizada sobre qué usuarios están activos. Francisco Javier Aguerri Moreno 35 Figura 5. Intento de registro sin conexión Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras En la pantalla de registro Si al tratar de enviar los datos de usuario al servidor no disponemos de conexión a Internet, no será posible acceder al sistema, dado que estar en dicha pantalla significa que la base de datos no contiene información sobre ningún usuario (bien porque el último cerró su sesión correctamente o porque es la primera vez que ejecutamos la aplicación). Salida (logout) Como ya hemos comentado anteriormente, si el usuario realiza un de-registro la tabla de usuarios borrará la información contenida y la aplicación nos llevará a la pantalla de registro. Además, toda la información relativa al usuario almacenada en la caché local (permisos, lista de tareas, etc) será eliminada también, para no interferir con el próximo usuario que se registre. 3.2.2. Menú principal Una vez registrados correctamente en el sistema, pasamos al menú principal. Como podemos apreciar en la figura 7, este módulo es un simple distribuidor de las posibilidades que ofrece nuestra aplicación: Sí que es interesante comentar un punto relativo al Francisco Javier Aguerri Moreno 36 Figura 7. Pantalla del menú principal Figura 6. Proceso de registro de usuarios Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras sistema de permisos de usuario y es que el botón "Dar de alta incidencia" no estará disponible para los usuarios que no tengan dicho permiso. 3.2.3. Lista de tareas Nos encontramos ahora frente al elemento central de nuestro sistema. Se trata de un listado de elementos, cada uno de los cuales se corresponde con una "tarea" o "incidencia" que el usuario debe resolver en un plazo determinado. Podemos observar dos botones, "actualizar lista" y "refrescar lista". El primero realiza una recarga completa de la tabla de tareas de la base de datos de la aplicación. Es decir, envía una petición (POST) al servidor y recibe de éste la lista completa en formato JSON. Como se ha comentado para el caso del autorregistro, todas las peticiones al servidor van precedidas de otra que registra al usuario. De esta manera, mantenemos el servidor con información actualizada de nuestro estado. En la petición de la lista de tareas, se envía como parámetros la sección (grandes áreas que pueden cubrir varias carreteras) y el tramo de carretera para los cuales se desean recibir las tareas pendientes. Estos dos parámetros son configurables en el submenú de opciones (se verá más adelante). El botón "refrescar lista" simplemente realiza una carga de las tareas almacenadas en la base de datos del terminal mostrándolas por pantalla, sin necesidad de conectarse con el servidor. En la lista de tareas propiamente dicha, vemos cómo para cada tarea se muestra un resumen de la información de la misma con los datos más importantes, ID de la tarea, título de la incidencia, localización, plazos, etc. Podemos pulsar sobre cada una de dichas tareas, lo que nos llevará a la ficha de dicha incidencia en concreto. Francisco Javier Aguerri Moreno 37 Figura 8. Pantalla de la lista de tareas Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras Actualización automática de la lista de tareas Como podemos comprobar, la lista de tareas es el elemento esencial de nuestro sistema. Es de vital importancia pues, que se mantenga actualizado y disponible en cualquier situación. Para ello, se diseñó un módulo que realiza una actualización automática de la lista de tareas en la base de datos, realizando una petición al servidor para recibir los datos. Sin embargo, tenemos la constancia de que nuestra aplicación debe ser lo más ligera y eficiente posible, a la vez que funcional. Esto nos lleva a considerar los siguientes puntos: •Nuestra aplicación funcionará en entornos de baja cobertura, problema que se agrava si tenemos en cuenta que el cliente de nuestra empresa trabajará en un país (México) donde la transmisión de datos 3G son, a menudo, cara y lenta. Es necesario pues, ahorrarnos la transmisión de datos siempre que sea posible. •A menudo el tiempo disponible para realizar las actuaciones pertinentes es escaso (1h en algunos casos) debido a exigencias de las autoridades competentes. Si a nuestros clientes se les exige cumplir con los protocolos establecidos, nosotros haremos lo posible por proporcionar un servicio rápido y eficiente. Francisco Javier Aguerri Moreno 38 Figura 9. Diagrama de funcionamiento de la lista de tareas Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras •Nuestra aplicación debe mantenerse simple, aprovechando el máximo código posible para hacerla fácil de mantener ante eventuales cambios en las exigencias de nuestro cliente. Ante estos retos, se realizó un módulo de actualización automática con las siguientes características: •El núcleo de dicho módulo es la misma función de actualización de la lista de tareas que ejecutamos cuando pulsamos el botón correspondiente (ver figura 10). Simplemente, esta función tiene un parámetro que indica el modo en el que se ejecuta, pudiendo ser modo "normal" (cuando pulsamos el botón) o "background", de manera que en modo "background" no mostraremos mensajes que podrían aparecer y que no tienen sentido en un proceso que debe ser transparente al usuario, tales como errores del servidor u otros. Nuestro módulo debe gestionar correctamente estas situaciones. •El módulo de actualización automática envía primero una petición al servidor, el cual responde con la fecha y hora de la última modificación de la lista de tareas para el sector seleccionado por el usuario. Esta fecha y hora se compara con la que el terminal tenía almacenada en su caché local. ◦Si es distinta, se actualiza con la nueva fecha y hora y se actualiza la base de datos del dispositivo tras enviar la petición correspondiente. Una vez actualizada con éxito, se mostrará por pantalla el mensaje Francisco Javier Aguerri Moreno 39 Figura 11. Notificación de nuevas tareas durante el uso. Figura 10. Gestión de un intento de actualización automática de la lista de tareas. Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras "Existen nuevas tareas" acompañado de vibración y una alerta sonora, para que el operador sea consciente de los cambios. ◦Si es la misma, la petición de la lista de tareas no se llega a enviar. De esta manera, ahorramos en datos transmitidos si no son necesarios. •La actualización automática de la lista de tareas puede ser configurada en la pantalla de opciones (ver apartado 3.2.7 Opciones). Podemos desactivar totalmente este evento o bien controlar la frecuencia con la que ocurre, en un rango de entre 2 y 30 minutos. Hay que tener en cuenta que, como ya hemos visto anteriormente, los plazos de resolución de la incidencia son a menudo de menos de 1 hora (lo que incluye tiempo para llegar al lugar de la incidencia y solucionarla) por lo que se requiere actualizaciones cada pocos minutos para no perder tiempo. 3.2.4. Ficha de la tarea Al pulsar sobre alguna de las tareas de la lista, accederemos a su ficha, que muestra todos los detalles sobre dicha incidencia. Podemos ver entre otros, un mapa de Google Maps con la geolocalización, si los informes de iniciación y finalización están completados y el resto de detalles. En esta sección se realiza una gestión de las posibilidades de las que dispone el usuario. Estas posibilidades vendrán marcadas primeramente por los permisos de los que dispone y en segundo lugar, por el grado de compleción en el que se encuentre la tarea. Cada una de las opciones cuya disponibilidad varía se describen a continuación: •Iniciar/finalizar actuación. Si pulsamos uno de estos botones nos llevan a la redacción del informe o reporte de actuación correspondiente (inicial, final). La posibilidad de redactar estos informes viene dada por los permisos de usuario, por lo tanto, para algunos de ellos no aparecerán estos botones y no será posible redactar dichos informes. Adicionalmente, el sistema gestiona que no se produzcan situaciones no deseadas o inverosímiles. Por ejemplo, no es posible redactar el informe de finalización si no está redactado primero el informe de iniciación. Además, si tratamos de redactar un informe que el operario ya había enviado, el sistema debe detectarlo y no permitir su modificación ni la creación de un nuevo informe para la misma incidencia. Esto es así debido a petición expresa Francisco Javier Aguerri Moreno 40 Figura 12. Pantalla de la ficha de la tarea Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras de nuestro cliente, quien consideraba esencial que los usuarios no pudiesen realizar acciones que diesen lugar a situaciones ambiguas ni modificar datos ya enviados previamente. •Validar. Este botón aparecerá cuando ambos informes (iniciación y finalización) estén listos y a la vez, el usuario tenga el permiso correspondiente. La validación consiste en el visto bueno del usuario (normalmente un supervisor de los operarios) sobre el trabajo realizado (informes) para la tarea correspondiente. Es una simple petición al servidor, que recibe como respuesta si la validación ha quedado registrada en el servidor o no. En la figura 12 vemos como no aparecen ni el botón de finalizar actuación (debería aparecer a la derecha del de iniciar actuación) debido a que el reporte inicial no está redactado (tal como marca el icono debajo del mapa). El botón validar tampoco aparece (debería aparecer encima del botón ″volver″), ya que no hemos redactado los informes, aunque en caso de que estuvieran podría no aparecer si no tuviésemos el permiso necesario. 3.2.5. Informes de actuación Si pulsamos sobre alguno de los botones de iniciar o finalizar actuación llegaremos a una pantalla donde se pueden dar diferentes casos: •El informe ya había sido redactado por el usuario actual, por lo tanto se encuentra en nuestra base de datos. •El informe había sido redactado por otro usuario. •El informe está pendiente de realizar. En el primer y segundo caso simplemente se mostrará el informe completo, sin posibilidad de modificarlo ni de reenviarlo. Nos centraremos de momento en el tercer caso. En el subapartado "Gestión de informes en el sistema" se estudiarán más a fondo las otras situaciones. Por ahora, comentaremos los campos a rellenar en el informe: •Fecha y hora. Automáticamente se toman los datos del dispositivo. •Geolocalización. Se toman los datos del sistema GPS, también de manera automática. Cuando la geolocalización se completa con éxito, se muestra un mapa de Google Maps con la situación del usuario. •Posibilidad de tomar imágenes de la incidencia. Tendremos opción de, o bien tomar nuevas instantáneas con la cámara integrada en el Francisco Javier Aguerri Moreno 41 Figura 13. Pantalla del informe de actuación Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras Finalmente, se incluye un selector para establecer el tamaño de las imágenes capturadas por la cámara, de manera que podemos rebajar los datos enviados en redes de poca capacidad. 3.3. Plan de pruebas del sistema A continuación se detalla el plan de pruebas seguido para comprobar el buen funcionamiento del sistema y que cumple con los requisitos que se le exigían. Aunque durante el desarrollo de la misma se iban haciendo pequeñas pruebas para comprobar el funcionamiento de cada una de las partes desarrolladas, era necesario realizar un plan de pruebas global para verificar el comportamiento de cada una de las partes de la aplicación, del global de la misma, y de su integración con el sistema en su conjunto. El método de comprobación del cumplimiento del plan de pruebas se reforzó con los ensayos del cliente del sistema, que contribuyó en buena medida a detectar problemas ya que contaba con el entorno real en el que el sistema ha de trabajar, además de sus propias simulaciones. Gracias al empeño puesto en el desarrollo del sistema, a la rigurosidad del plan de pruebas al que fue sometido y la aportación de nuestro cliente ha sido posible desarrollar este sistema en su versión más robusta, fiable y eficiente. El plan de pruebas se dividirá en varias partes, cada una enfocada en un módulo por motivos de claridad. La metodología del desarrollo de las pruebas no se basó solamente en comprobar cada módulo por separado sino que también se realizaron pruebas para ensayar aspectos que requerían la cooperación de varios de los módulos realizados (por ejemplo, el envío automático de los informes). Francisco Javier Aguerri Moreno 48 Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras 3.3.1. Instalación e inicio de la aplicación Francisco Javier Aguerri Moreno 49 Tabla 1. Plan de pruebas para la instalación y el módulo de registro REF Proceso Resultado esperado A. 01 Instalación de la aplicación A. 02 Detección de nuevas versiones y actualización A. 03 Configuración automática primer uso A. 04 A. 05 Login con datos erróneos A. 06 Login sin disponer de conexión Imposibilidad de entrar al sistema. A. 07 A. 08 A. 09 A. 10 El sistema muestra la pantalla de login. A. 11 Cerrar sesión (logout). Debe instalarse correctamente, teniendo en cuenta la actualización del número de versión Debe ser capaz de actualizarse automáticamente si existe una versión posterior en el market privado La primera vez que se ejecuta la aplicación, debe ajustar la configuración inicial correctamente Login (registro) de usuario en el sistema. Datos correctos. Se dispone de conexión Envío de los datos de usuario al servidor. Almacenamiento de información de usuario en la base de datos local Detección de pares nombre/contraseña erróneos. Solicitar nuevo par nombre/contraseña Login de usuarios con distintas combinaciones de permisos (alta, iniciar/finalizar, validar) El usuario puede realizar acciones acordes a sus permisos. Por ejemplo, un usuario con permisos de inciar/finalizar tareas y dar de alta tareas podrá realizar dichas acciones pero no validar. Autologin. Hay conexión y hay almacenados datos de usuario. Registro transparente para el usuario. Pasamos directamente al menú principal. Autologin. No hay conexión. Hay datos de usuario almacenados. Mensaje de aviso. Registro en el sistema utilizando la identidad y permisos del usuario guardado en la BD. Autologin.No hay almacenados datos de usuario. Borrado de los datos de usuario de la BD. Posteriormente, al iniciar debe mostrar la pantalla de login (y no realizar un registro automático, ya que no tiene información almacenada) Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras 3.3.2. Lista de tareas 3.3.3. Ficha de tarea Francisco Javier Aguerri Moreno 50 Tabla 2. Plan de pruebas para la lista de tareas REF Proceso Resultado esperado B. 01 B. 02 Botón "refrescar tareas" B. 03 B. 04 B. 05 Desde el menú principal, acceder a la lista de tareas Se accede a la pantalla y se desencadenan las acciones producidas al pulsar el botón "refrescar tareas" Se muestran las 50 primeras tareas almacenadas en nuestra base de datos. Para cada tarea, la información sobre los reportes ya redactados debe ser correcta. Aviso de tabla vacía si es necesario. Botón "actualizar tareas". Configuración: sector seleccionado y uno o varios tramos seleccionados Se actualiza la base de datos local con la información recibida del servidor. Sólo recibimos las tareas correspondientes a nuestro sector y tramos seleccionados, además de que el servidor tampoco nos envía las que ya están validadas. Se desencadenan las acciones producidas al pulsar el botón "refrescar tareas" Botón "actualizar tareas". Configuración: sector seleccionado y ningún tramo seleccionado Igual que el anterior, excepto que el servidor nos envía todas las tareas asociadas al sector seleccionado, sin filtrar por tramos. Botón "actualizar tareas". Configuración: sector no seleccionado. El servidor no nos devuelve información. Por consiguiente, la tabla de la lista de tareas estará vacía. REF Proceso Resultado esperado C. 01 C. 02 C. 03 C. 04 C. 05 Desde la lista de tareas, hacer click en una tarea. Hay conexión. Accedemos a la ficha de dicha tarea. Se muestran todos los detalles correctamente. Desde la lista de tareas, hacer click en una tarea. No hay conexión. Accedemos a la ficha de dicha tarea. Se muestran todos los detalles excepto el mapa de google maps, que no puede cargarse dado que requiere conexión. Tenemos permiso para redactar informes. Todavía no hemos redactado ninguno. Aparece en la parte superior de la pantalla un botón para redactar el informe de iniciación. Tenemos permiso para redactar informes. Hemos redactado el de iniciación pero no el de finalización. Aparecen en la parte superior de la pantalla dos botones, uno para visualizar el reporte de iniciación y otro para redactar el de finalización. El propio usuario ha redactado el informe de iniciación de una tarea. Pulsamos el botón "iniciar actuación" en esa tarea. Se visualiza el informe redactado anteriormente. No se permite realizar ningún cambio ni guardarlo de nuevo. Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras 3.3.4. Informes de iniciación/finalización Francisco Javier Aguerri Moreno 51 Tabla 3. Plan de pruebas para la ficha de tarea C. 06 C. 07 C. 08 C. 09 C. 10 C. 11 C. 11 C. 12 Otro usuario ha redactado el informe de iniciación de una tarea. Pulsamos el botón "iniciar actuación" en esa tarea. El sistema muestra un mensaje notificando que dicho informe ya ha sido redactado por otro usuario. Tenemos permiso para redactar informes. Ambos han sido ya redactados. Aparecen en la parte superior de la pantalla dos botones para visualizar los respectivos reportes. El propio usuario ha redactado el informe de finalización de una tarea. Pulsamos el botón "finalizar actuación" en esa tarea. Se visualiza el informe redactado anteriormente. No se permite realizar ningún cambio ni guardarlo de nuevo. Otro usuario ha redactado el informe de finalización de una tarea. Pulsamos el botón "finalizar actuación" en esa tarea. El sistema muestra un mensaje notificando que dicho informe ya ha sido redactado por otro usuario. Tenemos permiso para validar tareas. Los dos informes de actuación de una tarea (iniciar/finalizar) se han rellenado. Aparece en la parte inferior de la pantalla un botón para validar la tarea. Se pulsa el botón "validar tareas". La tarea no estaba validada. Hay conexión. Se guarda el formulario en la tabla de formularios de la BD. Después se ejecuta el proceso de envío de formularios. Consiste en rescatar de esta tabla todos los datos de los formularios pendientes. Todos aquellos que se guardan correctamente en el servidor actualizan su estado, pasando de "datos pendientes" a "datos enviados", de manera que ya no serán enviados de nuevo posteriormente. Se realiza el mismo proceso para las imágenes pendientes de ser enviadas. Ver diagrama del proceso de envío de formularios. Se pulsa el botón "validar tareas". La tarea no estaba validada. No hay conexión. Se guarda el formulario en la tabla de formularios de la BD, quedando como pendiente. Se pulsa el botón "validar tareas". La tarea ya estaba validada. Se muestra un mensaje notificando que la tarea ya estaba validada. REF Proceso Resultado esperado D. 01 D. 02 Viniendo de la pantalla de la ficha de tarea, entramos en la pantalla de redactar un informe. Hay conexión. Se muestra correctamente el ID de la tarea. Además, aparecen la hora y fecha actuales y la geolocalización (longitud, latitud). El mapa de google maps se encuentra centrado en las coordenadas de nuestra localización. Viniendo de la pantalla de la ficha de tarea, entramos en la pantalla de redactar un informe. No hay conexión. Se muestra correctamente el ID de la tarea. Además, aparecen la hora y fecha actuales. No aparece la geolocalización ni el mapa de google. Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras 3.3.5. Alta de tareas Francisco Javier Aguerri Moreno 52 REF Proceso Resultado esperado E. 01 E. 02 E. 03 Entramos en la pantalla de altas de nuevas tareas. Hay conexión. Se muestran todas las opciones y menús desplegables. Además, aparecen la hora y fecha actuales y la geolocalización (longitud, latitud). El mapa de google maps se encuentra centrado en las coordenadas de nuestra localización. Entramos en la pantalla de altas de nuevas tareas. No hay conexión. Se muestran todas las opciones y menús desplegables. Además, aparecen la hora y fecha actuales. No aparece la geolocalización ni el mapa de google. Seleccionamos un sector en el menú desplegable correspondiente. Se activa el menú desplegable ″contrato″. El campo provincia muestra el dato correspondiente. Los campos ″protocolo general del sector″ y ″protocolo específico″ muestran la información correspondiente. Tabla 4. Plan de pruebas para la redacción de informes D. 03 Pulsar el botón ″capturar nueva imagen″. D. 04 Pulsar el botón ″cargar imagen del álbum″. D. 05 Pulsar el botón ″quitar imagen″. D. 06 D. 07 D. 08 Pulsar el botón ″enviar″ Se abre la aplicación nativa de la cámara. Tomamos una fotografía y al cerrar la aplicación de cámara volvemos a nuestra aplicación. La imagen ahora se muestra en grande. Las imágenes adjuntadas previamente se muestran como miniatura. Se abre la aplicación nativa de la galería de imágenes. Escogemos una imagen y al cerrar la aplicación de galería volvemos a nuestra aplicación. La imagen ahora se muestra en grande. Las imágenes adjuntadas previamente se muestran como miniatura. La imagen mostrada en primer plano se desancla de nuestro formulario (no se elimina de memoria pero ya no está adjunta al formulario). No será enviada al servidor. Hacer click sobre alguna de las miniaturas de las imágenes que tengamos adjuntas. Dicha imagen pasa a mostrarse en primer plano, y la que estaba antes en grande se muestra sólo como miniatura. Añadir más imágenes cuando tenemos ya tres adjuntas. Se muestra un mensaje informando de la imposibilidad de adjuntar más de 3 imágenes por formulario. Se guarda el formulario en la tabla de formularios de la BD. Después se ejecuta el proceso de envío de formularios. Ver diagrama del proceso de envío de formularios. Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras Francisco Javier Aguerri Moreno 53 Tabla 5. Plan de pruebas para la realización de informes E. 04 E. 05 Se activa el menú desplegable ″tipo″. E. 06 E. 07 E. 08 E. 09 E. 10 E. 11 Menú desplegable ″fuente de información″ E. 12 Pulsar el botón ″capturar nueva imagen″. E. 13 Pulsar el botón ″cargar imagen del álbum″. E. 14 Pulsar el botón ″quitar imagen″. E. 15 E. 16 E. 17 Pulsar el botón ″enviar″ Deseleccionamos el sector que tuviéramos en el menú desplegable (elegimos la opción ″seleccione una opción″). El menú desplegable ″contrato″ pasa a no tener ninguna opción seleccionada y se desactiva. Los campos ″protocolo general del sector″ y ″protocolo específico″ se vacían (muestran ″No hay protocolo designado″). Seleccionamos una clase en el menú desplegable correspondiente. Seleccionamos un tipo en el menú desplegable correspondiente. Se activa el menú desplegable ″subtipo″. El campo ″actuación fundamental″ muestra la información correspondiente. Seleccionamos un subtipo en el menú desplegable correspondiente Los campos ″plazo para finalizar actuación″ y ″fecha y hora para finalizar actuación″ muestran la información correspondiente. Deseleccionamos el subtipo que tuviéramos en el menú desplegable (elegimos la opción ″seleccione una opción″). Los campos ″plazo para finalizar actuación″ y ″fecha y hora para finalizar actuación″ se vacían. Deseleccionamos el tipo que tuviéramos en el menú desplegable (elegimos la opción ″seleccione una opción″). El menú desplegable ″subtipo″ pasa a no tener ninguna opción seleccionada y se desactiva. El campo ″actuación fundamental″ se vacía. Deseleccionamos la clase que tuviéramos en el menú desplegable (elegimos la opción ″seleccione una opción″). El menú desplegable ″tipo″ pasa a no tener ninguna opción seleccionada y se desactiva. Se muestran sólo las opciones acordes al rol del usuario registrado. Se abre la aplicación nativa de la cámara. Tomamos una fotografía y al cerrar la aplicación de cámara volvemos a nuestra aplicación. La imagen ahora se muestra en grande. Las imágenes adjuntadas previamente se muestran como miniatura. Se abre la aplicación nativa de la galería de imágenes. Escogemos una imagen y al cerrar la aplicación de galería volvemos a nuestra aplicación. La imagen ahora se muestra en grande. Las imágenes adjuntadas previamente se muestran como miniatura. La imagen mostrada en primer plano se desancla de nuestro formulario (no se elimina de memoria pero ya no está adjunta al formulario). No será enviada al servidor. Hacer click sobre alguna de las miniaturas de las imágenes que tengamos adjuntas. Dicha imagen pasa a mostrarse en primer plano, y la que estaba antes en grande se muestra sólo como miniatura. Añadir más imágenes cuando tenemos ya tres adjuntas. Se muestra un mensaje informando de la imposibilidad de adjuntar más de 3 imágenes por formulario. Se guarda el formulario en la tabla de formularios de la BD. Después se ejecuta el proceso de envío de formularios. Ver diagrama del proceso de envío de formularios. Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras 3.3.6. Opciones Francisco Javier Aguerri Moreno 54 REF Proceso Resultado esperado F. 01 Entramos en la pantalla de opciones. F. 02 F. 03 F. 04 F. 05 F. 06 F. 07 F. 08 F. 09 Modo de transmisión de imágenes ON. F. 10 El sistema muestra la pantalla de login. F. 11 Se muestran todos los menús desplegables y campos correctamente. Hacer click en el botón ″Cerrar sesión″ (logout). Se muestra un mensaje preguntando si se está seguro de querer cerrar sesión. Borrado de los datos de usuario de la BD. Posteriormente, al iniciar debe mostrar la pantalla de login (y no realizar un registro automático, ya que no tiene información almacenada) Hacer click en el botón ″Borrar reportes y tareas″. Deben de eliminarse todos aquellos formularios que ya hayan sido enviados con éxito al servidor. Además, también debe vaciarse la lista de tareas. Hacer click en el botón ″Borrado maestro″. Realiza un reseteo de la aplicación. Borra todos los contenidos de la base de datos y restaura la configuración de fábrica. Hacer click en el botón ″Cargar base de datos – alta″. Pide al servidor la información relativa a las altas de nuevas tareas (contratos, clases, tipos, carreteras, protocolos... etc) y las almacena en las correspondientes tablas de la BD. Al dar de alta una nueva tarea, las opciones se muestran actualizadas. Hacer click en el botón ″Enviar formularios pendientes″. Se activa el proceso de envío de formularios. No se muestra ningún mensaje hasta el final, cuando se nos indicará si se han producido errores en alguno de los formularios pendientes. Seleccionar un sector en el menú desplegable correspondiente. Cuando actualicemos la lista de tareas, el servidor nos enviará las tareas asociadas a dicho sector. Seleccionar uno o varios tramos en el menú desplegable correspondiente. Cuando actualicemos la lista de tareas, el servidor nos enviará las tareas asociadas a los tramos seleccionados del sector seleccionado. Las imágenes adjuntas a los formularios sólo tratarán de ser enviadas al servidor si existe una conexión rápida (wifi) Activar actualización automática de tareas ON. Seleccionar un sector en el menú desplegable correspondiente. Cuando actualicemos la lista de tareas, el servidor nos enviará las tareas asociadas a dicho sector. Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras 3.4. Elementos de apoyo a la aplicación Aunque el elemento principal del proyecto es la aplicación móvil, hay elementos adicionales que la apoyan y junto con ésta, conforman un sistema integrado. 3.4.1. Servidor Ya hemos comentado anteriormente que nuestro sistema se basa en una arquitectura cliente-servidor. Aunque hasta ahora nos hayamos centrado en la aplicación (lado cliente) por ser el elemento central del sistema, merece la pena también comentar algunos aspectos del servidor. El servidor está basado en la tecnología Apache y programado en el lenguaje PHP. Así mismo, gestiona una base de datos perteneciente al sistema MySQL. Cabe decir que aunque la programación final del servidor no ha sido realizada por el autor de este proyecto, sí lo fue la programación del servidor de pruebas durante el desarrollo de la aplicación. Esto tiene que ver con la metodología de trabajo en la empresa Iternova S.L., según la cual todos los módulos del servidor deben estar integrados en el sistema SGWC para lo cual se sigue un formato, metodología y documentación concretos. Francisco Javier Aguerri Moreno 55 Tabla 6. Plan de pruebas para las opciones de configuración F. 12 F. 13 Modo de transmisión de imágenes ON. F. 14 Actualización automática de tareas ON. F. 15 Envío automático de formularios ON. F. 16 F. 17 Modo de transmisión de imágenes ON. F. 18 Resolución de imágenes capturadas Seleccionar uno o varios tramos en el menú desplegable correspondiente. Cuando actualicemos la lista de tareas, el servidor nos enviará las tareas asociadas a los tramos seleccionados del sector seleccionado. Las imágenes adjuntas a los formularios sólo tratarán de ser enviadas al servidor si existe una conexión rápida (wifi) Se realizará una actuación automática de la lista de tareas cada X minutos, siendo X la frecuencia seleccionada en la opción correspondiente. Ver diagrama del proceso de actualización automática de la lista de tareas. Se realizará un envío automático de los formularios pendientes cada X minutos, siendo X la frecuencia seleccionada en la opción correspondiente. Ver diagrama del proceso de envío de formularios. Seleccionar uno o varios tramos en el menú desplegable correspondiente. Cuando actualicemos la lista de tareas, el servidor nos enviará las tareas asociadas a los tramos seleccionados del sector seleccionado. Las imágenes adjuntas a los formularios sólo tratarán de ser enviadas al servidor si existe una conexión rápida (wifi) Según la opción elegida, las imágenes capturadas por la cámara tendrán una cierta resolución. Capítulo 3. DESARROLLO DE LA APLICACIÓN Desarrollo de aplicación móvil para gestión de carreteras Sin embargo, como ya se ha comentado la programación funcional del servidor sí que fue realizada por el autor del proyecto, y todas las decisiones acerca de cómo debía interaccionar con la aplicación fueron tomadas por él. Con esto queda patente que este proyecto engloba también la parte servidor, lo que le da una dimensión más amplia que la de la programación de una aplicación. 3.4.2. Control de versiones y actualizaciones En el momento en el que se tuvo una versión apta para comenzar a realizar las pruebas en el sistema fue necesario implementar un control de versiones que nos permitiera trazar una evolución de la aplicación y controlar qué errores habían sido corregidos. Para agilizar el proceso de actualización a última versión, debido a que se va a instalar en muchos dispositivos móviles (por ejemplo, en la carretera de Sinaloa va a haber unos 50 residentes con tablet), se utilizó un servicio on-line de gestión de versiones muy sencillo de utilizar (un market privado). Se ha integrado una extensión en la aplicación para permitir la auto-actualización mediante market privado, así como para facilitar la instalación, lo que permitirá en el futuro añadir nuevas funcionalidades de forma rápida. El desarrollador puede subir a la web la última versión de su aplicación, y ésta misma aparecerá junto a un código BIDI13 el cual permite que un usuario que disponga de un lector de estos códigos pueda descargar e instalar la aplicación. Además, una vez descargada la primera vez, la aplicación comprueba con cierta frecuencia si existen nuevas actualizaciones a la misma en dicho servicio, de tal manera que no es necesario comprobar manualmente si existen actualizaciones sino que esto se realiza de manera automática. Se ha usado un market privado ya que el sistema de gestión web es propio de una empresa en particular, y solo usuarios registrados en dicha plataforma van a tener acceso al sistema. 3.4.3. Ficheros de configuración y librerías Además de la información dinámica que se carga automáticamente desde el servidor web (ya sea al registrarse por primera vez como de forma periódica), se han incluido los parámetros de configuración de la aplicación en ficheros de configuración. Esto facilita las tareas de mantenimiento y reutilización de la aplicación, ya que en estos ficheros se puede almacenar, por ejemplo, la URI del servidor web, o parámetros de personalización. También se ha realizado un fichero a modo de librería, que contiene las funciones más comunes desarrolladas específicamente para la aplicación pero que podrían ser reutilizadas en sistemas similares. 13 Los códigos bidimensionales (abreviadamente códigos BiDi), son un sistema gráfico creado para almacenar información. Constituyen la evolución natural de los conocidos códigos de barras, que sólo pueden guardar 20 caracteres, pasando de emplear sólo una dimensión a emplear dos dimensiones: una matriz de pequeños cuadrados que pueden ser blancos o negros. De este modo, se consigue una capacidad de almacenamiento 100 veces mayor y una mejor protección frente a errores de lectura. Francisco Javier Aguerri Moreno 56 Desarrollo de aplicación móvil Capítulo 3. DESARROLLO DE LA APLICACIÓN para gestión de carreteras 3.5. Problemas planteados durante el desarrollo del proyecto Han sido numerosos los problemas que han aparecido durante el transcurso de este proyecto fin de carrera. Aunque los problemas han sido de diversa naturaleza, casi todos han tenido un denominador común: la inexperiencia en los lenguajes de programación utilizados. Y como también es lógico, estos problemas se hacían menos graves al final del desarrollo, cuando el manejo de las tecnologías había alcanzado un nivel aceptable. Las principales dificultades encontradas son: •Manejo de múltiples lenguajes de programación a la vez, cuyo desconocimiento era prácticamente total al comienzo del proyecto. Aunque ya se ha comentado que ésta era la raíz de muchos otros problemas posteriores, es también una dificultad en sí misma en el sentido de que la comprensión de todos los conceptos y metodologías fue un importante escollo que resolver y fue necesaria una gran cantidad de tiempo para progresar. •Problemas de incompatibilidad y ″bugs″14. En ocasiones se han enfrentado problemas que, en principio, parecían no tener solución. Al cabo del tiempo, tras muchas indagaciones (en ocasiones incluso de varios días) se concluyó que eran errores de incompatibilidad entre las tecnologías y API's15 utilizadas. De esta manera se trató de realizar la misma tarea que se pretendía de una manera diferente o actualizar los códigos a la última versión. Ejemplos de esto fue la imposibilidad de añadir parámetros al tratar de cambiar a otra URL en sistemas Android. También hubo dificultades a la hora de trabajar en el servidor de pruebas dado que existían problemas con los certificados SSL del mismo. •Problemas en los dispositivos de pruebas. En uno de los dispositivos en el cual se realizaron pruebas de la aplicación se presentaban varios problemas de funcionamiento, que no tenían su raíz en la aplicación desarrollada sino en algún problema de dispositivo. Éste fue el caso del envío de imágenes al servidor, lo cual no era posible desde uno de los tablets que se usaron para las pruebas, lo cual causó un considerable problema al pensar que se trataba de un error en el código cuando no era así realmente. •Errores de concepto en el desarrollo de la aplicación. Éste fue un problema derivado de la falta de perspectiva de lo que tenía que ser la aplicación, por lo que el sistema se comportaba de maneras no esperadas. Esta dificultad se mostró a la hora de probar la aplicación (hubo que hacer sustanciales cambios) y al entregar las primeras versiones a nuestro cliente. Tras una serie de correcciones por parte de éste, el autor llegó a la conclusión de que tomaría menos tiempo realizar un completo rediseño de la aplicación, aprovechando los códigos que valiesen la pena, los conocimientos adquiridos y, sobre todo, la visión global de lo que tenía que ser la aplicación. Esta decisión se reveló un éxito ya que, en menos de dos semanas la aplicación estaba lista de nuevo y esta vez, tras unas últimas correcciones, funcionaba correctamente. 14 Error del programa 15 Application Programming Interface, interfaz de programación de aplicaciones. es el conjunto de métodos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Francisco Javier Aguerri Moreno 57 Desarrollo de aplicación móvil BIBLIOGRAFÍA para gestión de carreteras Bibliografía jQuery [1] http://docs.jquery.com/Main_Page [2] http://www.javascriptya.com.ar/jquery/ jQuery Mobile [3] http://jquerymobile.com/ [4] http://www.ibm.com/developerworks/xml/tutorials/x-jquerymobilejsontut/xjquerymobilejsontut-pdf.pdf PhoneGap [5] http://docs.phonegap.com/en/2.0.0/index.html Android [6] http://www.androidhive.info/ [7] http://code.google.com/p/android/issues/list HTML [8] http://roble.pntic.mec.es/apuente/html/paginas/resumen.htm [9] http://html.conclase.net/tutorial/html/ JavaScript [10] http://www.librosweb.es/javascript/ [11] http://www.javascriptya.com.ar/ [12] http://www.w3schools.com/js/default.asp AJAX [13] http://www.librosweb.es/ajax/ [14] http://www.ajaxya.com.ar/ SQL [15] http://www.w3schools.com/sql/default.asp Francisco Javier Aguerri Moreno 65 BIBLIOGRAFÍA Desarrollo de aplicación móvil para gestión de carreteras CSS [16] http://www.librosweb.es/css/ PHP [17] http://www.uca.es/softwarelibre/publicaciones/apuntes_php [18] http://www.php.net/ [19] http://www.calitae.com/manuales/manual-php.pdf jQuery Mobile Plugin for Google Map [20] http://www.mobiledevelopersolutions.com/home/download/demos-and-tutorials [21] http://www.mobiledevelopersolutions.com/home/start/twominutetutorials/tmt0 [22] http://www.mobiledevelopersolutions.com/home/start/ twominutetutorials/tmt4part1 Foros de consulta [23] http://stackoverflow.com/ 66 Francisco Javier Aguerri Moreno Anexo A. Manual de usuario de la agenda de vialidad (versión móvil) En este primer anexo se presenta el manual de usuario elaborado con el fin de detallar el funcionamiento y las posibilidades de la aplicación pensando en el usuario final. Desarrollo de aplicación móvil Anexo A. Manual de usuario de la agenda de para gestión de carreteras vialidad (versión móvil) A.1. Introducción La aplicación ″Agenda de vialidad″ ha sido desarrollada para permitir su correcta visualización en cualquier tipo de dispositivo (ordenador, tablet o móvil), ya que cuenta con una versión móvil con funcionalidades específicas para permitir la introducción de las actividades realizadas por los operarios en el mismo lugar en el que realizan una acción. Por ejemplo, pueden dar de alta nuevas tareas en el sistema, incorporando automáticamente toda la información asociada como fotografías, localización u otros datos. La versión optimizada para dispositivos móviles (tablets y smartphones) será el objeto de este manual de usuario, y cuenta con las siguientes características: •Compatible para diferentes modelos de dispositivo. •Optimizada para minimizar los tiempos de carga, y agilizar el el uso de la aplicación por parte del usuario en entornos remotos. •Se tienen en cuenta los problemas de límites de ancho de banda y cobertura de las redes móviles, disponiendo de los mecanismos oportunos para agilizar la velocidad de la aplicación y evitar la pérdida de información por falta de cobertura. Respecto a la cobertura, la aplicación dispone de todos los elementos necesarios para permitir trabajar con ella aún cuando ésta no exista (de forma autónoma), volviendo a sincronizar la información con los servidores cuando la cobertura vuelva a estar disponible, de forma que se garantice la continuidad del funcionamiento sin perjuicio alguno para el usuario. La aplicación permite a los operarios la actualización instantánea de las tareas en el mismo momento en que proceden a su actuación, al mismo tiempo que se controla la posición exacta en la que se encuentra, posibilitando el seguimiento de la resolución de las tareas por parte de la empresa para mantener el control sobre las actuaciones realizadas. El módulo de agenda móvil es similar al que se puede observar en su versión extendida (para plataforma web), aunque está orientado a la introducción de información (y no a la consulta de informes). A.2. Opciones del usuario A.2.1. Acceso a la aplicación (login) Al ejecutar la aplicación en el dispositivo móvil se muestra la pantalla de entrada en la que se deben ingresar los datos del usuario registrado (login/paswword). Francisco Javier Aguerri Moreno 71 Anexo A. Manual de usuario de la agenda de Desarrollo de aplicación móvil vialidad (versión móvil) para gestión de carreteras Si los datos son correctos, desde ese momento el usuario (operario) podrá acceder a las opciones que, según los permisos asignados a ese usuario, tenga disponibles: ●Ver los registros de tareas asignadas ●Registrar una actuación ●Iniciar / finalizar una actuación ●Validar tareas Además, se guardan los datos del usuario en la base de datos del móvil, de manera que cuando cierre o minimice la aplicación no se le vuelva a solicitar los datos de usuario (sólo se le vuelve a solicitar cuando el usuario cierra la sesión desde el menú de configuración). A.2.2. Inicialización y configuración de la aplicación La primera vez que se ejecuta la aplicación el usuario debe hacerlo asegurándose de que dispone de conexión a Internet. Al registrarnos por primera vez aparecen los siguientes mensajes: Francisco Javier Aguerri Moreno 72 Figura 17. Pantalla inicial Figura 18. Formulario de registro de usuario Desarrollo de aplicación móvil Anexo A. Manual de usuario de la agenda de para gestión de carreteras vialidad (versión móvil) Simplemente dejamos que la aplicación haga su trabajo, y al finalizar con éxito observaremos el mensaje: Francisco Javier Aguerri Moreno 73 Figura 20. Configuración automática inicial (2)Figura 19. Configuración automática inicial (1) Figura 21. Configuración automática inicial (3) Figura 22. Menú principal Anexo A. Manual de usuario de la agenda de Desarrollo de aplicación móvil vialidad (versión móvil) para gestión de carreteras Para validar una tarea, deberemos acceder a la pantalla de “Ver detalle de tarea”. Bajo la información de la tarea se muestra, en caso de haber rellenado los informes de iniciación y finalización, el botón “Validar”. Pulsamos el botón y si disponemos de conexión, el servidor registrará esta validación. Si no, la aplicación tratará de reenviar la petición en otro momento como en el caso de los otros informes. A.2.4. Dar de alta incidencias Los operarios que dispongan del permiso necesario pueden dar de alta nuevas incidencias en el sistema. Para ello, desde el menú de la pantalla inicial se deberá pulsar el botón “Dar de alta inicidencia“. Al pulsarlo se accede al formulario con el que ingresar los datos de la incidencia (todas las imágenes que se muestran a continuación pertenecen a una misma pantalla con el formulario de ingreso de datos de la incidencia): Francisco Javier Aguerri Moreno 80 Figura 35. Ficha de tarea. Botón de validar Figura 36. Alta de nueva tarea (1) Figura 37. Alta de nueva tarea (2) Desarrollo de aplicación móvil Anexo A. Manual de usuario de la agenda de para gestión de carreteras vialidad (versión móvil) Con la ayuda del formulario irá ingresando la información: •Primero deberá ingresar los datos completos del segmento y carretera de la que se trata con la ayuda de los desplegables y el resto de campos destinados a tal efecto. •Podrá añadir imágenes, bien tomadas en ese momento o seleccionándolas de un repositorio (máximo 3 en cada formulario). •Deberá seleccionar el tipo de agente que registra la incidencia •Dependiendo del tipo de incidencia se muestra la actuación a llevar a cabo (acción fundamental y protocolo específico). •Podrá añadir las observaciones que considere oportunas. •Finalmente, dependiendo del tipo de incidencia y de la carta de servicios se especificarán las fechas en las que se debe finalizar la actuación. Hay que remarcar que los campos marcados con el símbolo '*' deben ser rellenados obligatoriamente (de otro modo no podremos enviar la información). Al pulsar el botón “Enviar” se tratará de enviar la información al servidor siguiendo el mismo procedimiento visto en los anteriores casos, es decir, gestionando adecuadamente los casos de ausencia de conexión. Francisco Javier Aguerri Moreno 81 Anexo B.Elementos clave del código de la aplicación En este anexo comentaremos los puntos de la aplicación fundamentales para comprender su funcionamiento sin entrar en detalles de desarrollo demasiado técnicos. Estos elementos clave serán las bases de datos, la caché local del navegador, y algunas funciones empaquetadas para la aplicación y ampliamente utilizadas. Desarrollo de aplicación móvil Anexo B. Elementos clave del código para gestión de carreteras de la aplicación B.1. Base de datos SQLite es el motor de bases de datos elegido por los desarrolladores de Android ya que ofrece características tan interesantes como su pequeño tamaño, no necesitar servidor, precisar poca configuración, ser transaccional y por supuesto ser de código libre. Android incorpora de serie todas las herramientas necesarias para la creación y gestión de bases de datos SQLite, y entre ellas una completa API para llevar a cabo de manera sencilla todas las tareas necesarias. Sin embargo no entraremos en los detalles sino que en la presente sección se expondrá la estructura de la base de datos que se ha implementado para el desarrollo del sistema. B.1.1. Tabla de usuarios Primeramente se presenta la más sencilla de las tablas, aquella que recoge la información del usuario registrado. Hemos de recordar (si se necesita más información, consultar el apartado 3.2.1. Registro y salida en el sistema) que esta tabla nunca almacenará la información relativa a más de un usuario por motivos de seguridad. Por tanto, en esta tabla siempre habrá registrado uno o ningún usuario. Como podemos observar, la información almacenada consta de tres campos: •login: es el nombre de usuario. •password: la contraseña del mismo. •remote: éste es un parámetro que en el caso de la aplicación móvil siempre vale el string ″tareas″. La información de esta tabla es consultada cada vez que se inicia la aplicación. Si existe algún usuario guardado, se envía al servidor su información automáticamente sin tener que pasar por el formulario de registro. Esto se conoce como ″guardar la sesión″ o "login automático" y contribuye a la agilidad de la aplicación. B.1.2. Tabla de reportes de actuación A continuación se verá la tabla donde se almacena toda la información relativa a los informes relativos a las tareas (iniciación, finalización y validación). Francisco Javier Aguerri Moreno 85 Tabla 7. Usuarios USUARIOS login password remote Tabla 8. Informes de actuación TAREAS rep_id ini_fin datos_ok comments date time lat lng img_image1 img_image2 img_image3 hay_img img_ok Anexo B. Elementos clave del código Desarrollo de aplicación móvil de la aplicación para gestión de carreteras •rep_id: identificador de tarea. Se trata de un número asignado a cada tarea de manera exclusiva (cada tarea tiene un número distinto) para identificarla, por lo que si tenemos varios informes (iniciación, finalización y validación) sobre la misma tarea, todos ellos tendrán el mismo identificador. •ini_fin: marcador de tipo de informe. Puede tomar valores ″ini″ (si es un reporte de iniciación), ″fin″ (finalización) y ″validar″ (si se trata de una validación). •datos_ok: registro de estado del envío de datos. Si este campo vale false, quiere decir que los datos del correspondiente formulario no han sido recibidos correctamente en el servidor, y por tanto el sistema tratará de reenviar este informe cuando corresponda. Si vale true, significa que los datos han llegado con éxito al servidor. •comments: comentarios adicionales añadidos por el usuario en el formulario. •date y time: fecha y hora en la que el informe fue redactado. Para evitar el falseamiento de esta información, son tomados automáticamente por el dispositivo y no se permite su modificación. •lat y lng: coordenadas de geolocalización (latitud, longitud). Son también tomadas automáticamente por el dispositivo. •img_imageX: estos tres campos almacenan la ruta y nombre (en el sistema de archivos local) de las imágenes adjuntas al reporte. Sirve para poder visualizar estas imágenes junto con el resto del informe posteriormente, además de para poder transferirlas. •hay_img: registro de estado que indica si en el correspondiente informe se incluye, al menos, una imagen. En caso de que no haya imágenes adjuntas este campo valdrá false, de otro modo valdrá true. •img_ok: registro de estado cuya función es similar a ″datos_ok″, pero relativo a las imágenes. Indica, por tanto, si las imágenes asociadas al reporte correspondiente han sido correctamente recibidas en el servidor (true) o si será necesario enviarlas posteriormente (false). La necesidad de dos registros de estado (uno para datos y otro para imágenes) viene impuesta por la separación en la transmisión de ambos elementos, ya que la transmisión de datos es más prioritaria y no requiere consideraciones aplicables a la transmisión de imágenes. Francisco Javier Aguerri Moreno 86 Desarrollo de aplicación móvil Anexo B. Elementos clave del código para gestión de carreteras de la aplicación B.1.3. Tabla de nuevas tareas En esta tabla quedarán registradas todas aquellas tareas que damos de alta rellenando el formulario correspondiente. Como podemos observar, esta tabla contiene gran cantidad de campos ya que describe todos los detalles necesarios para dar de alta una nueva tarea en el servidor. •new_id: es un identificador local de la tarea, pero no tendrá ninguna validez en el servidor. •tareaID: es el identificador de tarea que aparecerá en la lista de tareas. Es exclusivo de cada tarea. •descripción: detalles adicionales de la tarea. •fecha_conocimiento: fecha tomada automáticamente al dar de alta una nueva incidencia. •datos_ok: registro de estado cuya función es la misma que en el apartado anterior (B.1.2. Tabla de reportes de actuación). •bloqueID: identificador de bloque. Bloque es la distinción entre las tareas programables y no programables (sólo damos de alta las no programables). •sectorID: identificador de sector. Los sectores son las unidades en las que se divide la carretera. •contratoID: identificador del contrato que regula la gestión de la carretera. •claseID: identificador de la clase de la nueva incidencia. •tipoID: identificador del tipo de la nueva incidencia. •subtipoID: identificador del subtipo de la nueva incidencia. •provincia: nombre de la provincia donde se originó la incidencia. •carreteraID: identificador de la carretera donde se originó la incidencia. •calzadaID: identificador de en qué plataforma (derecha, izquierda, mediana) se Francisco Javier Aguerri Moreno 87 Tabla 9. Alta de nuevas tareas NUEVAS TAREAS new_id tareaID descripcion fecha_conocimiento datos_ok bloqueID sectorID contratoID claseID tipoID subtipoID provincia carreteraID calzadaID PKinicial PKfinal fuente_informacion plazo_llegada fecha_llegada actuaciones_complementarias observaciones proc_gen proc_esp latitud longitud zoom img_image1 img_image2 img_image3 userID_alta ambitoID ladoID orientacionID hay_img img_ok Anexo B. Elementos clave del código Desarrollo de aplicación móvil de la aplicación para gestión de carreteras originó la incidencia. •PKinicial: punto kilométrico del inicio de la incidencia. •PKfinal: punto kilométrico del final de la incidencia. •fuente_informacion: indica quién informó de la incidencia. •plazo_llegada: tiempo disponible (minutos) para realizar las actuaciones necesarias. Ese tiempo comienza a consumirse en cuanto se da de alta la tarea. •fecha_llegada: fecha y hora en la que el operario deberá tener finalizada la actuación. Equivale a fecha_conocimiento + plazo_llegada. •actuaciones_complementarias: protocolo de actuación establecido para una clase, tipo y subtipo. •observaciones: otra información a aportar por el operario. •proc_gen: procedimiento general de actuación del sector en el que se originó la incidencia. •proc_esp: procedimiento específico de actuación asignado a un sector y un contrato. •latitud y longitud: coordenadas de geolocalización de la incidencia. •zoom: nivel de zoom con el que aparecerá el mapa de Google Maps que muestra la situación de la incidencia en la ficha de la lista de tareas. •img_imageX: imágenes asociadas a la nueva incidencia. Guardan el nombre y la ruta de las imágenes para poder ser enviadas más tarde. •userID_alta: identificador del usuario que da de alta la incidencia. •ambitoID: identificador del ámbito. •ladoID: identificador del lado. •orientacionID: identificador de la orientación. Junto con el ámbito y el lado, conforma la georeferencia transversal. •hay_img: registro de estado que vale true si alguno de los campos img_imageX contiene la ruta de una imagen. Vale false si todos los campos están vacíos (es decir, el formulario no tiene imágenes adjuntas). •img_ok: registro de estado que indica si las imágenes han sido correctamente enviadas al servidor. B.1.4. Tabla de la lista de tareas Esta será la tabla que almacena la lista de tareas que nos llega del servidor. Es la que contiene una mayor cantidad de campos ya que es la que más información necesita almacenar. Muchos campos son idénticos a los del apartado anterior (B.1.3. Tabla de alta de nuevas tareas) y por tanto sólo se comentarán aquellos que no estuvieran presentes en dicho apartado. •inicio_actuacion: registro de estado que vale true si la incidencia había sido iniciada cuando descargamos la lista del servidor por última vez. Francisco Javier Aguerri Moreno 88 Desarrollo de aplicación móvil Anexo B. Elementos clave del código para gestión de carreteras de la aplicación •periodo_transcurrido: minutos que han pasado desde la fecha de conocimiento hasta el momento actual. •dif_temporal: control relativo a las diferencias horarias para evitar manipulaciones por parte de los usuarios. En pruebas (sin implementar). •comprobacion_presencia: verificación de presencia física en la realización de la tarea. En pruebas (sin implementar). •userID_baja: identificador del usuario que finalizó la tarea. •fin_actuacion: registro de estado que vale true si la incidencia había sido finalizada cuando descargamos la lista del servidor por última vez. •calzada: texto que nombra la parte de la vía en la que sucedió la incidencia (derecha, izquierda, mediana...). •validada: registro de estado que vale true si la incidencia había sido validada cuando descargamos la lista del servidor por última vez. •pk_hito_ini: hito kilométrico inicial. •pk_dst_hito_ini: distancia al hito kilométrico inicial. •pk_hito_fin: hito kilométrico final. •pk_dst_hito_fin: distancia al hito kilométrico final. •tipo: texto que nombra el tipo de incidencia. Esta información se complementa con su identificador (tipoID). •bloque: texto que nombra el bloque de la incidencia. Esta información se complementa con su identificador (bloqueID). •clase: texto que nombra la clase de incidencia. Esta información se complementa con su identificador (claseID). •contrato: texto que nombra el contrato que regula la explotación de la carretera donde sucedió la incidencia. Esta información se complementa con su identificador (contratoID). •sector: texto que nombra el sector donde sucedió la incidencia. Esta información se complementa con su identificador (sectorID). •permissionID: identificador de los permisos de los usuarios que pueden actuar sobre la incidencia. Generalmente se relaciona con el sector. •carretera: texto que describe el sector donde sucedió la incidencia. Esta información se complementa con su identificador (sectorID). •antelacion_aviso: indicador relativo a las tareas programadas. Sirve para mostrar un aviso antes de que aparezca la tarea programada. •fecha_inicial: indicador relativo a las tareas programadas. Fecha en la que se realizó la programación de la tarea. •modo_repeticion: indicador relativo a las tareas programadas. Frecuencia con la que se repite una tarea programada (anual, mensual...). •img_rep_ini_status y img_rep_fin_status: registros de estado que controlan si Francisco Javier Aguerri Moreno 89 Anexo B. Elementos clave del código Desarrollo de aplicación móvil de la aplicación para gestión de carreteras zoom: nivel de zoom que mostrará el mapa creado. Francisco Javier Aguerri Moreno 96