PROCEDURES:

El cliente recolector es un módulo que fue diseñado específicamente para ejecutarse en un dispositivo móvil y con la capacidad de poder realizar la reco- lección de datos sin la necesidad de una conexión a internet. De todas maneras la conexión a internet es necesaria para poder enviar los datos, pero esta acción se puede postergar ya que no es necesario realizarla durante la recolección de los datos.

A continuación se detalla el proceso diseñado para permitir el funcionamiento offline del cliente recolector. Luego el lector se encontrará con una sección que detalla las diferentes tecnologías que se utilizaron.

4.2.4.1. Recolección de datos Para poder implementar la recolección de datos desde un dispositivo móvil, sin que este requiera una conexión permanente a internet se siguió la estrategia de utilizar puntos de sincronización cuando se cuente con acceso a internet.

El proceso de sincronización está dividido en dos operaciones. La primer operación es capaz de proveer al dispositivo de todas las definiciones existentes en el servidor. Con estas definiciones el dispositivo puede mostrar los formu- larios en pantalla. Los datos que el usuario cargue en este formulario serán almacenados temporalmente en el dispositivo. Aquí entra en juego la segunda operación del proceso de sincronización, esta operación es capaz de enviar los datos almacenados al servidor y luego eliminarlos del dispositivo.

La figura 8 muestra un diagrama de secuencia que ilustra el proceso de sincronización.

Figura 8: Diagrama de secuencia del proceso de sincronización

4.2.4.2. Tecnologías utilizadas

4.2.4.2.1. Comunicación con el Servidor Para establecer la comuni- cación entre el cliente y servidor se analizaron las siguientes alternativas,SOAP

y REST, que permiten integrar o comunicar diferentes componentes o plata- formas. Ambos giran en torno a exponer servicios o recursos. Dichos servicios deben cumplir con ciertos principios de diseño, alta capacidad de reutilización, abstracción, bajo acoplamiento, autonomía, capacidad de composición, contar con un contrato estandarizado como esWSDLparaSOAP, convenciones para el caso deREST. Cualquiera de estas dos alternativas se ajustaban a las nece- sidades que se tenían. Se optó por llevar a cabo la comunicación haciendo uso de serviciosRESTya que se cuenta con más conocimiento en esta tecnología.

4.2.4.2.2. Lenguaje de programación La elección de la plataforma que permitiese desarrollar un cliente capaz de ser ejecutado en la mayoría de los dispositivos móviles disponibles en el mercado fue un verdadero reto. Al ser un ambiente altamente variable, además de realizar el análisis considerando el sistema operativo, en algunos casos resulta importante incluir la versión del mismo.

A manera de ejemplo se puede mencionar la introducción de Material Designen Android 5, lo cual permite que los desarrolladores hagan uso de

nuevos componentes visuales. Si bien es posible mantener la compatibilidad con dispositivos más antiguos, para esto se requiere bastante trabajo adicional.

Luego de un análisis del mercado se llega a la conclusión que solo existen tres sistemas operativos que cuentan con dos características importantes: una gran adopción y buenas perspectivas de crecimiento. Estos tres sistemas operativos sonAndroid®_,iOS®_{yWindows Phone}®_{, los cuales son tan diferentes en-}

tre sí que para poder desarrollar aplicaciones nativas, cada uno de ellos posee su propio lenguaje de programación. Con el fin de maximizar la cantidad de dispo- sitivos soportados y evitar reescribir la misma aplicación para cada plataforma se buscaron otras alternativas.

En auge desde hace unos años, los frameworks para desarrollar aplicaciones móviles híbridas permiten construir aplicaciones capaces de correr en distintos sistemas operativos. La principal desventaja de este tipo de frameworks es que no siempre permiten el acceso a algunas características avanzadas del dispositivo, lo cual no causa un impacto negativo debido a que a priori no se necesitaría hacer uso de estas.

Continuando con el análisis, estos frameworks se pueden agrupar en dos grandes conjuntos, de acuerdo a su manera de funcionar. Por un lado se pueden agrupar los frameworks que permiten escribir la aplicación en un lenguaje co- nocido, como por ejemploJava o Javascript, y luego compilan el código con el fin de generar aplicaciones nativas para las diferentes plataformas soporta- das. En el otro conjunto se pueden agrupar los que permiten empaquetar una aplicación web dentro de una aplicación nativa.

