Servicio de posicionamiento habitual y rutinas de desplazamiento según el modelo PEaaS

2 3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA DEL SOFTWARE SEVICIO DE POSICIONAMIENTO HABITUAL Y RUTINAS DE DESPLAZAMIENTO SEGÚN EL MODELO PEAAS POSITIONING SERVICES FOLLOWING THE PEAAS MODEL Realizado por JOAQUIN CARDOSO BUZÓN Tutorizado por CARLOS CANAL VELASCO Departamento LENGUAJES Y CIENCIAS DE LA COMPUTACIÓN UNIVERSIDAD DE MÁLAGA MÁLAGA, SEPTIEMBRE 2016 Fecha defensa: El Secretario del Tribunal 4 5 Resumen: El principal objetivo de este proyecto es el de poner en práctica el modelo PeaaS (People as a Service), que es un modelo de servicio que tiene como interés principal que el procesamiento de los datos se realicen en los dispositivos móviles de los usuarios, almacenando en ellos un perfil sociológico de su usuario. De este modo se evita que se guarden la información en los servidores y es el propio usuario quien es dueño de su propia información. Evitando la mala circulación de ésta. A la implementación de este modelo se le va a añadir una serie de funcionalidades que permitirán poner en práctica este modelo y darle un uso cotidiano. Para ello se almacenarán rutinas de desplazamiento del usuario. Estas rutinas, tendrán información de lugares visitados, fecha de la visita y frecuencia entre otras cosas. La aplicación móvil hará uso de estas rutinas para recibir notificaciones push. El sistema aplicará una serie de filtros que serán los encargados de determinar si la notificación es del interés del usuario para mostrarla o rechazarla. Éste sistema se puede extender a infinitos campos a parte del que ponemos en práctica, como puede ser la detección del tipo de lugar al que visita el usuario (bar, hospital, centro comercial, supermercado, etc) y determinar gustos y aficiones, ampliando el impacto del modelo. Palabras clave: PeaaS (People as a Service), Smartphone, perfil sociológico, rutinas de desplazamiento. Abstract: The main objective of this project is to implement the model PeaaS (People as a Service). Is a service model that has main objective data processing are performed on mobile devices This will prevent information on the servers are saved and the user who owns his own information. Avoiding wrong circulation of this. The implementation of this model is going to add a number of features that will implement this model and give everyday use They are stored user routines displacement. These routines have information of places visited, date of visit and frequency between other things. The mobile application will use these routines to receive push notifications. The system will apply a series of filters that will be responsible for determining whether the notification is in the interest of the user to display it or reject it. This system can be extended to infinite fields also we practice, such as detecting the type of place you visit the user (pub, hospital, shopping mall, supermarket, etc.) and determine tastes and interests, expanding the impact of model. Keywords: PeaaS (People as a Service), Smartphone, sociological profile, scroll routines. 6 7 Índice 1-Introducción………………..……………………………………………………………………………………………9 1.1-Motivación………………..…………………………………………………………………………..………………9 1.2-Objetivos……………………………………………………………………………………………..………………10 2-Tecnologías usadas………………………………………………………………………………………………….12 3Desarrollo……..…………………………………………………………………………………………………………18 3.1Proyecto…………….…………………………………………………………………………………………………18 3.2Descripción de las aplicaciones……………………….………………..…………………………………18 3.3Actores…………………………………………………………….…………….……………………………………19 3.4Requisitos………………………………………………………….………..………………………………………19 3.4.1Requisitos Funcionales…………………………………….……….………………………………………19 3.4.2Requisitos No Funcionales……………………………….….……………………………………………20 3.5Funcionalidad y Arquitectura………………………………………………………………………………21 3.6Estructura de datos………………………………………….….………………………………………………44 3.6Optimización de recursos….…………………………….….………………………………………………44 3.7Proceso de desarrollo…………………………………………….……………………………………………45 4Conclusiones y trabajos futuros….……………………………………………………….…………………51 5Manual de Usuario….………………………..……………………………………………………………………56 6-Casos de Uso…………………………….…………………………………………………………………………….61 6.1-Caso de uso 1……………………………………………………………………………………………………….61 6.2Caso de uso 2………………………..…………………………………………………………………………….62 7-Herencia………………………………………………………………………………………………………………….64 7.1-Funcionalidad heredada……………………………………………………………………………………….64 7.2Estructura de datos heredada……………………………………………………………………………..65 8 9 1 Introducción Hoy en día, los smartphones han revolucionado la forma de vivir de las personas, pudiendo indicar que son uno de los inventos más importantes de nuestra era. Tal ha sido su impacto, que forman parte fija de nuestra vida diaria, acompañándonos en todo momento y a todas partes. Con los avances producidos en sus aplicaciones, almacenan información de todo lo que hacemos, visitamos, buscamos y toda nuestra interacción con el medio a través de internet. Consecuentemente todas estas acciones permiten que los smartphones sean una parte más de nosotros, convirtiendo lo que almacenan en un auténtico histórico de nuestro día a día. Es por esta causa por la que desarrollamos el siguiente proyecto enfocado a la recopilación en el propio teléfono móvil de la información de su usuario para poder realizar una serie de acciones determinadas que se describirán a lo largo de este documento. 1.1 Motivación En la actualidad, el procesamiento de la información se lleva a cabo siguiendo el tradicional modelo cliente/servidor. La información generada por los usuarios se almacena y procesa en los servidores de las compañías responsables de las aplicaciones que estos utilizan (Google, Facebook, Instagram, etc.) que son las que construyen y explotan económicamente el perfil sociológico de los mismos. Este modelo plantea varios inconvenientes. En primer lugar, el hecho de que la información está distribuida en diversas plataformas sociales, que solo pueden generar un perfil sociológico parcial y en ocasiones contradictorio de sus usuarios. En segundo lugar, que el usuario no controla quién y con qué objeto procesa su perfil sociológico o accede al mismo, ni obtiene beneficios de su explotación, más allá del uso gratuito de la mayoría de aplicaciones de redes sociales. Para paliar estos inconvenientes, se han planteado modelos alternativos para el desarrollo de aplicaciones sociales para dispositivos móviles. En concreto, People as a Service (PeaaS) [1], plantea un modelo computacional centrado en el dispositivo móvil que permite que el perfil sociológico del usuario se genere, almacene y proporcione de forma segura como servicio a terceros desde el propio dispositivo. Esto permite a su propietario ser plenamente consciente y capaz de controlar quién y cuándo accede a su información, y proporciona una manera excelente de representar información sociológica colectiva. En este proyecto se pretender desarrollar un servicio que haga uso de la información que almacenan nuestro Smartphone de nosotros, pudiendo establecer un perfil nuestro y permitir el recibo de información que mayor interés nos pueda entregar, según los datos que tiene nuestros. [1] J. Guillen, J. Miranda, J. Berrocal, J. Garcia-Alonso, J.M. Murillo, C. Canal. “People as a Service: A Mobile-centric Model for Providing Collective Sociological Profiles”: 16 Para el uso de éste sensor utilizaremos la api que ofrece google “Google maps Apis”, que nos ayudará a determinar los reconocimientos de los recorridos que ejecute el usuario.  JExcelApi Es una api, escrita en java, que permite leer y escribir hojas de cálculo [5]. Con esta api, se permitirá en la aplicación exportar los datos obtenidos en las rutinas a un archivo Excel o importarlos nuevamente del archivo Excel a la base de datos. [5] http://jexcelapi.sourceforge.net/ Figura 4: GPS 17 18 3-Desarrollo 3.1-Proyecto Se pretende presentar un sistema basado en el modelo PeaaS (People as a Service), centrado en los dispositivos móviles, que permite generar perfiles sociológicos de sus dueños y proporcionarlos como servicios de forma segura desde sus propios dispositivos. Éste modelo, le ofrece al usuario la posibilidad de almacenar los datos que su dispositivo va generando sobre posicionamiento, búsquedas, etc. evitando que dicha información pase a formar parte de empresas que comercialicen sus datos e información de un lado a otro llegando en ocasiones a hacer un uso fraudulento de ellos. Los perfiles que se van generando se utilizarán para mostrar información relevante para el propio usuario en forma de notificaciones push. El escenario elegido para la implantación del modelo PeaaS ha consistido en el desarrollo de dos aplicaciones móviles, una para el envío de mensajes y otra para su recepción. La aplicación destinada al envío le ofrece al usuario una serie de parámetros que este puede ir introduciendo, como pueden ser dirección, mes, día, etc. Estos parámetros se utilizarán en la aplicación de recepción, que según los datos del usuario almacenados en el dispositivo (perfil), filtrará los parámetros, para saber si es relevante para el propio usuario o no. Con el funcionamiento de la aplicación se pretende dar la posibilidad de que cualquier usuario pueda promocionarse o enviar su propia publicidad teniendo en cuenta parámetros de posicionamiento como pueden ser la latitud y longitud de su establecimiento, llegando la información a los usuarios que viven cerca del lugar o a usuarios que dentro de alguno de sus recorridos diarios pasa por ese sitio o por las personas que frecuentan ir a su establecimiento, etc. Para el funcionamiento de todo el sistema se ha hecho uso de la api de Nimbees. Dicha api recibe una petición post con unos datos de entrada, entre ellos el mensaje de la notificación e información adicional (filtros) y se envía a los dispositivos seleccionados una notificación push con la información pertinente. 3.2Descripción de las aplicaciones -Aplicación 1 (Mis rutinas): se encarga de ir almacenando los lugares frecuentes que el usuario va visitando a lo largo del día (su casa, trabajo, supermercado, tiendas, etc). La aplicación va almacenando la información tanto de los puntos finales como del recorrido que se realiza hasta llegar. Una vez va detectando los lugares frecuentes se va introduciendo la frecuencia con la que se va a esos lugares para poco a poco ir generando el perfil del usuario. La aplicación permite adicionalmente importar la información que la aplicación va almacenando del usuario tanto en un archivo .txt como en un Excel. Además muestra una lista de las últimas notificaciones recibidas. La parte más importante de esta aplicación es la aplicación de filtros sobre las notificaciones recibidas, para evaluar de una forma inteligente si la notificación ha de 19 ser mostrada al usuario siguiendo los patrones establecidos en el perfil del usuario creado en el dispositivo. - Aplicación 2 (Envío de Notificación): se encarga de enviar los datos que el usuario emisor dictamine relevantes a la api de Nimbees, por los que la aplicación del usuario receptor filtrará la notificación en base a su información almacenada. Ésta aplicación ha sido desarrollada en forma de apoyo para la demostración del correcto funcionamiento del sistema. 3.3Actores Habrá dos actores además del sistema que tendrán acceso a éste. El usuario principal, que será sobre quien el sistema trabaja y obtiene las rutinas (aplicación “Mis rutinas”), pero recordemos que la idea es tratar de reducir al máximo la interacción de este con el sistema, tratando que la introducción de datos sea mínima o nula, es el sistema automáticamente quien deberá aprender del usuario sin que este se dé cuenta si quiera. Sin embargo, si se le permitirá en cualquier caso hacer algunas consultas en el móvil, como pueden ser la exportación en un archivo Excel o .txt de sus principales rutinas, la visualización de las últimas notificaciones e incluso la manipulación de los datos que se han almacenado sobre él. El segundo actor será el que se encargue de hacer uso de la otra aplicación (aplicación “Envío de Notificaciones”), para poder enviar las notificaciones a los usuarios finales y probar el correcto funcionamiento del sistema. El sistema se encargará de ir recopilando las rutinas de desplazamiento del usuario, para posteriormente ir reconociendo los puntos interesantes como pueden ser recorridos y lugares habituales. Además también tiene la tarea de una vez reciba una notificación enviada por un usuario, filtrar según los parámetros recibidos si es de interés para el usuario final o por el contrario desestima mostrarla. 3.4 Requisitos A continuación se citan los requisitos funcionales y no funcionales a ser tenidos en cuenta en la producción de la aplicación con el fin de intentar definir de forma más concreta el sistema con los requerimientos mínimos que este debería cumplir. 3.4.1 Requisitos Funcionales - El sistema detectará ante desvíos en la rutina de desplazamiento del usuario, los puntos finales, para reconocer si estos son nuevos o simplemente son desvíos. - El sistema reconocerá los lugares de destino a través de un radio de localización. 20 - El sistema permitirá que los datos sean guardados en diferentes formatos. - El sistema permitirá la recepción de notificaciones push. - El sistema permitirá el envío de notificaciones push. - El sistema filtrará las notificaciones push según los criterios de filtrado establecidos. - El sistema será capaz de obtener el email del usuario de su teléfono para poder realizar el registro en la aplicación. - El usuario podrá consultar sus rutinas. Para ello deberá acceder a la memoria del teléfono y dentro encontrará documentos con los datos almacenados. - El usuario podrá manipular los datos de sus rutinas desde el archivo Excel exportado desde la aplicación. - El usuario podrá importar los cambios realizados en su archivo Excel. - El usuario podrá recibir notificaciones a través del sistema. - El usuario podrá enviar notificaciones a través del sistema. - El usuario podrá consultar las últimas notificaciones recibidas. - El usuario podrá realizar una exportación de su base de datos. - El usuario podrá realizar una importación de su base de datos para recuperarla en caso de error. - El sistema realizará una copia de la base de datos antes de su manipulación para recuperarse en caso de error en el procedimiento. 3.4.2 Requisitos No Funcionales - El sistema debe estar desarrollado en plataforma Android. Es la plataforma que se ha elegido para el desarrollo en un principio, debido a que se trata de la plataforma más asequible para los usuarios, con el objetivo de que cualquiera pueda tener acceso al servicio sin realizar una gran inversión monetaria. - El sistema debe cumplir con la LOPD. Es obligatorio cumplir con la Ley Orgánica de Protección de Datos ya que trabajamos con datos sensibles de los usuarios. - El sistema se adaptará a los recursos disponibles. - El sistema debe ser lo más eficiente posible optimizando la utilización de los recursos del dispositivo móvil. 21 3.5 Funcionalidad y Arquitectura Como se ha descrito, el conjunto de aplicaciones desarrolladas ha heredado parte de funcionalidad un proyecto de fin de grado anterior. Esta funcionalidad ha sido adaptada a la nueva lógica de funcionamiento que debe de presentar el presente escrito. Se ha de tener en cuenta que la app Caremee estaba destinada a enfermos de Alceimer, siendo su principal objetivo detectar recorridos de los enfermos para avisar a su cuidador en caso de que el paciente salga de un recorrido habitual. Describimos la funcionalidad y los cambios aplicados sobre ella: - Acumulación de datos: dicha funcionalidad se ha adaptado a los requisitos establecidos, ya que estaba enfocada a la detección de rutas de usuarios enfermos de alcéimer. Sobre ella se han realizado el cambio de la api que se utiliza para la detección del posicionamiento que provocaba desvíos significativos en algunas ocasiones, consiguiendo reducir estos desvíos y la mejora de la precisión. - Monitorización de las rutas: consiste en la detección, según los datos que se van recogiendo de la ruta seguida, de si la ruta realizada es una ruta conocida o no y en caso de no serlo se envía al cuidador un mensaje avisándolo de ello por si el paciente se ha perdido. En nuestro caso se ha eliminado gran parte de esta funcionalidad y sólo se ha tenido en cuenta la detección de la ruta para estudiar si es una ruta conocida o nueva, aumentando la holgura de desvío para no considerar que el usuario ha cambiado de ruta si éste desvía su recorrido por otro lugar para llegar al mismo destino. - Analizador de datos: Esta tarea convierte lo que en un principio son muestras de latitud, longitud y fecha, en rutinas con una frecuencia, un lugar de partida y de llegada, y una convicción de fiabilidad de la misma. El proceso seguido para dicho análisis o aprendizaje, es el descrito por Davenport y Prusak, basado en la pirámide de conocimiento. A esta funcionalidad se le ha añadido un sistema de recuperación ante fallos que realiza una copia de seguridad de la base de datos para no perderlos en caso de error. También se ha heredado parte de la base de datos, concretamente la parte encargada del almacenamiento de las rutinas, teniendo en cuenta las modificaciones necesarias para cumplir con los requisitos establecidos. Notificaciones Push En términos de tecnología de movilidad, las Notificaciones Push son aquellos mensajes que recibimos en el dispositivo y que han sido emitidos desde cualquier punto de un sistema. Tenemos un ejemplo muy claro en el popular WhatsApp, donde son los usuarios los que envían mensajes a los dispositivos de otros usuarios. Otro ejemplo con notificaciones enviadas de manera automática (y no manual como WhatsApp) podría ser una aplicación de cliente de correo, cuando el servidor detecta un mensaje entrante envía una notificación al dispositivo del usuario. 22 Las Notificaciones Push permiten el envío de mensajes desde cualquier parte de un sistema a una aplicación móvil tanto si la aplicación está siendo utilizada por el usuario, si está corriendo en un segundo plano, si todavía no ha sido arrancada o, incluso, si el dispositivo está en reposo. Google Cloud Messages Las notificaciones Push en Android mediante Google Cloud Messaging (GCM) se ejecutan en un escenario que está compuesto por, al menos, tres actores: Google Cloud Messaging: El servicio de Google habilitado para el envío de Notificaciones Push a dispositivos Android. Servidor: con un servicio (REST, SOAP, aplicación web, etc…) que será el encargado de gestionar los identificadores de registro de dispositivos a los que podemos enviar las notificaciones y de comunicarse con GCM solicitando el envío de notificaciones al dispositivo (o dispositivos) deseado. En nuestro caso utilizaremos la api de Nimbees, sobre la que hablaremos más adelante Dispositivo Android receptor: que recibirá las notificaciones. Dispositivo Android emisor: que enviará las notificaciones, junto con información adicional, que será procesada en el otro dispositivo. Para poder enviar notificaciones a un dispositivo Android desde GCM dicho dispositivo debe estar antes registrado en el servicio ofrecido por Nimbees. Dicho paso se realiza de forma transparente al usuario al iniciar éste el sistema. Para ello se ha implementado una función que obtiene la cuenta de correo electrónico de usuario de Android y mediante una petición post realiza el registro con la aplicación implementada en la plataforma Nimbees. Registro de la aplicación móvil Para el registro de nuestra aplicación Android, lo primero que debemos hacer para que la aplicación pueda recibir Notificaciones Push desde Google Cloud Messaging (GCM) será registrarla en dicho servicio. Es una forma de decirle a GCM: “soy un dispositivo que quiere recibir notificaciones de una aplicación”. La forma que tenemos de decirle la aplicación de la que queremos recibir notificaciones es indicándole un número de proyecto (lo veremos en el siguiente apartado). Si todo está correcto, GCM nos responderá con un identificador de registro. 23 Figura 6: Registro Para terminar el proceso de registro de la aplicación que hemos creado en la web de Nimbees, introduciremos el identificador obtenido en la plataforma de GCM y ya se podrá comunicar con GCM para indicarle que debe enviar una notificación. El envío de la notificación. Podemos enviar una Notificación Push a cualquiera de los dispositivos Android que tengamos registrados en nuestro servicio desde cualquier parte del sistema. Para ello, nuestro servicio tendrá una operación donde recibirá la información relativa al mensaje que queremos enviar en forma de notificación y el destinatario o destinatarios. La información relativa al destinatario puede ser directamente el identificador del registro u otra información que el servicio sepa relacionar con dicho identificador de registro. Figura 7: Envío de la notificación 24 A continuación, con la información de la petición de envío de notificación que recibió nuestro servicio, éste envía una nueva petición a GCM (puede hacerse de manera síncrona o asíncrona: HTTP o XMPP) para que mande la notificación al dispositivo, en nuestro caso se utilizará http. El destinatario de la notificación se indica mediante el identificador de registro que obtuvimos en el punto anterior. Necesitaremos adjuntar unas credenciales de servidor a nuestra petición. Una vez que hemos enviado la petición a Google Cloud Messaging con nuestras credenciales del servidor, la información relativa a la notificación y su destinatario, GCM enviará dicha Notificación Push. Habilitando el servicio Google Cloud Messaging. Para habilitar el servicio Google Cloud Messaging debemos seguir una serie de sencillos pasos:  Creando un proyecto Google API. Lo primero que haremos será crear un proyecto en Google API, para ello accedemos a la consola de desarrolladores de Google con nuestro usuario. Figura 8: Google cloud Messages En la sección “Projects” pulsamos sobre el botón “Create Project”, le asignamos un nombre y ya tendremos nuestro proyecto creado. Nos aparecerá una pantalla donde podremos ver información relevante a dicho proyecto. 25 Figura 9: Obtención de project Number Para las Notificaciones Push, el campo que más nos interesa será Project Number o sender id. Dicho número es necesario para el paso de registro del dispositivo en GCM. Dicho Project Number será algo del tipo: 231447612989  Habilitando la opción Google Cloud Messaging. Una vez tenemos el proyecto creado, lo siguiente que haremos será habilitar el servicio de Google Cloud Messaging. Para ello, pulsamos en el menú de la izquierda sobre APIS & AUTH > APIs y activamos el servicio “Google Cloud Messaging for Android” (por defecto estará desactivo). Figura 10: Activar google cloud menssaging  Obteniendo la clave de acceso al API. Por último, necesitaremos tener una clave de acceso a nuestro API para que podamos enviar peticiones a GCM y que éste las sirva las notificaciones al dispositivo o 32 Añadimos al archivo AndroidManifest.xml la versión de Google Play Services que vamos a usar: Figura 22: Versión Google Play Añadimos al archivo AndroidManifest.xml la actividad que será la encargada de reproducir las notificaciones recibidas, junto con los servicios. Figura 23: NotificationDisplayActivity Añadimos el Broadcast Receiver con el fin de procesar los mensajes de inserción y ser capaz de realizar un seguimiento de la ubicación del usuario. Figura 24: NimbeesBroadcastReceiver Creamos un archivo denominado app.properties en la carpeta assets del proyecto, introduciendo su app key and app secret, y su identificación de remitente de GCM. Opcionalmente, también se pueden añadir los parámetros de personalización de la plataforma. En primer lugar establemos la app.key y la app.secret, que son las que obtuvimos al crear nuestra aplicación en la plataforma Nimbees. Se encuentran dentro de “App 33 Configuration”. Estos parámetros se utilizarán para que se comunique nuestra aplicación móvil con la aplicación Nimbees. La primera se utiliza para autenticar y sincronizar la app móvil con la plataforma, y es una clave para uso exclusivo desde el SDK móvil. En el panel pone "Mobile Key" a la izquierda, haciendo referencia solamente a la autenticación para la librería móvil: Figura 25:Mobile key En segundo lugar establecemos el gc.sender, que es el número que obtenemos al registrarnos en google cloud messages. Este parámetro se utiliza para cuando nuestra aplicación móvil quiera enviar información a la API de Nimbees pueda enviar los mensajes a través de google cloud messages. En tercer lugar encontramos parámetros de configuración extra como pueden ser título para la notificación, título para el diálogo, vibración, led color y parámetros de location tracking. Por último encontramos la opción de configurar la clase CustomNotificationManager, que utilizaremos para manejar las notificaciones que recibe nuestro teléfono. Archivo App.properties: 34 Figura 26: app.properties Para gestionar las notificaciones personalizadas y mensajes de transición de pantalla, crearemos la clase CustomNotificationManager que se extiende NimbeesNotificationManager desarrollando la funcionalidad que se desee para tratar las notificaciones recibidas por Nimbees. Figura 27: CustomNotificationManager 35 Los métodos que usaremos en nuestra aplicación son:  handleCustomMessage: Se utiliza para tratar las notificaciones tipo “custon”, es decir, las notificaciones que utilizaremos para recibir la información adicional para tratar los filtros dentro de nuestra aplicación aplicando de este modo el modelo PeaaS.  handleScreenTransitionMessage: Se utiliza para tratar las notificaciones de tipo “message”, que es el otro tipo de notificaciones que podemos recibir. En este tipo de notificaciones sólo se puede añadir el mensaje y una imagen. Aunque estos tipos de mensajes sólo serán procesador por nuestra aplicación móvil en caso de que la notificación push sea enviada a través de la web de Nimbees, ya que no se ha implementado esta opción en la app de envío. Finalmente en la actividad principal de la aplicación (o la clase de aplicación personalizada), debemos inicializar la biblioteca mediante una llamada al método init del cliente nimBees: NimbeesClient.init(this); Después de que los usuarios se registren en la aplicación, llamamos al método RegisterDevice de NimbeesClient con el fin de registrar el usuario en la plataforma nimBees. ¡Error! No hay texto con el estilo especificado en el documento. Figura 28: Registro Nimbees Y ya tenemos nuestra aplicación preparada para aceptar las notificaciones push. Envio de notificaciones 36 Para el envío de notificaciones se ha implementado una función que realiza una petición post a la API de Nimbees. En la siguiente imagen podemos ver su desarrollo. Figura 29: Envio de mensaje a la plataforma Nimbees Como podemos ver en primer lugar se obtiene el policy para informar de las violaciones de políticas relacionadas con los hilos y la máquina virtual. En segundo lugar se inicia la clase OkHttpClient, que que es una librería que permite realizar peticiones HTTP en java. Creamos el MediaType para parsear nuestro body a un objeto JSON. En tercer lugar creamos el body de nuestro request. En él introduciremos el tipo de mensaje, que en este caso es “CUSTOM”, y la rutina con la información de los filtros que se van a usar en la aplicación que recibe las notificaciones. En cuarto lugar creamos el request en el que debemos introducir la url de la api de Nimbees, el body, con un método post y el header, que estará compuesto por la autorización que es una clave que ahora explicaremos cómo se obtiene, el contenttype, que es JSON y otros parámetros obtenido al generar el request con la aplicación “Postman”[6]. Por último realizlamos la petición, con el método build() y obtenemos la respuesta. Obtención de la Authorization Para la obtención de la authorization en la api de Nimbees debemos obtener dos claves en la web de Nimbees, la primera se ha explicado anteriormente cómo obtenerla, es la App KEY que se encuentra en el “app configuration” de nuestra aplicación en Nimbees. 37 La segunda, la MASTER SECRET, es la clave a utilizar para la API REST, tal y como se indica en la página de documentación de Nimbees. Para obtener el valor de la MASTER SECRET en el menú "Account" que hay al desplegar tu usuario en la esquina superior derecha. Figura 30: Master Secret [6] Postman: Buil, test and document APIs faster. http://www.getpostman.com/ Por tanto, para la autenticación con la API hay que utilizar como nombre de usuario el App KEY, para identificar a qué aplicación de tu cuenta Nimbees y como contraseña se debe usar MASTER SECRET (en el menú Account), que es la que referencia al usuario. Con esto ya tenemos la authorization para poder enviar mensajes a los usuarios registrados en nuestra aplicación móvil. Filtros Los filtros son una de las partes más importantes de nuestra aplicación, porque mediante su aplicación podremos obtener cierta aproximación de la satisfacción de condiciones obtenidas a la hora de realizar el perfil sociológico del usuario. Permitirán estudiar, si un usuario ha pasado o ha visitado una dirección, en qué día y mes fue, qué día de la semana se realizó, con qué frecuencia, etc. y mediante este estudio decidir si mostrar al usuario la notificación por presunto interés. Además estos filtros posibilitan saber si un usuario podría tener la intención de ir en un futuro a ese lugar. 38 Todo el proceso se realiza en la clase CustomNotificationManager que creamos para procesar las notificaciones recibidas desde la API de Nimbees. Nos centramos en el método handleCustomMessage Figura 31: Obtención del mensaje En este método procesamos el content de la notificación que recibimos a través de la API de Nimbees. En este content, viene en forma de String, toda la información de nuestro mensaje que enviamos en formato JSON. Para poder obtener los datos, creamos el objeto JSON con el string y he creado una función que obtiene un Map<String,String> del objeto y de este modo recogemos los valores que son enviados. Hacemos las comprobaciones necesarias, por si ocurriera el caso de que no se enviara información en alguno de los campos y aplicamos el filtro. En caso de que el filtro sea aceptado se muestra la notificación, en caso contrario la rechaza. La clase Filtro se describe a continuación. Mediante el método buscaDireccionEnBD al que se le pasan los parámetros dirección, fecha, dia, mes y radio, se va aplicando de menor a mayor exhaustividad para obtener el filtrado más preciso posible. 39 Figura 32: Filtro 1 En primer lugar recorro las tablas principales de la base de datos, que son las que deben de darme la información más reciente del usuario, estas tablas son Place, RoutinePlace y PlaceInstance. En primer lugar en cada búsqueda dentro de las tablas compruebo si la latitud longitud de la dirección recibida coincide con alguno de los puntos de estas tablas. En caso afirmativo, compruebo que se haya pasado algún parámetro de fecha, si esto es así, hago uso de un método (se explica más adelante) 40 que he creado para que filtre si esos lugares han sido visitados con relación a los campos pasados, que serán la fecha, los días y los meses de interés. En caso de que no coincida con ningún campo de la tabla, continúo con la siguiente buscando alguna coincidencia. Si por el contrario no se pasa fecha ni días, considero que no es necesario aplicar el filtro de la fecha y se muestra la notificación. Si no ha habido ninguna coincidencia en ninguna de estas tres tablas, realizo la búsqueda en la tabla RoutineInstance, en este caso además de aplicar los filtros anteriores, aplico un radio si este es pasado como parámetro. Para poder aplicar el radio he definido una función, que mediante unas operaciones matemáticas obtiene la distancia de los puntos de latitud y longitud de las direcciones que estamos comparando y si la distancia es menor que el radio dado se considera que se ha tenido éxito en la búsqueda. Figura 33: Filtro 2 Por último, se comprueba en la última tabla que puede contener información de todos los puntos visitados posibles. Esta tabla es la del Historial. En primer lugar comprueba si coinciden los puntos de latitud y longitud y en caso contrario se comprueba si están dentro de un radio permitido. Continuando con los filtros de fecha anteriormente mencionados. 41 Figura 34: Filtro 3 El filtro aplicado a la fecha consiste en tres pasos, primero se comprueba si coinciden la fecha pasada en el mensaje con la de la rutina. Si no se ha obtenido ninguna coincidencia, se pasa a comprobar los días pasados en el mensaje. Para esto se obtiene el mes en el que se produjo la rutina, si existe alguna coincidencia con los meses pasados en el mensaje, se devuelve true, en caso contrario se procede a realizar el mismo proceso, pero con los días, en este caso obtenemos el día de la semana en la que se produjo la rutina, si coincide con alguno de los días pasados en el mensaje se devuelve true. Este filtro es vital a la hora de determinar si en un futuro existe la posibilidad de que el usuario vuelva a ir a ese sitio en determinado ya que ha estado allí ese mismo día de la semana en el pasado. En caso de que no exista ninguna coincidencia se devolverá false, para pasar al siguiente filtro. 48 "name": "sendNotification/", "description": "", "collectionId": "1dbb8d07-ad05-4d86-3e08-4c4019b771fc", "responses": [], "rawModeData": "{\n\"content\": {\n \"type\": \"MESSAGE\",\n \"message\": \"Hola!\"\n }\n}", } ] } Como podemos observar, se incluye el formato de una petición post y otra get, y se le pasan, entre otras cosas, la clave de autenticación que es la Master secret de google cloud messages utilizada como autenticación de acceso básica, el usuario y la password de que son la App Key y la Master Secret de la cuenta de Nimbees, la url a la que se realizará la petición y el mensaje donde se enviará toda la información para los filtros. Importamos dicho archivo a la aplicación Postman y gracias a ella agilizamos el proceso de comunicación. Una vez conseguimos que la api nos respondiera un mensaje de “OK”, se procedió a transformar la petición para java. Para ello Postman ofrece la posibilidad de transformar el objeto JSON en una petición para el lenguaje que nosotros prefiramos, que en nuestro caso es java. Una vez podíamos enviar y recibir las peticiones en nuestro teléfono, se procedió a implementar los filtros para decidir si la aplicación debía mostrar o rechazar el mensaje. 49 50 4Conclusiones y trabajos futuros. Como se describe a lo largo de este proyecto se pretende presentar una tecnología que ofrece al propio usuario ser quien maneja la información que su dispositivo almacena sobre sí mismo. Esta situación podría mejorar la información que el teléfono va a mostrarle según su perfil creado, como por ejemplo mensajes publicitarios o de interés. El modelo PeaaS probablemente no sea de alto interés para los sistemas publicitarios ya que el interés de éstos es llegar al mayor número posible de usuarios, sin embargo, si puede llegar a ser interesante para los usuarios debido a que ellos pueden filtrar y manipular su información o perfil para recibir sólo aquello que puede ser de su interés. De este modo se evita que el usuario sea bombardeado con multitud de información que probablemente no sea de su interés. Para futuros trabajos se podrían establecer nuevos filtros que permitan seleccionar mejor la población que puede estar interesada. También se podría mejorar el almacenamiento de los lugares que visita el usuario, por ejemplo en el actual sistema se almacena una dirección, cosa que se puede mejorar porque por ejemplo si se visita un centro comercial no se tiene en cuenta qué tiendas o tipo de tiendas son visitadas. También se podría permitir la posibilidad de que el usuario introduzca información sobre sí mismo, como pueden ser cosas de interés, gustos deportivos, aficiones, etc. De este modo si al usuario le gusta el running por ejemplo, y se va a celebrar una carrera deportiva cerca de donde vive, o en su comunidad autónoma, pueda recibir dicha información. Podría resultar interesante que se monitorizaran búsquedas y visitas de páginas que el usuario realiza desde su dispositivo, para tener un perfil aún más desarrollado. Si el modelo PeaaS tomara fuerza y se siguiera desarrollando aplicaciones utilizando esta lógica la publicidad que reciben los usuarios podría ser más interesante, ya que ellos seleccionarán qué recibir y no recibir mucha publicidad de forma constante y desinteresada teniendo que buscar cual puede llegar a interesarle. Con este modelo se filtra la publicidad o información antes de que la reciba el usuario y no tenga que ser el usuario quien la filtre después de recibirla. Además la información del propio usuario no irá de una empresa a otra sin el consentimiento del propio usuario, cosa que hoy en día es un gran problema para los ciudadanos. 51 52 Referencias Bibliográficas: [1] J. Guillen, J. Miranda, J. Berrocal, J. Garcia-Alonso, J.M. Murillo, C. Canal. “People as a Service: A Mobile-centric Model for Providing Collective Sociological Profiles” [2] http://encuentracapital.es/encuentra_capital_III/nimbees/ [3] Libro Introduccion a Android www.tecnologiaUCM.es [4] http://elbauldeandroid.blogspot.com.es/2013/12/services.html [5] http://jexcelapi.sourceforge.net/ [6] Frances Wright. Course of Popular Lectures. Office of the Free Enquirer, 1829. 24 53 54 ANEXOS 55 5Manual de usuario -Manual de usuario de aplicación “Mis rutinas”. La aplicación Mis rutinas, ofrece a sus usuarios la posibilidad de tener un perfil sociológico en su teléfono siguiendo el modelo PeaaS. A su vez permite el volcado de datos en un archivo Excel y la posibilidad de poder manipular ese Excel e importarlo de nuevo a la base de datos. Para su uso será necesario disponer un dispositivo móvil con sistema operativo Android. Una vez instalada la aplicación en nuestro dispositivo, no tendremos que realizar ninguna acción, tan sólo asegurarnos que el dispositivo tiene activado el gps, para que la aplicación comience su lectura de datos. Conforme vayan pasando los días, la aplicación irá definiendo cada vez, de forma más clara el perfil del usuario. Según el usuario vaya viajando y realizando sus recorridos, la aplicación reconocerá o detectará si es un recorrido ya realizado al que habrá que aumentar su frecuencia, o si habrá que añadirlo como nuevo. Una vez el usuario comience a recibir su primera notificación push, éstas, se irán mostrando en la actividad principal de la app durante un periodo de tiempo, de este modo nos aseguramos de que la información de las notificaciones no sean olvidadas por el usuario. Figura 37: Vista principal aplicación 56 Si el usuario pulsa su dedo sobre cualquier notificación, ésta se abrirá como si fuera una alerta, mostrando su información. Figura 38: Vista notificación En el menú que se encuentra en la esquina superior derecha, encontraremos opciones para exportar la base de datos a un archivo Excel, importar el archivo Excel a la base de datos, hacer un backup de la base de datos y poder recuperar de un archivo de backup la base de datos. Figura 39: Menú aplicación Las opciones de backup sobre la base de datos, están pensadas para evitar que se pierda la información si al hacer una importación del archivo Excel introdujéramos algún tipo de error, corrompiendo de este modo la base de datos. El archivo Excel se guarda dentro de la carpeta raíz de la memoria del teléfono con nombre de serviceNotificationPush.xml y el archivo de backup serviceNotificationBackup. 57 El formato del archivo Excel, en primer lugar se muestra la primera fila donde podemos ver la palabra que representa al tipo de datos a mostrar, que en este caso es “Lugares:”. En la siguiente línea aparecen los nombres de las columnas que son ID, longitud, latitud, dirección y frecuencia. Para diferenciar un conjunto de datos de otro se introduce una línea en blanco. La siguiente lista de datos a mostrar es la de “Instancias:” que contiene datos de ID, latitud, longitud, dirección, localidad, fecha de inicio y fecha de fin. El último conjunto de datos es el de “Instancia-Rutina” y consta de ID, dirección de inicio, localidad de inicio, dirección de fin, localidad de fin, fecha de inicio y fecha de fin. En el caso de que no se tengan datos dentro de la aplicación sobre alguno de estos conjuntos, se mostrará una fila mostrando el mensaje de “No se encuentran Lugares”, “No se encuentran Instancias” y “No se encuentran InstanciasRutinas” respectivamente. Figura 40: Ejemplo de archivo excel 64 7Herencia 7.1Funcionalidad heredada En este apartado presentamos parte de la funcionalidad que se ha heredado de un antiguo proyecto de fin de grado llamado Caremee descrito anteriormente. Acumulación / Monitorización Este es el componente consta de dos tareas que se van realizando de forma simultánea. Estas tareas son la de acumulación de histórico y la de monitorización de los desplazamientos del usuario. Dicha funcionalidad se realiza a través de un servicio que se ejecuta en segundo plano mientras el dispositivo se encuentra encendido junto con su conexión a internet y gps activados. La acumulación funciona con un Listener que detecta cuando un usuario recorre una distancia x, en este momento se recogen los datos del posicionamiento del dispositivo (latitud y longitud) y se almacenan en la base de datos con la fecha y la hora de la recogida. Se realiza una recogida cada cierta distancia para ahorrar en el uso de batería y memoria. De este modo, si un usuario permanece durante un largo periodo de tiempo en un determinado lugar, el Listener quedará en reposo. Después de realizar la llamada al Listener, se lleva a cabo el proceso de monitorización, que actúa siguiendo el siguiente procedimiento: utilizamos un contador que se incrementa cada vez que se hace una llamada al Listener, en caso de que en una llamada se haga después de más de 5 minutos desde la última monitorización, se comprueba que se hayan realizado al menos un determinado número de incrementos del contador, consiguiendo el mínimo consumo de batería con un rango de detección de desvíos bastante aceptable. Explicando un poco mejor el procedimiento, en cuanto recogemos la primera muestra del histórico (recogida de datos del gps), actúa el monitor rellenando una lista con todas las rutinas que parten del lugar de la muestra recogida e incrementando el contador. Seguidamente, comprobamos si han pasado 5 minutos, si no han pasado, se incrementa el contador, en caso contrario, se comprueba si el contador tiene un número de medidas aceptable, lo que significa que el usuario sigue moviéndose y lo que se hace es ir rutina a rutina de la lista, y se establece un radio de cierta holgura con centro en el destino de la rutina. De esta forma, somos capaces de considerar que el usuario está en camino siempre que permanezca dentro de ese radio, o si en este caso es una rutina nueva para almacenar. Analizador Esta tarea convierte lo que en un principio son muestras de latitud, longitud y fecha, en rutinas con una frecuencia, un lugar de partida y de llegada, y una convicción de fiabilidad de la misma. El proceso seguido para dicho análisis o aprendizaje, es el descrito por Davenport y Prusak, basado en la pirámide de conocimiento. Más 65 adelante encontramos una sección de procedimiento de análisis en la que se relatará con más detalle el algoritmo implementado que usa esta tarea. Esta tarea solo se realizará una vez al día y en un momento preciso. Este momento es habitualmente cuando el dispositivo entra en modo de carga, lo cual significa que ha sido enchufado a la corriente, y por consiguiente que no va a tener repercusión en la batería del mismo. Otra tarea importante que realiza este componente es el borrado de datos antiguos ya utilizados para minimizar el uso de la memoria. En esta fase está implementado el borrado de datos con más de dos meses de antigüedad. Se ha implementado junto con la funcionalidad descrita la de recuperación ante un fallo. Para ello se realizan copias de seguridad de los datos automáticas o manuales, de este modo evitamos que algún tipo de error en el sistema a la hora de realizar la computación de los datos nos afecte. 7.2Estructura de datos heredada Podemos distinguir entre dos tipos diferentes de datos según la descripción de la estructura del sistema: el acumulador necesita almacenar las medidas que vaya recogiendo a lo largo del día; el analizador usar estos datos para crear lo que serían las rutinas, que también deben ser almacenadas. Así la base de datos se compondría de tres tablas principalmente. Sin embargo, son necesarias otras tablas de apoyo, tanto para completar la estructura de una rutina, como de apoyo para el análisis. En la figura 9 se muestra el diagrama entidad/relación de la base de datos final con todas las tablas y sus relaciones. Figura 9: Diagrama entidad/relación base de datos 66  Historial Es donde el acumulador almacena todas las muestras que se van recogiendo. Esta tabla tiene los datos de ID, latitud, longitud y fecha.  Rutina En esta tabla se almacenan las rutinas y su grado de convicción y frecuencia. Contiene datos de: -Lugares a los que el usuario acude durante la rutina. -Hora de inicio de la rutina. -Hora de fin de la rutina. -Frecuencia semanal con la que se repite. Los puntos a los que el usuario acude en la rutina se han modelado usando una relación muchos a muchos con una tabla llamada Lugares Habituales que contiene las coordenadas GPS de dichos puntos visitados por el usuario. En cuanto a la columna frecuencia, también es una relación muchos a muchos con una tabla Día que contiene los nombres de los días de la semana.  Lugares Habituales Se trata de la tabla que se relaciona con las rutinas en la relación muchos a muchos de los lugares a los que irá acudiendo el usuario durante la misma. Representa los lugares en los que el usuario pasa más tiempo o acude con asiduidad. Esta tabla contendrá las columnas necesarias para identificar estos lugares. -Coordenadas GPS. -Descripción del lugar, o anotaciones que se quieran hacer sobre él. -Asiduidad, que representará un número entero, representando el más alto, el lugar donde más ha ido el usuario, que suele ser su casa.  Frecuencia Es la tabla que está relacionada con Rutina, para representar la frecuencia semanal con la que se repite una rutina de desplazamiento del usuario. Solo contiene una fila por día de la semana de lunes a domingo. Para completar la información sobre una frecuencia semanal de una rutina, se añadió un campo de un entero para representar el grado de convicción que se tiene sobre la repetición del desplazamiento ese día. Este campo se encuentra en la relación muchos a muchos entre las dos tablas. Por último, es de esperar que en análisis, antes de obtener las rutinas completas, son necesarios una serie de pasos intermedios en los que los datos van adquiriendo cada 67 vez una mayor complejidad. Estas tablas son, en orden ascendente de completitud, Instancia de Lugar e Instancia de Rutina.  Instancia de Lugar Es el primer paso en el análisis. En esta tabla se intentan identificar los lugares en los que el usuario ha permanecido cierto tiempo. Es el paso previo a convertirse en un lugar habitual. Contiene: -Coordenadas GPS, del lugar en cuestión. -Fecha y hora de comienzo, de la permanencia en ese lugar. -Fecha y hora del fin, de la permanencia en ese lugar.  Instancia de Rutina Este es el último paso de los datos antes de convertirse en Rutinas. Estos datos ya tienen la misma forma que una rutina, a falta de la frecuencia. -Coordenadas GPS, del lugar de partida. -Coordenadas GPS, del lugar de llegada. -Fecha y hora de salida, desde el lugar de partida. -Fecha y hora de llegada, al destino. 