Este último conjunto tiene como referente al proyecto de laApache Foun- dationllamadoApache Cordova40_{el cual es la base de productos comerciales}

como:Ionic®_yPhoneGap®_{(provisto porAdobe}®_{). Dado que este tipo de}

solución requiere desarrollar una aplicación web, se pensó que se podría ex- poner esta aplicación públicamente para que pueda ser accedida por cualquier dispositivo que cuente con un navegador web.

Esta alternativa permite generar aplicaciones nativas paraAndroid,iOSy

Windows Phonea la vez que permite cubrir el resto de los dispositivos que posean un navegador web. Estas razones fueron suficientes para elegirApache Cordovay comenzar con el análisis de los distintos frameworks para el desa- rrollo de una aplicación web de una sola página (Single-Page Applications41 _o

SPAs).

La primera restricción impuesta porApache Cordovaes que la aplicación web a empaquetar debe funcionar solamente con archivos estáticos por lo que no se pueden utilizar frameworks comoEmber.jso React.js, sin embargo se pueden utilizarAngular.jsy Backbone.js.

En este caso se compararon las características entre ambos frameworks sin poder llegar a una conclusión, por lo que se decidió construir una prueba de concepto en donde se utilizó cada framework para generar formularios dinámi- camente a partir de un JSON. Luego de este análisis práctico se arribó a la

40_{Apache Cordovahttps://cordova.apache.org/}

conclusión de queAngular.jsresulta más flexible y ágil para la realización de las tareas necesarias.

En resumen, el cliente recolector se implementó en Angular.js y se em- paqueta como aplicación nativa paraAndroid,iOSoWindows Phoneutili- zandoApache Cordoba.

4.2.4.2.3. Bibliotecas utilizadas Se incorporó el estilo visual provisto porBootstrap, lo que provee el soporte para desarrollar una interfaz respon- siva a la vez que provee un estilo uniforme para los diferentes componentes.

El almacenamiento persistente en el dispositivo se podría realizar utilizando cualquier alternativa como localStorage, IndexedDB o WebSQL. Estas alternativas no se encuentran siempre disponibles, sino que dependen del dispo- sitivo, sistema operativo, etc. Por lo que se decidió incorporarlocalForage42

que es una biblioteca javascript que por medio de una sencilla API permite que uno se abstraiga del tipo de persistencia a utilizar, postergando esta decisión hasta detectar el tipo de dispositivo y qué opciones de almacenamiento exis- ten. En ese momentolocalForage es capaz de elegir la mejor opción según corresponda.

Se optó usar Offline Application Cache provisto por HTML5 para poder publicar elcliente recolector como una aplicación web y que esta pueda funcionar aún sin conexión a internet.

Para acceder a la ubicación geográfica del dispositivo al momento de reco- lectar un dato se decidió crear una interfaz que permite alternar el método de geolocalización a utilizar según cómo esté distribuido el cliente recolector. En caso de utilizarApache Cordovapara empaquetar el cliente en una aplicación nativa, se utilizará la geolocalización provista por el plugin de Apache Cor- dova. En cambio, si el cliente recolector se distribuye como una aplicación web, se utilizará la geolocalización provista por HTML5.

5. Herramienta desarrollada

En este capítulo se detalla la funcionalidad de la aplicación. Esta funciona- lidad ha sido separada en tres etapas que constituyen el flujo de trabajo con el que el usuario normalmente utilizará la aplicación. Estas etapas que se muestran en la figura 9, se describen detalladamente en las secciones 5.1 a 5.3.

Figura 9: Etapas del flujo de trabajo

Además, en la sección 5.4 se describe un conjunto de funcionalidades adi- cionales que posee la herramienta y en la sección 5.5 se detallan los ambientes donde se deployó la herramienta.

5.1. Definición de la información

En este paso un usuario definirá el conjunto de datos que desea asociar a cada ubicación geográfica. Para esto deberá crear un nuevo proyecto, asignándole un nombre y una coordenada inicial. El proyecto podrá contener una o más capas con distinto tipos de información. En cada capa el usuario deberá definir el conjunto de datos a recolectar. Las siguientes dos sub secciones cubren la creación de proyectos y la creación de capas.

5.1.1. Crear proyecto

Para crear un proyecto se deberá presionar el botón "Nuevo proyecto" ubi- cado en la parte superior derecha de la pantalla inicial, como se puede observar en la figura 10.

Figura 10: Botón para crear un proyecto

Esto mostrará el formulario de creación de proyecto, como el de la figura 11, donde se deberá ingresar el nombre del proyecto y de ser necesario se puede seleccionar la zona tentativa de trabajo.

Figura 11: Formulario de creación de proyecto Luego se deberá presionar botón Crear para finalizar la creación.

5.1.2. Crear capa

Para crear una capa se deberá presionar el botón "Agregar capa" en el proyecto deseado (figura 12).

Esto mostrará el formulario de creación de capa (figura 13) que requiere que se ingrese el nombre de la misma, el tipo de geometría que se contendrá, el tipo de marcador que representará a la geometría y la definición de los datos relacionados a recolectar.

Figura 13: Formulario de creación de capa

Para la definición de los datos a recolectar se deberá presionar el botón "Agregar dato a recolectar" que mostrará una ventana emergente con el formu- lario, mostrado en la figura 14, para definir el dato a recolectar.

Figura 14: Formulario de definición de datos

En este formulario se deberá definir el nombre del dato a recolectar, su tipo y en caso de que sea necesario se deberá ingresar alguna información adicional. Por ejemplo, si el tipo de dato es "Opcion", se deberá ingresar las diferentes opciones disponibles al momento de realizar la recolección.

La figura 15 muestra como quedaría una capa definida con 5 campos a reco- lectar de distintos tipos. Para completar la creación se deberá presionar el botón "Aceptar".

Figura 15: Capa definida con 5 datos a recolectar

5.2. Agregar información

En este paso se asocia un dispositivo móvil a una cuenta de usuario con el fin de que ese dispositivo pueda acceder a las definiciones de las capas, utilizar estas definiciones para recolectar datos y luego realizar el envío de esos datos recolectados.

Las siguientes sub secciones cubren estas tareas con más detenimiento.

5.2.1. Registrar dispositivo

La primera vez que se ejecute el cliente recolector en un dispositivo móvil se mostrará un mensaje conteniendo un identificador para ese dispositivo (figura 16).

Figura 16: Mensaje que se muestra la primera vez

El identificador del dispositivo es un dato requerido para asociar el dispositi- vo al usuario en el cliente administrador. Para realizar esta asociación se deberá ir a la sección "Dispositivos" presionando el botón para tal fin (figura 17).

Figura 17: Botón Dispositivos

En esta sección se muestra el botón "Registrar dispositivo" (figura 18) que al presionarlo muestra el formulario para realizar esta tarea.

Figura 18: Sección Dispositivos contiene el botón Registrar dispositivo En este formulario se deberá ingresar el identificador del dispositivo y el nombre que se le desea asociar con el fin de reconocerlo fácilmente (figura 19).

Figura 19: Formulario de registro de dispositivo.

Para finalizar desde el cliente recolector existe la opción de verificar si el dispositivo se encuentra registrado. Esto se puede lograr presionando el botón "Comprobar", que se puede ver en la figura 16. En caso que el dispositivo se encuentre registrado, se mostrará la pantalla principal del cliente recolector (figura 20).

Figura 20: Pantalla principal del cliente recolector

5.2.2. Obtener definiciones

Antes de comenzar con la recolección de datos será necesario obtener las definiciones de los formularios a utilizar. Para llevar a cabo esta tarea, desde el dispositivo móvil se deberá pulsar el botón "Sincronizar items", que se puede ver en la figura 20. La pantalla de Sincronización mostrará el estado de la sincronización (figura 21).

Figura 21: Pantalla de sincronización

Luego de realizar esta acción, la pantalla principal mostrará la lista de capas definidas por el usuario, esto se puede observar en la figura 22.

Figura 22: Lista de capas disponibles

5.2.3. Recolectar datos

Para realizar la recolección de datos se deberá seleccionar una de las capas mostradas en la pantalla principal del cliente recolector, como se puede observar en la figura 22. Esto mostrará el formulario que se construye en base a la defi- nición de los datos a recolectar. La figura 23 muestra como se ve el formulario.

Figura 23: Formulario por cargar

El usuario deberá cargar los datos solicitados en el formulario y luego pulsar el botón "Guardar" (figura 24). Esto finaliza con la recolección (figura 25) per- mitiendo volver a la pantalla principal, o continuar con la recolección de datos sobre la misma capa.

Figura 25: Guardado de los datos