Recomendación dinámica de productos a grupos con realidad aumentada

RECOMENDACIÓN DINÁMICA DE PRODUCTOS A GRUPOS CON REALIDAD AUMENTADA Cristina Delgado Rodríguez Ignacio Rocillo Landa Jorge Muñoz Rodríguez Jorge Rueda Garzón Sergio Fuentes Urabayen TRABAJO FIN DE GRADO FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 2015-2016 ii A todos nuestros familiares, que siempre nos han estado dando apoyo durante la realización de este proyecto. iii AUTORIZACIÓN Nosotros, Cristina Delgado Rodríguez, Ignacio Rocillo Landa, Jorge Muñoz Rodríguez, Jorge Rueda Garzón y Sergio Fuentes Urabayen, alumnos matriculados en la asignatura Trabajo de Fin de Grado (TFG) en la Facultad de Informática de la Universidad Complutense de Madrid durante el curso 2015/2016, dirigidos por Juan Antonio Recio García y Guillermo Jiménez Díaz, autorizamos la difusión y utilización con fines académicos, no comerciales, y mencionando expresamente a sus autores del contenido de esta memoria, el código, la documentación adicional y la aplicación desarrollada. Cristina Delgado Rodríguez, Ignacio Rocillo Landa, Jorge Muñoz Rodríguez, Jorge Rueda Garzón y Sergio Fuentes Urabayen iv AGRADECIMIENTOS En primer lugar, quisiéramos agradecer a todos nuestros familiares que durante la realización de este proyecto siempre nos han apoyado y que han puesto toda su ilusión en nuestro viaje universitario. Mencionar también a todas las personas que han evaluado MUVI y han dedicado una parte de su tiempo a valorarla y probarla, especialmente a nuestras familias y amigos. Por último, quisiéramos dar las gracias a nuestros tutores de Trabajo de Fin de Grado, Juan Antonio Recio García y Guillermo Jiménez Díaz, por permitirnos trabajar en este proyecto y ayudarnos y guiarnos en la realización de este TFG. v RESUMEN Resumen La Realidad Aumentada es una tecnología que permite aumentar el mundo real que percibimos con elementos virtuales interactivos. En esta memoria describimos el uso de esta tecnología, entre otras, para obtener información a tiempo real sobre películas. La aplicación que describimos es capaz de recoger toda la información de una película con solo enfocar su foto de portada con la cámara, pudiendo guardar y/o compartir esta información. Además, explicaremos el sistema de recomendación para grupos de personas, que también es una funcionalidad de nuestra aplicación. Este sistema recoge las valoraciones de todos los usuarios para luego hacer una recomendación grupal. Veremos de una manera detallada cómo ha sido el proceso evolutivo desde la idea inicial hasta llegar a una aplicación real. Abstract Augmented Reality is a technology which allows to increase the real world that we sense with interactive virtual elements. In this report, we describe the use of this technology, among others, for obtaining information about movies. The application described is able to collect all information of a film with only focus your cover photo with the camera and can store and / or share this information. In addition, we will explain the recommendation system for groups of people, which is also a feature of our application. This system recollects the evaluations of all users and then makes a recommendation group. We will see in a detailed way how it has been the evolutionary process from the initial idea to reach a real application. i INDICE AUTORIZACIÓN ...............................................................................................................................................III AGRADECIMIENTOS ....................................................................................................................................... IV RESUMEN ....................................................................................................................................................... V RESUMEN .............................................................................................................................................................. V ABSTRACT .............................................................................................................................................................. V INDICE .............................................................................................................................................................. I INDICE DE FIGURAS ........................................................................................................................................ IV CAPÍTULO 1: INTRODUCCIÓN A MUVI .............................................................................................................. 1 1.1 INTRODUCCIÓN ................................................................................................................................................. 1 1.2 OBJETIVOS ....................................................................................................................................................... 2 1.3 ORGANIZACIÓN DE LA MEMORIA........................................................................................................................... 2 CAPÍTULO 2: ESTADO DEL ARTE ....................................................................................................................... 4 2.1 REALIDAD AUMENTADA ...................................................................................................................................... 4 2.1.1 Usos ....................................................................................................................................................... 5 2.1.2 Tecnologías ........................................................................................................................................... 8 2.2 FUENTES DE INFORMACIÓN DE PELÍCULAS ............................................................................................................. 10 2.2.1 Metacritic ............................................................................................................................................ 10 2.2.2 IMDb ................................................................................................................................................... 11 2.2.3 Rotten Tomatoes ................................................................................................................................. 12 2.2.4 TheMovieDb.Org ................................................................................................................................. 13 2.3 SISTEMAS DE RECOMENDACIÓN .......................................................................................................................... 14 2.3.1 Tipos .................................................................................................................................................... 14 2.3.2 Tecnologías ......................................................................................................................................... 17 2.4 SISTEMAS DE LOCALIZACIÓN CON DISPOSITIVOS BEACON ......................................................................................... 18 2.4.1 Usos ..................................................................................................................................................... 18 2.4.2 Tecnologías ......................................................................................................................................... 19 CAPÍTULO 3: FUNCIONALIDAD ....................................................................................................................... 22 3.1 FUNCIONES DE LA APLICACIÓN ........................................................................................................................... 22 3.2 FLUJO DE LA APLICACIÓN .................................................................................................................................. 22 3.3 PRIMEROS PROTOTIPOS .................................................................................................................................... 24 3.4 INTERFAZ DE USUARIO ...................................................................................................................................... 26 3.4.1 Interfaz de Registro ............................................................................................................................. 26 3.4.2 Interfaz de Iniciar Sesión ..................................................................................................................... 27 3.4.3 Interfaz de Inicio .................................................................................................................................. 28 3.4.4 Interfaz de Realidad Aumentada ........................................................................................................ 30 3.4.5 Interfaz de Me Gusta .......................................................................................................................... 35 3.4.6 Interfaz de Ficha de Película................................................................................................................ 36 3.4.7 Interfaz de Gente Cercana .................................................................................................................. 38 CAPÍTULO 4: IMPLEMENTACIÓN .................................................................................................................... 40 4.1 ARQUITECTURA ............................................................................................................................................... 40 4.1.1 Relación entre front-end y back-end ................................................................................................... 41 4.2 IMPLEMENTACIÓN DEL BACK-END ....................................................................................................................... 42 4.2.1 Arquitectura de servicios ..................................................................................................................... 43 4.2.2 Base de datos ...................................................................................................................................... 46 4.2.3 Sistema de recomendación ................................................................................................................. 48 ii 4.2.4 Servidor ............................................................................................................................................... 50 4.2.5 Fuente de información sobre películas................................................................................................ 50 4.3 IMPLEMENTACIÓN DEL FRONT-END ..................................................................................................................... 51 4.3.1 Entorno de desarrollo .......................................................................................................................... 52 4.3.2 Realidad Aumentada........................................................................................................................... 53 4.3.3 Tecnologías ......................................................................................................................................... 54 4.3.4 Herramientas ...................................................................................................................................... 57 4.4 PRUEBAS DE ARQUITECTURA .............................................................................................................................. 58 4.4.1 Pruebas de realidad aumentada ......................................................................................................... 58 4.4.2 Pruebas de servicios web REST con Jersey .......................................................................................... 63 4.4.3 Pruebas con Hibernate/JPA ................................................................................................................. 64 4.4.4 Pruebas de los servicios de redes sociales ........................................................................................... 65 4.4.5 Pruebas de geolocalización ................................................................................................................. 68 CAPÍTULO 5: EVALUACIÓN DE USUARIOS ...................................................................................................... 70 5.1 PLAN DE EVALUACIÓN ....................................................................................................................................... 70 5.1.1 ¿Qué estamos evaluando? .................................................................................................................. 70 5.1.2 Propósito de la evaluación .................................................................................................................. 70 5.1.3 Objetivos generales ............................................................................................................................. 71 5.1.4 Preguntas de investigación ................................................................................................................. 71 5.1.5 Requisitos de los participantes ............................................................................................................ 71 5.1.6 Diseño experimental ........................................................................................................................... 71 5.1.7 Tareas a realizar .................................................................................................................................. 72 5.1.8 Entorno y herramientas empleadas .................................................................................................... 72 5.1.9 Obtención de feedback de los participantes ....................................................................................... 73 5.1.10 Tareas del moderador ....................................................................................................................... 73 5.1.11 Descripción de la metodología de análisis de datos ......................................................................... 73 5.2 EVALUACIÓN .................................................................................................................................................. 74 5.2.1 Observaciones y opiniones de los usuarios ......................................................................................... 74 5.2.2 Resultado cuestionario SUS ................................................................................................................. 76 CAPÍTULO 6: CONCLUSIONES ......................................................................................................................... 78 6.1 CONCLUSIONES ............................................................................................................................................... 78 6.2 CONCLUSIONS ................................................................................................................................................. 80 CAPÍTULO 7: TRABAJO FUTURO ..................................................................................................................... 83 CAPÍTULO 8: ORGANIZACIÓN DEL TRABAJO ................................................................................................... 85 8.1 MODELO DE DESARROLLO ................................................................................................................................. 88 8.2 HERRAMIENTAS DE COMUNICACIÓN .................................................................................................................... 88 8.3 HERRAMIENTAS DE CONTROL DE VERSIONES .......................................................................................................... 88 8.4 HERRAMIENTAS DE GESTIÓN DE TAREAS ............................................................................................................... 89 CAPÍTULO 9: APORTACIONES AL PROYECTO .................................................................................................. 90 9.1 CRISTINA DELGADO RODRÍGUEZ ......................................................................................................................... 90 9.2 IGNACIO ROCILLO LANDA .................................................................................................................................. 93 9.3 JORGE MUÑOZ RODRÍGUEZ ............................................................................................................................... 94 9.4 JORGE RUEDA GARZÓN..................................................................................................................................... 96 9.5 SERGIO FUENTES URABAYEN .............................................................................................................................. 98 REFERENCIAS ............................................................................................................................................... 100 ANEXOS ....................................................................................................................................................... 103 ANEXO I: API REST ........................................................................................................................................... 103 1. Usuarios ............................................................................................................................................ 103 2. Películas............................................................................................................................................. 105 iii 3. Valoraciones ...................................................................................................................................... 108 4. Deseos ............................................................................................................................................... 109 5. Recomendaciones.............................................................................................................................. 111 6. Geolocalización (GPS) ........................................................................................................................ 111 7. Beacons ............................................................................................................................................. 113 4/117 Capítulo 2: ESTADO DEL ARTE En este apartado expondremos las tecnologías que más importancia tienen para nuestro proyecto: realidad aumentada, fuentes de información de películas, sistemas de recomendación y sistemas de localización mediante dispositivos Beacon. Estudiaremos los diferentes usos que se le da a estas tecnologías, detallaremos su funcionamiento y también veremos en qué aplicaciones del mercado se usan. 2.1 Realidad aumentada La realidad aumentada (1) (en adelante RA) es el término que se utiliza para definir la visión de elementos virtuales interactivos (datos, información), en un entorno real, a través de un dispositivo. Para utilizarla en la actualidad, únicamente es necesario tener un dispositivo con una cámara y una pantalla, lo que hace de los Smartphone un dispositivo perfecto para utilizar esta tecnología. Además de en dispositivos móviles y ordenadores, se están creando dispositivos centrados en RA, como las gafas de las empresas Google y Microsoft. Es por esto, que se dice que actualmente junto a la realidad virtual, la RA es una tecnología en auge. Con el paso del tiempo, más compañías están trabajando en incluir RA de múltiples formas, ya no sólo en aplicaciones de ocio y entretenimiento, como es el caso de este proyecto, sino también en otros ámbitos, como arqueología, medicina o uso militar. Su funcionamiento consiste en mostrar, a través de la pantalla del dispositivo y sobre la imagen captada por la cámara, información virtual que complementan lo visto en la realidad y permite la interacción en tiempo real entre el usuario y la información. Para poder mostrarla, se utiliza el reconocimiento de marcadores como tarjetas de códigos QR, carteles de películas, etc. En el siguiente apartado se explican los usos más importantes de esta tecnología. 5/117 2.1.1 Usos La RA se está utilizando en múltiples ámbitos, entre ellos: Arqueología Puede utilizarse para “reconstruir” las edificaciones en yacimientos y lugares antiguos en los que únicamente quedan los restos de épocas pasadas. Un ejemplo de ello es la guía interactiva del Museo al Aire Libre del yacimiento de la Villa Romana de l´Albir, en Alicante (2). Gracias a ella, se puede visualizar en la pantalla del dispositivo una representación 3D del conjunto de las termas sobre el yacimiento y ayudar a mostrar el funcionamiento de las estancias de los baños. Arquitectura Gracias a la RA se puede visualizar cómo quedarían construcciones en un determinado lugar gracias a la creación de objetos 3D en entornos reales, o para visualizar la maqueta de una construcción u obra a la hora de enseñar un proyecto. Figura 1: Ejemplo de uso en la arqueología Figura 2: Ejemplo de uso en la arquitectura 6/117 Medicina Algunos de los usos de la RA en medicina son ayudar a personas autistas a interactuar en un entorno social (3), enseñanza especializada, ayuda en operaciones reconociendo tumores (4), etc. Un ejemplo de enseñanza especializada en medicina es mARble, una aplicación desarrollada por el Colegio de Medicina de Hannover (5) para ayudar a estudiantes de medicina a ganar experiencia gracias a la RA. Proyecta “enfermedades virtuales” en sujetos sanos y muestra textos, videos y gráficos sobre la enfermedad. Figura 3: Ejemplo de uso en la medicina Uso militar El ejército de Estados Unidos creó cascos “inteligentes” con un visor de RA diseñado para el campo de batalla. El sistema muestra información como la localización de los enemigos, imágenes satélites o su orden actual. El software se ejecuta en un dispositivo junto al casco. Gracias a una cámara, puede rastrear lo que el soldado está viendo y mostrar la información en el monitor (6). Figura 4: Ejemplo de uso militar 7/117 Museos La RA en los museos está siendo utilizada para mostrar más información e interactuar con obras y objetos. Muchos museos de todo el mundo están empezando a incorporar RA, como es el caso del Museo Británico, el Museo de Londres o el Museo de América de Madrid, con la aplicación RACMA (7), la cual ayuda a mostrar las colecciones más destacadas de las culturas expuestas gracias al poder de la RA. Videojuegos En los últimos años, muchas compañías han querido adentrarse en el mundo de la RA con videojuegos para consolas portátiles y smartphones . Quizás el máximo representante de esta categoría es la empresa española Novarama, creadores de Invinzimals (8), juego original de PSP, y que posteriormente salió en muchos más dispositivos. En él, con la ayuda de una tarjeta marcadora y la cámara de la consola o smartphones , asistimos a batallas de monstruos en la mesa de nuestra habitación. Figura 5: Ejemplo de uso en museo Figura 6: Ejemplo de uso en los videojuegos 8/117 2.1.2 Tecnologías Actualmente hay muchas librerías para programar y desarrollar RA. Para comprobar cuál de ellas se acercaba más a nuestras necesidades buscamos diferentes alternativas. Algunas de ellas son estas: OpenCV OpenCV (9) es una librería open source de visión artificial desarrollada por Intel. Se utiliza tanto en sistemas de seguridad con detección de movimiento como en reconocimiento de objetos o RA. Es multiplataforma, existen versiones para GNU/Linux, Mac y Windows, y tiene funciones que van desde el reconocimiento de objetos a la visión robótica. Vuforia Vuforia (10) es una librería que permite construir aplicaciones basadas en RA. Ofrece reconocimiento de texto, reconocimiento de imágenes, detección rápida y rastreo simultáneo y robusto de objetivos. Puede desarrollarse en Unity, Java, C++ y es compatible con iOS y Android. Su arquitectura consiste en:  Cámara: permite captar la imagen en busca del Target (objetivo).  Base de datos: puede ser local o en la nube. Almacena una colección de Targets para poder reconocerlos con el Tracker .  Target: son los objetivos a reconocer. Pueden ser Image Targets (imágenes, tales fotos, páginas de revista, posters, etc.) o Word Targets (palabras, frases, etc.)-  Tracker: analiza la imagen de la cámara y detecta objetos a través de la cámara con el fin de encontrar coincidencias con la base de datos. Metaio Compañía de RA (11) que desarrollaba software de RA comprada por Apple. Ofrece diferentes productos para crear aplicaciones de RA:  Metaio SDK: herramienta para crear aplicaciones para Android, iOS y Windows con un plugin adicional en Unity.  Metaio Creator: permite crear aplicaciones RA sin conocimientos especializados en programación, a través de una interfaz Drag and Drop.  Metaio CVS: servicio de búsqueda para reconocer imágenes instantáneamente. 9/117 Mixare Mixare (12) es una aplicación que trabaja de forma totalmente autónoma y que está disponible para el desarrollo de aplicaciones propias publicada bajo licencia GPLv3. Está disponible para iOS y Android. ARToolKit ARToolKit (13) es una librería software para la realización de aplicaciones de RA. Utiliza algoritmos de visión computacional para buscar el punto de vista de los usuarios. Entre sus características se encuentran la distribución completa del código fuente, calibración sencilla de la cámara y distribuciones para Linux, Mac OS, Windows OS. Wikitude Wikitude (14) es una tecnología para dispositivos móviles de pago que posee un kit de desarrollo de RA. Algunas de las características de Wikitude son:  API nativa y API JavaScript: permite la programación para Android/iOS o con tecnologías web como JavaScript.  Servicios de localización basados en datos de geolocalización.  Posee extensiones para Cordova, Titanium, Xamarin y Unity.  Permite el desarrollo de aplicaciones para Smart Glasses.  Permite añadir videos, modelos 3D, imágenes y elementos HTML.  Incorpora reconocimiento de imágenes y seguimiento: permite reconocimiento en la nube y en local de 1000 imágenes. 10/117 2.2 Fuentes de información de películas Debido a que la aplicación muestra información de películas y valoraciones, y esta información es cambiante y dinámica, necesitamos saber de dónde extraer está información. Por ello investigamos las principales webs y bases de datos de películas para comprobar cuál de ellas ofrece todo lo que queremos mostrar. 2.2.1 Metacritic Metacritic (15) es una de las webs más conocidas de análisis de Estados Unidos, propiedad de la cadena de televisión CBS. Es conocida por agrupar todos los análisis de películas, videojuegos, series y música de la prensa especializada de todo el mundo y hacer una media con todas ellas. Además, todos los usuarios pueden valorar igualmente y realiza también una media con todas las opiniones. Poseía una API no oficial que finalmente fue cerrada por los creadores del sitio. Figura 7: Ejemplo de Metacritic 11/117 2.2.2 IMDb IMDb (Internet Movie Database) (16) es una de las bases de datos de cine más grandes de Internet. Contiene información de películas, actores, series de televisión, actores de doblaje e incluso de personajes ficticios. Actualmente es propiedad de Amazon. Contiene mucha información sobre cada una de las películas: valoraciones, análisis, directores, guionistas, actores, fecha de estreno, noticias relacionadas con la película, películas parecidas, etc. Una característica poco común en las bases de datos de películas es que además de toda esta información, se incluye el elenco total de personas que han participado en la película, desde asistentes de sonido hasta extras. OMDb (17) es la API no oficial de IMDb, gratuita, y que contiene información como el género, fecha de lanzamiento, sinopsis… Figura 8: Ejemplo de IMDb 12/117 2.2.3 Rotten Tomatoes Rotten Tomatoes (18) es otra de las webs de opinión más importantes y conocidas de la industria del cine y la televisión. Como Metacritic, recoge críticas tanto de medios especializados como del público, además de mostrar información de la película como duración, presupuesto, casting y noticias relacionadas. Posee una API (19) que requiere de clave de acceso y tiene un número limitado de usos por día y requiere permiso por parte del equipo de Rotten Tomatoes para poder utilizarse fuera de los Estados Unidos. Figura 9: Ejemplo de Rotten Tomatoes 13/117 2.2.4 TheMovieDb.Org TheMovieDb.org (20) es una base de datos de películas y series. Es pública, por lo que cualquier persona puede añadir una nueva película, o actualizar una existente. Entre la información que muestra se encuentra la habitual de este tipo de páginas, duración, sinopsis, valoración de los usuarios de la web, etc. Además de su presupuesto, se pueden ver los ingresos que ha obtenido la película, y como ocurre en IMDb, también se puede ver todo el reparto de la película, incluyendo operadores de cámara, maquilladores, etc. Incluye una API (21) que también necesita una clave de acceso, pero puede usarse fuera de los Estados Unidos y muestra mucha información de la película como tráiler, sinopsis… Figura 10: Ejemplo de Rotten Tomatoes 20/117 Figura 15: Ilustración y aplicación de los Estimote Beacons RadBeacon RadBeacon (28), ofrece hasta tres tipos de Beacons dependiendo de las necesidades de conectarlo con una fuente de carga para su funcionamiento yendo desde conexión USB, a toma eléctrica o de forma autónoma. Estos dispositivos están más pensados para dar una gestión y seguridad de estas balizas mucho más avanzada, pudiendo configurar y supervisar las diferentes balizas mediante un servicio en la nube y siendo compatible estos dispositivos con servicios API REST. Son compatibles con IBeacon(iOS), AltBeacon y Eddystone Beacon(Android). Figura 16: Ilustración de los diferentes dispositivos de RadBeacon Bluecat Beacon Bluecat Beacon (29) utilizan como forma de fuente de carga pilas convencionales, donde nos ofrece unas herramientas para monitorizar y configurar nuestros Beacons en la nube. Ofrece un SDK bastante claro para que en unos minutos podamos realizar nuestro primer proyecto. Es compatible con iBeacon(iOs) y Eddystone(Android). 21/117 Figura 17: Partes de que se compone Bluecat Beacon Kontakt.io Beacon Kontakt.io (30) nos ofrece un único formato de Beacon el cual no necesita ninguna fuente externa de recarga. Además, nos pone a nuestra disposición las siguientes herramientas: Proximity Web Panel: Es una plataforma fácil de usar que permite configurar y administrar la infraestructura de los Beacons, donde permite organizar despliegues en lugares virtuales, cambiar la configuración y los perfiles de las balizas de forma individual o en masa. Proximity REST API: Permite una creación de una herramienta de configuración y administración o usar la plataforma ya existente que ofrece para los desarrolladores. Integra también soluciones para la seguridad administración masiva, análisis e información instantánea acerca de los Beacons. El SDK de Kontakt.io es compatible con Eddystone (Android superiores a 4.3 para un correcto funcionamiento) y iBeacon (iOs 8.0 o superiores). Figura 18: Ilustración del modelo Kontakt.io 22/117 Capítulo 3: FUNCIONALIDAD En este capítulo, describiremos de todas las funcionalidades que tiene la aplicación a modo de manual de usuario, viendo a través de diagramas cuál sería el flujo de estados de la aplicación. MUVI es una aplicación, como ya hemos comentado anteriormente, basada en RA, con la que se puede obtener información sobre películas utilizando las carteleras de las películas. Además, se puede compartir dicha información, almacenar tus películas favoritas y valorarlas. Debido a que MUVI está pensada para ser una aplicación social es necesario almacenar la información de los usuarios y, por eso, se requiere que todos los usuarios se registren en la aplicación antes de poder usar todas las funcionalidades. Además, hacemos uso de los dispositivos Beacon para comprobar qué amigos están cerca de nosotros cuando escaneamos una película y así poder recomendar dicha película al grupo o no, además de poder mostrar la recomendación individual del usuario. 3.1 Funciones de la Aplicación Antes de entrar en detalle en el flujo de la aplicación y explicar detalladamente cada interfaz que tiene nuestra aplicación, contaremos cuáles son sus funcionalidades básicas. La principal funcionalidad de nuestra aplicación es la RA. Ahí, el usuario puede realizar la mayoría de funcionalidades de la aplicación simplemente apuntando al cartel de una película. Puede ver información sobre una película, valorar una película, ver el tráiler, compartir en Twitter, añadir a la lista de Me Gusta y ver la puntuación que la aplicación estima de la película escaneada para tus amigos conectados al mismo dispositivo Beacon que tú. Fuera de la RA, podemos ver en una interfaz sencilla e intuitiva las películas que hemos añadido a nuestra lista de Me Gusta y la información de esas películas sin tener que volver a entrar a la RA. Además, el usuario, gracias al uso del GPS, puede ver las películas que sus amigos cercanos han añadido a Me Gusta para hacerse así una idea de qué película ver. 3.2 Flujo de la Aplicación La primera pantalla que verá el usuario es la interfaz de Registro. Aquí el usuario introducirá sus datos para registrarse. Una vez registrados, lo siguiente es iniciar sesión. Para ello, se tiene que introducir el nombre de usuario y contraseña con la que se haya registrado el usuario en la interfaz de Inicio de Sesión. Una vez terminado el proceso de registro y/o inicio de sesión se accede a la interfaz de Inicio, desde la cual se puede acceder a todas las funcionalidades de la aplicación. Para ello, se 23/117 dispone de una barra de menú desplegable a la que se puede acceder pulsando sobre el botón de la esquina superior izquierda o simplemente deslizando el dedo de izquierda a derecha. Además del menú se puede acceder a la RA pulsando sobre la imagen principal que hay en la pantalla de inicio. Cuando el usuario entra en la interfaz de RA se abrirá la cámara del dispositivo móvil que se esté utilizando. Para poder capturar los posters de películas lo único que hay que hacer es enfocar con la cámara sobre el poster. Si la aplicación detecta el poster, aparecerán varios botones alrededor de él. Los botones tienen diversas funciones: añadir la película a la lista de Me Gusta, valorar la película, ver tráiler, etc. Todas estas funcionalidades se explicarán en detalle más adelante. De vuelta a la interfaz de Inicio, el usuario puede elegir entre varias opciones. En la 3.4.5 Interfaz de Me Gusta puede ver todas las películas que haya guardado desde la 3.4.4 Interfaz de Realidad Aumentada. Estas películas son interactivas, de forma que si el usuario pulsa sobre la imagen de la película, la aplicación le redirigirá a la 3.4.6 Interfaz de Ficha de Película. En esta interfaz se muestra toda la información relevante de la película: título, sinopsis, género, etc. En la siguiente figura se muestra el flujo de todas las interfaces de la aplicación, desde la interfaz de Registro hasta la de Ficha de Película. Figura 19: Flujo de las interfaces de la aplicación 24/117 3.3 Primeros prototipos La aplicación que en un principio teníamos pensada y la que finalmente ha resultado no se parece mucho. En un principio, se pensó en hacer secciones diferentes como la búsqueda de películas, así como un historial de todas las capturas de la RA. Estas primeras ideas se plasmaron en unos dibujos sencillos como primeros prototipos. Figura 20: Prototipo de interfaz de búsqueda Figura 21: Ilustración del modelo Kontakt.io Según avanzábamos en la definición de la aplicación, la mayoría de las posibles funcionalidades se desechaban, ya que no se centraban en lo que de verdad importaba, la RA. Para los siguientes prototipos utilizamos herramientas específicas como proto.io. De este modo, nos acercábamos a una primera versión de las interfaces. Para la interfaz de inicio se pensó en tener la mitad de la pantalla con una pre-visualización de la cámara, para que así el usuario pudiera capturar posters nada más entrar en la aplicación. Sin embargo, se rechazó esta idea porque tener la cámara encendida siempre que se esté usando la aplicación, reduciría en exceso la memoria y usaría demasiado la batería del dispositivo. 25/117 Figura 22: Primer prototipo de la interfaz de inicio Como se puede observar en la figura, este prototipo constaba de una barra de herramientas en la parte de abajo. Esta idea fue perdiendo peso debido a que si se añadieran más funcionalidades tendríamos una barra demasiado llena de iconos. Para arreglar este problema nos decantamos por usar un menú desplegable. Figura 23: Segundo prototipo de la interfaz de inicio 26/117 3.4 Interfaz de usuario En los próximos apartados se explican las diferentes interfaces de usuario de la aplicación: 3.4.1 Interfaz de Registro Figura 24: Interfaz de registro El objetivo de esta interfaz es que los usuarios se den de alta en la aplicación. Se trata de un registro básico en el que se requiere que el usuario escriba su nombre, un nombre de usuario, su correo y una contraseña. Como hemos explicado anteriormente, al ser una aplicación social es necesario guardar la información de los usuarios, por eso es necesario que todos los usuarios se registren. La aplicación hace varias comprobaciones de los datos insertados: si el nombre de usuario es único, si ningún campo está vacío y si el correo tiene un formato válido. 27/117 Si alguna de estas condiciones no se cumple, la aplicación mostrará un mensaje de error indicando que es lo que el usuario tiene que hacer. Si el registro es exitoso, la aplicación redirigirá a la interfaz de “Iniciar Sesión” para que el usuario pueda empezar a utilizar los servicios. Cuando el usuario pulse “Login” se abrirá la interfaz de “Iniciar Sesión”. A continuación, se presenta un diagrama de actividad para entender el flujo de actividad que tiene esta funcionalidad: Figura 25: Diagrama de actividad de registro 3.4.2 Interfaz de Iniciar Sesión Figura 26: Interfaz de inicio de sesión 28/117 El objetivo de esta interfaz es iniciar sesión en la aplicación para poder comenzar a hacer uso del resto de funcionalidades. Para ello, el usuario debe de introducir el nombre de usuario y contraseña que utilizó cuando hizo el registro. Cuando el usuario pulse “Acceder” se comprueba que los datos introducidos son correctos y que éste existe en la base de datos de la aplicación. Hay dos opciones: si existe y los datos son correctos: entonces se inicia la sesión y se abre la ventana de inicio. Si no existe o los datos son incorrectos, entonces se notifica al usuario para que corrija los datos y vuelva a intentarlo. Cuando el usuario pulse “Registrarse” se abrirá la interfaz de “Registro”. A continuación, se presenta un diagrama de actividad para entender el flujo de actividad que tiene esta funcionalidad: Figura 27: Diagrama de actividad de la interfaz de inicio de sesión 3.4.3 Interfaz de Inicio Figura 28: Interfaz de inicio y menú lateral 29/117 La interfaz de Inicio es la interfaz principal de la aplicación. Desde ella se puede acceder a cada una de las funcionalidades de la aplicación. Consta de dos elementos: 1. Una imagen principal “pulsable” con el que el usuario puede ir a la interfaz de RA. 2. Un carrusel con las películas que están arrasando en taquilla. Además, esta interfaz tiene una barra de navegación en la parte superior con la que se puede acceder al menú. El menú tiene una lista de botones para poder ir a cualquier punto de la aplicación. La finalidad de esta interfaz es dar la bienvenida a los usuarios. Una vez realicen correctamente el registro y posterior inicio de sesión, serán la primera pantalla que vean. A continuación, se presenta un diagrama de actividad para entender el flujo de actividad que tiene esta funcionalidad: Figura 29: Diagrama de actividad de inicio 36/117 A continuación, se presenta un diagrama de actividad para entender el flujo de actividad que tiene esta funcionalidad. Figura 39: Diagrama de actividad de Me Gusta 3.4.6 Interfaz de Ficha de Película Figura 40: Interfaz de ficha de película 37/117 En esta interfaz se ofrece una descripción de una película. Para ello, primero se tiene que seleccionar dicha película desde la 3.4.5 Interfaz de Me Gusta . Se muestran diferentes datos de la película, como son:  Título: se muestra el Título en el idioma original de la película.  Foto del cartel: se muestra la foto del cartel de la película.  Valoración: se muestran cinco estrellas, que dependiendo de la valoración que tenga la película, serán amarillas o grises. Por ejemplo, la película “Marte” tiene una valoración de 3 sobre 5, entonces esta película tendrá 3 estrellas amarillas y 2 grises. Las valoraciones que se muestran son las que haya en la fuente externa. En este caso, las valoraciones de IMDb.  Tráiler: es un botón que al pulsarlo redirige al tráiler en YouTube.  Géneros: se muestran los géneros a los que pertenece la película.  Sinopsis: se muestra un resumen de la trama de la película. El texto está en el idioma original. A continuación, se presenta un diagrama de actividad para entender el flujo de actividad que tiene esta funcionalidad. Figura 41: Diagrama de actividad de Ficha de Película 38/117 3.4.7 Interfaz de Gente Cercana Figura 42: Interfaz de Gente Cercana La finalidad de esta interfaz es ofrecer al usuario una idea de que películas están teniendo más éxito entre las personas que le rodean, ofreciéndole una idea de qué película podría ver. Esta interfaz se dispone a mostrar las personas cercanas al usuario, pudiendo consultar las películas favoritas de cada una que se haya añadido desde la RA. Primero, se mostrará una lista de personas y si el usuario quiere saber los gustos de las mismas tendrá que pulsar sobre una de ellas. Por otro lado, si el usuario vuelve a accionar este botón se ocultará la lista de películas de dicha persona. Por último, el usuario puede ir a la RA pulsando el botón flotante de la esquina derecha. 39/117 A continuación, se presenta un diagrama de actividad para entender el flujo de actividad que tiene esta funcionalidad. Figura 43: Diagrama de actividad de Gente Cercana 40/117 Capítulo 4: IMPLEMENTACIÓN En este apartado se detalla la arquitectura de la aplicación y el proceso de creación de la misma, incluyendo las distintas tecnologías implicadas, los lenguajes de programación y entornos de desarrollo utilizados, así como las diferentes pruebas realizadas como toma de contacto con dichas tecnologías. 4.1 Arquitectura Figura 44: Arquitectura de la aplicación La arquitectura de nuestra aplicación es una arquitectura cliente-servidor . Se trata de un sistema en el que existen clientes ( front-end ), que solicitan servicios, y servidores ( back-end ), que los proporcionan. Esta comunicación se realiza a través de Internet y, en nuestro caso, el formato de los datos que intercambian es JSON. En la parte servidor o back-end , existe una API REST de servicios, los cuales implementan funcionalidades que requieren hacer uso de los recursos del sistema. Se entiende por recurso la información almacenada en la base de datos. Estos servicios se encuentran alojados en un servidor proporcionado por la Facultad de Informática. Los datos son almacenados en dos tipos de bases de datos diferentes: MySQL y MongoDB. La parte cliente o front-end corresponde con nuestra aplicación MUVI, que puede ser instalada en cualquier dispositivo Android. Nuestra aplicación hace uso de los dispositivos Beacon, 41/117 orientados a la localización en indoor . También utiliza el sistema de localización GPS, orientado a la localización en exteriores. 4.1.1 Relación entre front-end y back-end En este apartado se explica el uso que la aplicación MUVI ( front-end ) hace de los servicios de la API ( back-end ). El objetivo es plasmar con mayor claridad la relación que existe entre frontend y back-end , es decir, el funcionamiento de la aplicación un poco más a bajo nivel, antes de explicar cómo se han implementado ambas partes por separado más adelante. Los servicios que se consumen desde la interfaz de RA corresponden con los siguientes recursos del sistema:  El recurso de películas se utiliza para consultar la información de una película escaneada cuando el usuario desea ver su información.  El recurso de valoraciones se utiliza para añadir la valoración de un usuario cuando realiza una valoración de la película escaneada y para consultar las valoraciones que amigos cercanos han realizado de la dicha película.  El recurso de deseos se utiliza para añadir la película a la lista de deseos del usuario cuando éste la añade a favoritos.  El recurso de sistema de recomendación se utiliza para estimar lo que a alguno de los amigos cercanos les gustaría la película escaneada cuando éste no ha valorado dicha película con anterioridad.  El recurso de dispositivos Beacon corresponde con los datos de las conexiones entre usuarios y beacons almacenados en la base de datos provenientes del escaneo de beacons realizado en el front-end , en concreto, en la interfaz de RA. Se utiliza tanto para almacenar cierta información de un usuario y de un beacon que están conectados, como para eliminarla si pasa cierto tiempo desde que el dispositivo del usuario escaneó ese beacon por última vez. Los servicios que se consumen desde el resto de interfaces de la aplicación corresponden con los siguientes recursos del sistema:  El recurso de usuarios se utiliza para guardar los datos de un usuario si crea una cuenta a través de la interfaz de Registro o para consultar los datos del mismo si desea acceder a la aplicación a través de la interfaz de Inicio de Sesión.  El recurso de películas se utiliza consultar la información de una película cuando se necesita mostrar dicha información en la interfaz de Ficha de Película.  El recurso de deseos se utiliza para consultar las películas que le gustan al usuario cuando se necesita mostrar dichas películas en la interfaz de Me Gusta. También se 42/117 utiliza en la interfaz de Gente Cercana para consultar que películas le gustan a cada uno de los usuarios cercanos.  El recurso de GPS corresponde con los datos de ubicación almacenados en la base de datos provenientes del uso del sistema de localización GPS en el front-end . Se utiliza en la interfaz de Gente Cercana, tanto para añadir la ubicación de usuarios cercanos, como para consultar los usuarios cercanos cuando se necesita mostrar dichos usuarios. 4.2 Implementación del back-end Los módulos de los que se compone el back-end son los siguientes: Figura 45: Módulos del back-end Las relaciones entre los módulos se representan con una línea que los une. A continuación, se explican cada una de estas relaciones: El módulo de usuarios gestiona la información de los usuarios almacenada en la base de datos relacional en MySQL. El módulo de películas obtiene la información de las películas de una fuente de información externa, en nuestro caso TheMovieDB, y por eso está relacionado con el módulo de TheMovieDB. La información que obtiene de TheMovieDB, la gestiona, almacenando parte de ella en la base de datos relacional en MySQL. El módulo de deseos gestiona las listas de películas deseadas de los usuarios. Es por esta razón que está relacionado con ambos. Los módulos que almacenan la información en la base de datos relacional MySQL es por eso que están relacionados con el módulo de MySQL. El módulo de valoraciones gestiona la información de las valoraciones que realizan los usuarios de nuestro sistema sobre las películas. Es por esta razón que está relacionado, tanto con los 43/117 usuarios, como con las películas. Por otro lado, estas valoraciones realizadas por los usuarios de nuestro sistema, junto con las valoraciones del dataset MovieTweetings, se utilizan en nuestro sistema de recomendación. Por ello, tanto el módulo de valoraciones, como el módulo de MovieTweetings, están relacionados con el módulo de recomendación. En un principio se diseñó el back-end pensando en que el sistema de recomendación se basara en datos de valoraciones que se almacenaran en MongoDB. Posteriormente, la tecnología con la que se implementó el sistema de recomendación no permitía acceder a los datos directamente desde MongoDB, sino que requería de un fichero de datos. De este hecho se deriva que las valoraciones de nuestro sistema se almacenen y consulten en MongoDB y que ambos módulos estén relacionados. Se explica con más detalle en el apartado 4.2.3 Sistema de recomendación de este documento. La funcionalidad que interactúa con los sistemas de localización, tanto dispositivos Beacon, como GPS, se implementa en el front-end . Sin embargo, los datos que es necesario persistir se envían al back-end y se almacenan en MongoDB. Es por esta razón que existen los módulos de beacons y GPS . El módulo de beacons gestiona los datos de las conexiones entre dispositivos Beacon y usuarios, almacenados en MongoDB. El módulo de GPS gestiona los datos de ubicación de los usuarios obtenidos a través del sistema de localización GPS, almacenados en MongoDB, y obtiene, a partir de ellos, los usuarios cercanos dentro de un rango de distancia. Los módulos que almacenan la información en la base de datos orientada a documentos MongoDB es por eso que están relacionados con el módulo de MongoDB. A continuación, se detalla cómo se ha implementado este back-end , incluyendo la explicación de la arquitectura de los servicios y la documentación de los mismos, así como las diferentes tecnologías utilizadas en su desarrollo, para la persistencia de los datos y en el sistema de recomendación. También se explican las tareas y problemáticas derivadas del servidor experimental proporcionado por la Facultad de Informática. 4.2.1 Arquitectura de servicios REST (REpresentational State Transfer) es un tipo de arquitectura de servicios que se apoya en el estándar HTTP. Se definió en el año 2000 por Roy Fielding, coautor de la especificación HTTP. Existen varios niveles de cumplimiento de los principios REST. Se describen en un modelo llamado Richardson Maturity Model ( en adelante RMM ) (31), cuyo autor es Leonard Richardson, padre de la arquitectura orientada a recursos.  Nivel 0 – Swamp of POX: Los servidores utilizan HTTP, pero únicamente como medio de transporte. Ejemplo: SOAP 44/117  Nivel 1 – Recursos: Los servicios utilizan las URIs HTTP para distinguir los recursos del sistema. Se entiende por recurso la información a la que se quiere acceder, modificar o borrar, independientemente de su formato. Estas URIs permiten identificar de forma única el recurso.  Nivel 2 – Verbos HTTP: Los servicios se aprovechan de las características nativas de HTTP como cabeceras, códigos de estado, métodos, etc. Ejemplo: Amazon S3  Nivel 3 – Hypermedia: Los servicios utilizan HATEOAS (Hypermedia as the Engine of Application State). HATEOAS es una restricción que implica que el cliente interactúa con el servidor a través de hipermedias proporcionadas dinámicamente por el propio servidor. Nuestra API se encuentra en el nivel 2. Siendo estrictos con la definición original de REST realizada por Roy Fielding, nuestra API no sería REST, porque no utilizamos hipermedias (32). Sin embargo, son muchas las grandes empresas (Flickr, Twitter, Git, Amazon S3…) que dicen tener una API REST y tampoco respetan la definición original. Las características de nuestra API serían las siguientes:  Uso correcto de URIs (Nivel 1 del modelo RRM): o Los nombres de URI no implican acciones, es decir, no se utilizan verbos. o Cada URI es única y no existen dos URIs que identifiquen el mismo recurso. o Son independientes del formato. o Mantienen una jerarquía lógica. o Los filtrados de información de un recurso no se hacen en la URI.  Uso correcto de HTTP (Nivel 2 del modelo RRM): o Se utilizan los verbos HTTP apropiados para cada acción concreta (GET, POST, DELETE…). o Se utilizan los códigos de error/estado HTTP en las respuestas a las peticiones. o Se especifica el formato del recurso a través de HTTP. La principal referencia a la hora de entender y aplicar estas características en nuestra API ha sido un artículo de Asier Marqués en los que resume algunos de los conceptos más importantes que caracterizan a las APIs REST (33). Nuestra API REST de servicios implementa servicios relacionados con los distintos recursos del sistema: los usuarios, las películas, las valoraciones de los usuarios, los deseos del usuario, el sistema de recomendación, la geolocalización GPS y los dispositivos Beacon. Los servicios relacionados con los usuarios son:  Login de un usuario: comprueba los datos de acceso de un usuario. 45/117  Registro de un usuario: registra un nuevo usuario en nuestro sistema.  Buscar un usuario: busca un usuario por su nombre. Los servicios relacionados con las películas son:  Buscar información de una película: busca la información de una película por su título.  Listar películas: lista las películas que coinciden con un título (máximo 5 películas). Los servicios relacionados con las valoraciones de los usuarios son:  Añadir una valoración de un usuario: añade una valoración de una película realizada por un usuario al sistema.  Mostrar una valoración de un usuario: muestra la valoración de una película realizada por un usuario. Los servicios relacionados con los deseos del usuario son:  Añadir un deseo de un usuario: añade una película a la lista de deseos de un usuario.  Listar los deseos de un usuario: lista las películas de la lista de deseos de un usuario.  Eliminar un deseo de un usuario: elimina una película de la lista de deseos de un usuario. Los servicios relacionados con el sistema de recomendación son:  Estimar una recomendación: estima la valoración que un usuario daría a una película. Los servicios relacionados con la geolocalización GPS son:  Añadir ubicación de un usuario: añade la ubicación de un usuario al sistema.  Eliminar ubicación de un usuario: elimina la ubicación de un usuario del sistema.  Listar usuarios cercanos: lista los usuarios cercanos con respecto a la ubicación actual. Los servicios relacionados con los dispositivos Beacon son:  Asociar un usuario a un beacon : asocia un usuario a un dispositivo Beacon cuando se conecta a dicho dispositivo.  Elimina un usuario de un beacon : elimina un usuario de un dispositivo Beacon una vez ha pasado cierto tiempo desconectado.  Listar los usuarios de un beacon : Lista los usuarios conectados a un mismo dispositivo Beacon. En el ANEXO I de este documento se encuentra una documentación más detallada y más técnica de nuestra API REST de servicios. En el desarrollo de nuestra API REST se ha utilizado el lenguaje de programación Java y el framework Jersey. Jersey es un framework open source para el desarrollo de servicios web RESTful en Java. Se trata de una implementación de JAX-RS (Java API for RESTful Web 52/117 Figura 47: Módulos del front-end Como en el diagrama de módulos de la Implementación back-end , las relaciones entre módulos se representan con una línea que los une. La RA se relaciona con la Recomendación debido a que la utilizad a la hora de recomendar a un grupo de amigos una película. Con Beacon y Usuarios debido a que cuando se buscan los beacons se guarda la información de los usuarios y los beacons que están conectados. Se relaciona con Valoración, Deseos y Películas gracias a que cuando se escanea el cartel de una película, muestra la información de la película y tráiler, y permite tanto darle una valoración, como añadirla a la lista de deseos del usuario. Las interfaces Android se relacionan con Usuarios debido que es necesario hacer el registro y el login para entrar en la aplicación. Con Deseos y Películas porque la interfaz de Me Gusta muestra las películas que un usuario ha añadido a la lista de deseos y la interfaz de Ficha de Película muestra toda la información de una película. Por último, se relaciona con GPS debido que se utiliza para mostrar la gente que está cerca de ti en la Interfaz de Gente Cercana. A continuación, se detalla cómo se ha implementado el front-end , incluyendo la explicación de los lenguajes utilizados, tecnologías, así como las diferentes herramientas utilizadas en su desarrollo. 4.3.1 Entorno de desarrollo Para todo el desarrollo de la parte cliente del proyecto se utilizó el lenguaje Java. Java es el lenguaje que hay que utilizar para programar en Android Studio, por lo que no hubo 53/117 mucha elección posible. Además, es un lenguaje que conocemos todos los integrantes del grupo y, por esta razón, aprender a programar aplicaciones móviles para Android ha sido más fácil. Sin embargo, para poder trabajar con Wikitude tuvimos que utilizar Javascript. Es un lenguaje fácil de aprender, que conocemos casi todos los integrantes y es muy sencillo de utilizar y trabajar con él. Toda la parte cliente se desarrolló en un mismo entorno de desarrollo. Aunque al principio estuvimos dudando entre Eclipse o Android Studio, finalmente nos decantamos por este último. Android Studio ofrecía más herramientas y una forma más sencilla de trabajar. Android Studio es un entorno de desarrollo integrado para la plataforma Android. Fue anunciado el 16 de mayo de 2013 en la conferencia Google I/O, y reemplazó a Eclipse como el IDE oficial para el desarrollo de aplicaciones para Android. Elegimos utilizar Android Studio por su integración con las APIs de Android y el fácil manejo que tiene para desplegar y testear las aplicaciones en los dispositivos móviles. Además de esto, Android Studio ofrece varias ventajas:  Renderización en tiempo real.  Consola de desarrollador: consejos de optimización, ayuda para la traducción, estadísticas de uso.  Soporte para construcción basada en Gradle.  Refactorización especifica de Android y arreglos rápidos.  Herramientas Lint para detectar problemas de rendimiento, usabilidad, compatibilidad de versiones, y otros problemas.  Plantillas para crear diseños comunes de Android y otros componentes. 4.3.2 Realidad Aumentada A la hora de desarrollar la 3.4.4 Interfaz de Realidad Aumentada teníamos varias herramientas posibles. Estuvimos bastante tiempo investigando cuál sería mejor para el proyecto y haciendo pruebas con Vuforia y Wikitude. Finalmente, decidimos usar la tecnología Wikitude en vez de Vuforia debido a su fácil integración con Android Studio, porque dispone de un lenguaje de programación sencillo (JavaScript) y porque Vuforia, al diseñarse en Unity, está más orientado a juegos que a aplicaciones, como la de este proyecto, y permite reconocer imágenes tanto en local como en la nube. Decidimos usar el reconocimiento en la nube de las imágenes debido a que la Target API de Wikitude es muy sencilla de utilizar, ya que se pueden añadir muchos carteles muy fácilmente, y la base de datos de la aplicación se actualiza de forma automática. Sin embargo, nos 54/117 encontramos con el problema de que, al estar el reconocimiento en la nube limitado a 1000 reconocimientos al mes (en la versión gratuita) y tener que hacer tantas pruebas para ver si funcionaba correctamente la aplicación, rápidamente se nos prohibía utilizar más reconocimientos porque habíamos superado el límite. Por ese motivo, decidimos realizar el reconocimiento de imágenes en local, ya que no tiene límite. Sin embargo, no se actualiza automáticamente la aplicación y es necesario descargar un archivo .wtc de la API de Wikitude con las imágenes que queremos reconocer y añadirlo a la aplicación cada vez que queremos cambiar los carteles de las películas que reconocemos. Otro inconveniente que encontramos fue la reproducción de video en la RA. Uno de los objetivos de la interfaz RA era mostrar el tráiler de la película que anunciaba el cartel. Sin embargo, leyendo la documentación de Wikitude, comprobamos que sólo se pueden crear 4 objetos de video debido al coste de carga de estos videos. Es por ello que nuestra interfaz de RA se vio limitada a reconocer únicamente cuatro carteles de película, siendo imposible así realizar el objetivo de guardar toda una cartelera. Otro problema con la reproducción de los tráileres está relacionado con la forma en la que se guardan los videos y los objetos de reconocimiento. La primera idea era un único objeto AR.Trackable2DObject que recibía el nombre del póster y llamaba a los servicios web para mostrar toda la información por pantalla. Sin embargo, al tener que crear un objeto de video (AR.VideoDrawable) para cada tráiler, fue necesario crear un objeto de reconocimiento para cada cartel, lo que provoca mucho código repetido y no ser tan fácilmente ampliable. Una posible solución a estos problemas es no mostrar el video en la RA y que, al pulsar el botón de video, se dirija la reproducción del tráiler a YouTube. 4.3.3 Tecnologías Por otro lado, parece importante explicar qué otras tecnologías se usaron para la creación de las interfaces de usuario. Al ser una aplicación con interfaces parecidas, que, además, el usuario puede ir de una a otra rápidamente, tuvimos que encontrar la manera de que las llamadas al servidor se hicieran de forma eficiente y sin que el usuario lo notara. Para ello, utilizamos la tecnología Fragment. Esta tecnología nació cuando empezaron a aparecer dispositivos de gran tamaño tipo tablet, el equipo de Android tuvo que solucionar el problema de la adaptación de la interfaz gráfica de las aplicaciones a ese nuevo tipo de pantallas. Una interfaz de usuario diseñada para un teléfono móvil no se adaptaba fácilmente a una pantalla varias pulgadas mayor. La solución a esto vino en forma de un nuevo tipo de componente llamado Fragment. 55/117 Un fragment no puede considerarse ni un control ni un contenedor , aunque se parecería más a lo segundo. Un fragment podría definirse como una porción de la interfaz de usuario que puede añadirse o eliminarse de la interfaz de forma independiente al resto de elementos de la actividad, y que por supuesto puede reutilizarse en otras actividades. Esto, aunque en principio puede parecer algo trivial, nos va a permitir poder dividir nuestra interfaz en varias porciones de forma que podamos diseñar diversas configuraciones de pantalla, dependiendo de su tamaño y orientación, sin tener que duplicar código en ningún momento, sino tan sólo utilizando o no los distintos fragmentos para cada una de las posibles configuraciones. Figura 48: Ejemplo de uso de los fragmentos de Android El uso de fragmentos nos ha ayudado bastante a la hora de gestionar las IU, teniendo una actividad principal y después varios fragmentos que se combinan para crear todo el conjunto de interfaces. Los hemos utilizado en las interfaces de Inicio, Me gusta y Ficha de Película. En nuestro caso lo que tenemos es un contenedor que tiene el menú desplegable y después los diversos fragments que aparecen o desaparecen en función de lo que el usuario haya pulsado en el menú. 4.3.3.1 Localización indoor con dispositivos Beacon La localización indoor con dispositivos Beacon se ha implementado con el SDK de Konkakt.io, que es una compañía que ofrece servicios de seguridad y configuración de dispositivos Beacon, tanto hardware, como software (36). 56/117 El uso de beacons en nuestra aplicación se deriva de la necesidad de localizar dispositivos móviles cercanos en indoor . Los beacons permiten al usuario ubicarse en sitios donde el GPS no es tan útil, por ejemplo, en un cine. La funcionalidad asociada a estos dispositivos Beacon está asociada a la interfaz de RA. Esta funcionalidad consiste en que cuando el usuario entra en esta interfaz se inicia el escaneo de beacons de forma instantánea y permanece constante hasta que el usuario sale de dicha interfaz. Si durante el escaneo se encuentra uno de estos dispositivos, se asocia dicho usuario a dicho beacon en el sistema. De esta forma, cuando se muestran los amigos cercanos a un usuario en la RA, se consultan los usuarios que están asociados al mismo dispositivo Beacon que el usuario en cuestión. En el desarrollo de esta funcionalidad, partimos de una demo realizada por José Luis Jorro Aragoneses. En ella se utiliza el SDK para Android de Konkakt.io. Este SDK proporciona componentes para construir aplicaciones utilizando beacons y cubre las siguientes áreas de funcionalidad:  El ranging/monitoring del dispositivo.  La conexión del dispositivo.  La comunicación con la API REST de Konkakt.io.  Las acciones del dispositivo. El manager utilizado para el escaneo de beacons ha sido ProximityManager. Este manager presenta ciertos inconvenientes con respecto a la otra alternativa (KonkaktProximityManager), pero decidimos no actualizarlo debido a que llevábamos cierto retraso en el desarrollo de la funcionalidad asociada a estos dispositivos Beacon. Sería una posible mejora de futuro. Por otro lado, el método utilizado para este escaneo ha sido ranging . Consiste en escanear dispositivos Beacon de forma instantánea y constante una vez iniciado el escaneo. En nuestra aplicación este escaneo se inicia al entrar en la interfaz de RA. La demo inicial de J. L. Jorro permitía escanear beacons en sus dos formatos: iBeacon y Eddystone. Esta demo no era del todo funcional, ya que no realizaba el escaneo correctamente. En el proceso de solución de este problema, limitamos esta característica, y nuestra aplicación actualmente sólo escanea dispositivos Beacon en formato Eddystone. Esta sería otra posible mejora de futuro. 57/117 4.3.3.2 Geolocalización con GPS Es una tecnología de geoposicionamiento utilizando la red de satélites de GPS, la cual, mediante cálculos trigonométricos da una posición con componentes de latitud y longitud, con una precisión de unos pocos metros. Este apartado en un principio no fue primordial, sino que fue una salvaguarda por si no se podía lograr un correcto funcionamiento en el uso del servicio Beacon de Kontakt.io, pero al final, introdujimos esta funcionalidad para cuando estuviéramos fuera del alcance de algún Beacon. Así distinguimos outdoor (cuando estemos fuera del alcance de un Beacon) e indoor (cuando estemos dentro del alcance de un Beacon). Implementamos un servicio en segundo plano que nos proporciona nuestras coordenadas geoespaciales mediante el uso de datos móviles, WiFi o sistema GPS. Dicho servicio dependerá de la precisión de nuestra posición, siendo mayor o menor dependiendo de nuestro tipo de conexión. Este servicio es utilizado en la interfaz gente cercana para proporcionarnos una lista de usuarios cercanos a nosotros, mostrándonos las películas que les gustan a cada uno de ellos. 4.3.4 Herramientas A la hora de desplegar la aplicación para poder probarla, algunos integrantes del grupo tuvimos problemas, ya que no disponíamos de móvil Android. Por esta razón, tuvimos que investigar y utilizar una herramienta que nos permitiese desplegar la aplicación en el ordenador. Aunque Android Studio tiene esta posibilidad, el rendimiento es bastante malo y decidimos utilizar Genymotion. Se trata un emulador móvil mucho más eficiente que el que por defecto ofrece Android Studio. Utiliza VirtualBox para crear los diferentes dispositivos móviles (emulados). Además, Android Studio reconoce el móvil de GenyMotion cuando éste está corriendo. Nos ha sido muy útil a la hora de debugear y testear, ya que utilizando esta herramienta no ha sido necesario reiniciar el ADB cada vez que ejecutábamos la aplicación desde Android Studio. 58/117 4.4 Pruebas de arquitectura En este apartado se explican las diferentes pruebas llevadas a cabo como toma contacto con las tecnologías y/o funcionalidades del proyecto que eran totalmente nuevas para nosotros. Estas pruebas se agrupan en cinco grupos: de RA, de servicios web, con Hibernate/JPA, de los servicios de redes sociales y de geolocalización. 4.4.1 Pruebas de realidad aumentada El objetivo de realizar pruebas con varias tecnologías de RA es conocer cómo funcionan y qué nos ofrecen, para saber con cuál nos puede resultar más fácil implementar la RA de nuestra aplicación o cuál se ajusta más a nuestras necesidades. Pruebas en Unity con Vuforia  Pruebas de reconocimiento de texto Una de las ideas al principio del desarrollo del proyecto era que, en vez de reconocer la imagen de un cartel, la aplicación pudiera reconocer el nombre de la película a través del texto. Para ello, realizamos una prueba con el reconocedor de texto de Vuforia. Esta funcionalidad de Vuforia se encuentra, una vez instalado el paquete de Vuforia en Unity, en una escena en la carpeta assets > Scenes > Vuforia-TextReco . Para poder ejecutarla en el ordenador, es necesario que éste tenga cámara o que se ejecute en un teléfono utilizando la aplicación de Unity para dispositivos móviles. En las pruebas se muestra una pequeña franja en la que añadir texto, y las palabras en inglés con fuente normal se reconocen fácilmente, especialmente en fondo claro. Sin embargo, al probar con carteles como los de Star Wars y Planet 51 , que tienen unas fuentes muy diferentes, la aplicación es incapaz de reconocer los nombres. Tras estas pruebas, descartamos la idea del reconocimiento de texto para los carteles, ya que las fuentes son un problema, debido a que muchas son irreconocibles para los reconocedores de texto. 59/117  Prueba de reconocimiento en local de una imagen La prueba de reconocimiento en local la realizamos siguiendo un tutorial del blog Emiliusvgs (37). El tutorial está suficientemente completo y no tuvimos mayores problemas para implementar esta prueba. Figura 49: Prueba de reconocimiento local con Vuforia  Prueba de reconocimiento en la nube de imágenes Comenzamos siguiendo un artículo de la página de Vuforia en el que se explica cómo crear una app sencilla de reconocimiento en la nube con Unity (38). Siguiendo este tutorial nos encontramos con las siguientes dificultades:  La utilización de Vuforia en Unity tiene una restricción. Si nuestro sistema operativo es Windows, el editor para Unity que instalemos debe ser necesariamente de 32 bits. Sin embargo, si se trata de un MAC OS, debe ser necesariamente de 64 bits.  Además de importar el paquete de Vuforia para Unity (vuforia-unity-5-0-6), como se indica, también hay que importar el de Cloud Recognition (CloudReco-5-0-5) debido a que en el código se implementa la interfaz de ICloudRecoEventHandler. Esto último no se especifica en el tutorial.  En la versión del SDK 4.0, la clase ImageTracker ha sido reemplazada por ObjectTracker. En el código de ejemplo del tutorial es necesario reemplazar una por otra si se usa la versión 5 del SDK de Vuforia.  Para ejecutar una aplicación en Vuforia es necesario solicitar una clave de licencia, la cual se puede conseguir de forma gratuita en el portal para desarrolladores de la página web de Vuforia (39). 60/117 Vuforia permite la creación de una base de datos en la nube donde se pueden guardar las imágenes que se quieren reconocer, y pone a disposición del usuario claves de acceso para añadirla a la app en Unity. La licencia gratuita permite guardar 1000 imágenes en la base de datos y el mismo número de reconocimientos al mes. Al añadir una imagen a la base de datos es posible añadir un archivo de metadatos asociado a la imagen. Para la prueba creamos un archivo de metadatos para cada película únicamente con el nombre de ésta. Al tener algunos miembros experiencia a la hora de trabajar con Unity, la prueba fue más sencilla de realizar que si nadie hubiera trabajado antes en Unity. El proceso que se realizó fue el siguiente:  Utilizando la escena básica de Vuforia Cloud Reco , creamos un objeto que aparecerá encima de la imagen reconocida.  A este objeto le añadimos un script llamado NameManager , que recoge el metadata de la imagen y actualiza el objeto anterior con el nombre obtenido en el archivo. Figura 50: Prueba de reconocimiento en la nube con Vuforia 61/117 Pruebas en Android con Wikitude  Prueba de reconocimiento en local de una imagen Nuestra primera toma de contacto con el SDK de Wikitude fue mediante varios artículos del blog Desarrollo Libre (40). Estos ejemplos son en local, están implementados con la versión 3 del SDK de Wikitude para Android y utilizan la API de JavaScript. Para ello utilizamos el entorno de desarrollo Eclipse con el plugin ADT. Las principales dificultades que nos encontramos tuvieron que ver con nuestra falta de conocimientos en el desarrollo de Android. Algunas de esas dificultades fueron:  Al importar el código de ejemplo nos aparecía el error “Unable to resolve target 'android-XX'”. Esto ocurría porque la versión de la API del proyecto en Eclipse no se correspondía con la versión que aparecía en los archivos de configuración.  El código de ejemplo no incluía en el archivo de configuración AndroidManifest.xml los permisos y características de uso que requería la aplicación para funcionar. De esta forma, cuando intentábamos probar la demo en nuestro móvil, ni siquiera se abría y aparecía un mensaje indicando que se había detenido. Figura 51: Prueba de reconocimiento en local con Wikitude 68/117 Al final se descartó la funcionalidad de compartir en Facebook, ya que no nos permitía personalizar la publicación, siendo sólo posible compartir enlaces que no hacen referencia alguna a nuestra aplicación. 4.4.5 Pruebas de geolocalización GPS Con esta prueba desarrollamos una forma alternativa de representar a la gente cercana, a la usada en los Beacons, debido a la existencia de algunos problemas presentados durante su desarrollo. Las pruebas de la geolocalización constan de dos partes. En primer lugar, conseguir los puntos de latitud y longitud, mediante el uso de llamadas a los servicios GPS, construyendo un servicio completo en nuestra aplicación. Durante su realización se presentaron problemas de permisos debido a que la nueva API de Android (SDK 23 de Android), presenta un cambio en los permisos, donde antes los usuarios se despreocupaban de otorgar algunos permisos llamados de riesgo, como el uso de tu localización o información personal. Ahora son los usuarios los que tienen que dar permiso para el uso de algunos recursos de las aplicaciones, delegando de esta forma al programador la llamada explícita para la aceptación del permiso. En segundo lugar, se realizaron pruebas de cálculo de distancias. Primeramente, dejamos el cálculo a la aplicación mediante una función, ofreciendo una distancia de error desde el primer punto calculado a los siguientes puntos que se calculan. Seguidamente nos dimos cuenta que podíamos hacer este cálculo directamente en el servidor, mediante MongoDB, que ofrece una función específica que calcula la distancia. 69/117 Figura 60: Prueba de geolocalización 70/117 Capítulo 5: EVALUACIÓN DE USUARIOS Con una versión de la aplicación funcional y prácticamente estable, comenzamos a realizar las evaluaciones con usuarios para estudiar la usabilidad de nuestra aplicación y comprobar si hay posibles problemas a la hora de ser manejada por gente ajena al proyecto. Exponemos el plan de evaluación, donde detallamos los objetivos de la evaluación, las tareas que los usuarios deben realizar durante la evaluación, las preguntas que deben responder y cuál será nuestro trabajo en cada evaluación. También mostramos las opiniones de los usuarios a nuestra aplicación una vez realizada la evaluación, contando cuántas personas la hicieron, los errores que encontramos, opiniones y críticas hacia la aplicación y conclusiones que tomamos. 5.1 Plan de evaluación Este plan de evaluación se basa en el que realizaron en el TFG de RACMA, una aplicación de RA para museos (50) 5.1.1 ¿Qué estamos evaluando? Proyecto: MUVI APP Premisa: Un grupo de amigos va al cine, pero no se ponen de acuerdo en qué película ir a ver, y necesitan información de la película y qué película se les recomienda. Además, un usuario ve un cartel de una película y quiere ver todo lo relacionado con ella. Objetivo de la aplicación: Ayudar a grupos de gente que van al cine a decidir qué película ver, mostrando mediante una interfaz de RA y apuntando a un cartel, información de dicha película, tal como tráiler, sinopsis y puntuación media en medios internacionales de opinión, y valoración que su grupo de amigos daría. Además, se permite añadir la película a una lista de deseos para poderla ver en otro momento. 5.1.2 Propósito de la evaluación Una vez terminada la etapa de desarrollo, se desea comprobar el impacto del uso de la RA en el usuario, así como la usabilidad de la aplicación. 71/117 5.1.3 Objetivos generales Deseamos evaluar las principales características de la aplicación:  Recabar la opinión del usuario sobre el uso de la aplicación, especialmente sobre la interfaz de RA.  Comprobar la facilidad de uso de la aplicación: si la interfaz es sencilla, cómoda e intuitiva. 5.1.4 Preguntas de investigación  ¿Se puede usar MUVI de manera correcta?  ¿Es confusa la interfaz?  ¿Los botones son claros y están bien colocados?  ¿El usuario encuentra de manera fácil lo que busca?  ¿La aplicación muestra la información necesaria al usuario?  ¿Hay alguna función de la aplicación que se echa en falta? 5.1.5 Requisitos de los participantes Las personas a las que entrevistaremos para las evaluaciones serán familiares, amigos y/o conocidos, preferiblemente con rangos de edades diferentes y con niveles de estudios diferentes. 5.1.6 Diseño experimental  La evaluación se realizará entre los días 20 y 22 de mayo de 2016  Se realizarán de 5 a 10 evaluaciones, teniendo cuidado de evaluar a gente con rangos de edades y niveles diferentes.  Duración aproximada de cada evaluación individual: 20 minutos.  Duración total de la evaluación: aproximadamente 40 minutos por cada miembro del grupo, haciendo un total de unas 5 horas para todos los usuarios. El plan a realizar con el usuario es: 1. Realizar un cuestionario para saber datos demográficos del usuario y el conocimiento del usuario sobre RA en un primer momento. 2. Introducir al usuario sobre qué es la RA. También explicarle en qué consiste nuestra aplicación, sin entrar demasiado en detalles. 3. Proporcionarle una lista de tareas al usuario y pedirle que las realice. Debe realizar las tareas sin nuestra ayuda, a no ser que se quede atascado sin saber cómo seguir. 72/117 Mientras tanto, iremos tomando nota de cómo el usuario realiza cada una de las tareas. El usuario, a su vez, deberá ir expresando en voz alta sus impresiones. 4. Pequeño diálogo con el usuario, preguntándole qué es lo que más le ha gustado y si tiene alguna queja en concreto. 5. Realización de un cuestionario sobre la facilidad de uso de nuestra aplicación. 6. Recopilación de datos: a. A partir de la encuesta, obtendremos datos cuantitativos sobre la experiencia del usuario. b. Con la información tomada durante la observación, obtendremos datos cualitativos que nos permitirán detectar cuáles son los errores más comunes que han cometido los usuarios para su posterior análisis. 5.1.7 Tareas a realizar Esta lista de tareas está relacionada con nuestra aplicación. 1. Regístrate en la aplicación. 2. Inicia sesión en la aplicación. 3. Entra en la interfaz de RA. 4. Reconoce una de las películas. 5. Muestra la información sobre la película. 6. Reproduce el tráiler de la película. 7. Pausa el tráiler de la película. 8. Deje de mostrar el tráiler de la película. 9. Añade la película a “Me Gusta”. 10. Realiza una valoración de la película. 11. Vuelve a la pantalla de inicio. 12. Muestra la lista de películas que te gustan. 13. Muestra la información de una de las películas favoritas. 14. Vuelve a la lista de favoritos. 15. Vuelve a la pantalla de inicio. 16. Muestra la gente cercana. 17. Vuelve a la pantalla de inicio. 5.1.8 Entorno y herramientas empleadas No es obligatorio ningún entorno específico para la realización de las pruebas, únicamente valdrá con que sea un espacio cómodo donde poder realizarlas sin problemas ni interrupciones. 73/117 Las herramientas que utilizaremos serán un teléfono móvil y fotocopias o imágenes de los carteles de película que reconoce la aplicación. No haremos uso del dispositivo Beacon ni de la recomendación a grupos debido a que su funcionalidad está diseñada para grupos y nuestras pruebas se realizarán individualmente. 5.1.9 Obtención de feedback de los participantes Las fuentes de datos serán las siguientes: 1. Cuestionario inicial para conocer el contexto del usuario antes de realizar la evaluación. 2. Reunión posterior a la evaluación con el participante. 3. Cuestionario SUS traducida por Marta Caro y David Hernández (50), que medirá el grado de usabilidad. Las preguntas se responden a través de una valoración del 1 al 5, en la que 1 es totalmente en desacuerdo y 5 totalmente de acuerdo. 5.1.10 Tareas del moderador Las tareas que deberá realizar el moderador a la hora de la evaluación serán:  La primera tarea del moderador será explicar al usuario en qué consisten tanto la aplicación como la RA.  Pedirá al usuario que realice las tareas anteriormente expuestas, y anotará y observará todo aquello que considere relevante para el estudio. Importante detectar los problemas que el usuario encuentre. A lo largo de estas tareas, el moderador no ayudará al usuario a menos que sea totalmente necesario.  Pedirá al usuario que comente en todo momento sus impresiones de la aplicación y de la tarea asignada.  Para terminar, proporcionará al usuario las encuestas para la recolección de datos para que las realice. 5.1.11 Descripción de la metodología de análisis de datos 1. Los cuestionarios a los usuarios se realizarán mediante la herramienta Google Forms, ya que se realizarán en espacios conectados a Internet. 2. Los moderadores anotarán en papel todos los apuntes que crean convenientes en un documento impreso con el nombre de cada tarea y un espacio en el que añadir texto. A la hora de agrupar todos los formularios, se escanearán (o en caso de ser imposible el escaneado, se realizará una foto) y se guardarán en la carpeta de Google Drive preparada para la tarea. 74/117 3. Con las notas y los valores recogidos en los cuestionarios, se comprobará cuáles son las tareas que más tiempo tardan en realizarse y se estudiará si la implementación es la correcta. 4. Se pondrán en común todas las conclusiones y se realizará un informe con todo los errores y posibles mejoras que puedan realizarse. 5.2 Evaluación Durante la evaluación comprendida entre los días 21 y 22 de mayo, efectuamos 7 evaluaciones de 20-30 minutos cada una. El rango de edades de los usuarios fue el siguiente:  Entre 18 y 29 años: 4  Entre 30 y 45 años: 1  Mayores de 46 años: 2 Además, hemos intentado que tengan una profesión o estudios diferentes para poder tener un mayor rango de opiniones. Los usuarios eran: estudiante de Bachillerato, estudiante de Geología, estudiante de Relaciones Laborales, electromecánico, Ingeniero Informático, Ingeniero de Telecomunicaciones y pensionista. 5.2.1 Observaciones y opiniones de los usuarios Empezamos la evaluación preguntando al usuario cuál es su experiencia sobre la RA. Los resultados fueron los siguientes:  6 de los 7 evaluados no poseían experiencia previa en aplicaciones de RA.  Sólo un evaluado tenía experiencia previa en RA, en videojuegos y en museos. En la realización de tareas, los principales problemas que encontraron los usuarios por cada tarea fueron los siguientes:  Regístrate en la aplicación: algunos usuarios no encontraron el botón de registro, ya que el teclado sale automáticamente y tapa el botón. Otro usuario detectó falta de consistencia de los idiomas entre “Registrarse” y “Login”.  Entra en la interfaz de RA: un usuario se extrañó de la petición de encender el bluetooth . Se le explicó que el motivo era la búsqueda de los usuarios cercanos. Otro usuario dudó como entrar.  Reconoce una de las películas: todos los usuarios intuitivamente apuntaron a la película, pero algunos se quejaron de que se reinicia el servicio al girar la pantalla. 75/117  Muestra la información sobre la película: no tuvieron problema en encontrar el botón. Sin embargo, algunos usuarios pidieron que se mostrara sobre que puntuación es la valoración máxima y a otros no les gustó que si mueves el móvil se va la captura.  Reproduce el tráiler de la película: la mayoría no tuvo problemas a la hora de encontrar el botón. Algunos usuarios pidieron poder cambiar el tamaño o se quejaron de la incomodidad de tener el brazo levantado para poder ver el video. Sin embargo, también les gustó el hecho de que el vídeo cargara tan rápido y que se muestre en la RA.  Pausa el tráiler de la película: un usuario necesitó ayuda del moderador para pausar el video.  Deje de mostrar el tráiler de la película: algunos usuarios intentaron arrastrar el video para que dejara de mostrarse y otro buscó una X cerca del video.  Añade la película a tus favoritos: un usuario pidió que se mostrase un mensaje de notificación.  Realiza una valoración de la película: a todos los usuarios les cuesta encontrar el botón o deducen que es ese por descarte. También se quejan de no poder rectificar una valoración. Otro usuario ve la aplicación como una herramienta para elegir que ver, no cree que nadie vaya a buscar el póster para puntuarla una vez vista la película.  Muestra la lista de películas que le gustan: todos los usuarios han encontrado problemas a la hora encontrar el menú principal. Piden cambiar el icono del menú porque la flecha parece que saca de la aplicación.  Vuelve a la lista de favoritos: vuelven con el botón de Android, no de la aplicación. Con los resultados de las pruebas, sacamos una lista de problemas y soluciones ordenados por orden de prioridad y cómo lo resolveríamos en un trabajo futuro: 1. Mejorar el rendimiento de la aplicación para que no se reinicie el servicio de RA al girar el dispositivo. 2. Cambiar los iconos de algunos botones, como el de Valoración de la RA o el del Menú de Inicio debido a la confusión que causaron a todos los usuarios. 3. Cambiar el inicio de la aplicación para que no salga automáticamente el teclado y no esconda el botón de Registrarse. 4. Permitir cambiar la valoración individual debido a que actualmente no es posible cambiarla. 5. Añadir otra forma de quitar el video de la RA para que sea más intuitivo, como una X o arrastrar el video. 6. Cambiar la puntuación de los medios para que pueda verse sobre qué nota está puntuada la película. 76/117 5.2.2 Resultado cuestionario SUS Al final de la realización de las tareas, se pidió a los usuarios que realizaran el test de usabilidad SUS de la aplicación con el fin de obtener la puntuación SUS y comprobar el nivel de facilidad de uso de nuestra aplicación. Para obtener la puntuación SUS se siguen los siguientes pasos: 1. Para las preguntas impares se resta uno al valor respondido. 2. Para las pares se resta al valor 5 el valor respondido. 3. Sumamos todos los valores obtenidos tras realizar los pasos 1 y 2. 4. Multiplicamos por 2,5 y obtendremos la puntuación SUS. Durante la evaluación se ha obtenido una valoración media de 80,7, una valoración por encima de los 68, resultado considerado satisfactorio, por lo que se puede afirmar que nuestra aplicación ha obtenido una buena puntuación en esta encuesta. Además, la encuesta SUS organiza las puntuaciones utilizando una escala de valores, en la que una F es un suspenso de la aplicación y una A es la puntuación máxima a obtener. Para conseguir una A es necesario superar un 80 de puntuación, y la nuestra es de 80,7, por lo que se puede concluir que la usabilidad de MUVI es sobresaliente. Figura 61: Resultados posibles de SUS Conclusiones y sugerencias Una de las quejas más habituales fue la postura a la hora de realizar la prueba en la RA, y una propuesta que nos dieron fue que no fuera obligatorio estar constantemente apuntando a la película, lo que llevaría a un cambio muy grande en la estructura de la RA. Otro aspecto muy importante del que los usuarios se quejaron fue del botón de valoraciones en la RA, que no queda nada claro y es difícil de encontrar, por lo que habría que cambiar ese icono por otro más intuitivo. 77/117 Tampoco gustó el icono del menú principal, ya que mucha gente no sabía qué hacía ese icono o pensaba que sacaba de la aplicación, por lo que sería conveniente cambiarlo también. Entre las funcionalidades que añadirían ellos a la aplicación, nos dijeron que la RA podría llevar a la compra de entradas en alguna web y qué considerarían de mucha ayuda que mostrara opiniones de los usuarios de la película, no sólo la valoración media de webs importantes. Sin embargo, hemos comprobado en las encuestas que, a pesar de los pequeños fallos que encontraron en la aplicación, todos los usuarios han expresado su aprobación a la aplicación y algunos han quedado impresionados con ella. A todos les ha gustado e incluso han afirmado que estarían dispuestos a pagar por ella en el caso de que saliera a la venta. Han opinado que es una aplicación realmente útil a la hora de ir al cine y que la recomendarían. 84/117 13. Añadir otra forma de quitar el video de la RA para que sea más intuitivo, como una X o arrastrar el video. 14. Cambiar la puntuación de los medios para que pueda verse sobre qué nota está puntuada la película. 85/117 Capítulo 8: ORGANIZACIÓN DEL TRABAJO En la etapa de investigación y pruebas con tecnologías, no ha existido división del trabajo como tal. Cada uno de los miembros investigaba lo que consideraba conveniente sobre la tecnología objetivo en cada momento. En la etapa de desarrollo, nos hemos dividido en dos grupos. Uno se ha centrado en el desarrollo del front-end y lo han formado Ignacio Rocillo, Jorge Muñoz y Sergio Fuentes. El otro se ha centrado en el desarrollo del back-end y lo han formado Cristina Delgado y Jorge Rueda. En la etapa de realización de la memoria, nos hemos dividido el trabajo de tal forma que cada uno de nosotros se ha enfocado en escribir o documentar sobre aquello con lo que ha estado más en contacto. A continuación, se muestra la cronología del proyecto: 1910 0211 0211 1611 1611 3011 3011 1412 14-12 11-01 (Navidad) 1101 2501 1502 2902 2902 1603 16-03 06-04 (S. Santa) 0604 2004 2004 0405 0405 1805 1805 2305 2305 0606 ETAPA DE INVESTIGACIÓN Investigación tecnologías RA Definición casos de uso Prototipado de las IU Pruebas RA Investigación servicios REST Definición servicios API Pruebas tecnologías servicios Pruebas geolocalización GPS [1] Investigación recomendación [2] ETAPA DE DESARROLLO 86/117 Interfaz RA Servicios de usuarios Servicios de películas Servicios de deseos Servicios de redes sociales Interfaz de Registro Interfaz de Login Diseño y maquetación de logo Servicios de valoraciones Prototipo 1 Interfaz de Inicio Servicios de beacons Desarrollo beacons en cliente Servidor FDI [3] Prototipo 2 Interfaz de Inicio Interfaz de Ficha de Película Interfaz de Me Gusta Cambios en servicios Mejoras Interfaz RA Mejoras interfaces Android Interfaz de Gente Cercana Servicios de recomendación Demo estable [4] ETAPA DE MEMORIA Documentación servicios API [5] 87/117 Documentación pruebas [6] Estructura de la memoria Versión 1 de la Memoria Evaluación de usuarios Versión 2 de la Memoria Versión 3 de la Memoria La etapa de investigación corresponde con la primera etapa del proyecto. Sin embargo, ciertas tareas de investigación se han realizado durante etapas posteriores. En el caso de las pruebas de geolocalización GPS [1], no estaba previsto su uso en un principio, sino que surgió como una alternativa a la localización con dispositivos Beacons cuando tuvimos ciertos problemas con su desarrollo. En el caso de la investigación sobre sistemas de recomendación [2], en un primer momento íbamos a utilizar el proyecto jCOLIBRI para el desarrollo de nuestro sistema de recomendación, pero debido a la incompatibilidad de las versiones de Java entre este proyecto y nuestra API de servicios fue necesario buscar alternativas. La etapa de desarrollo corresponde con la segunda etapa del proyecto. Sin embargo, ciertas tareas de desarrollo se han alargado hasta el final del proyecto. En el caso del despliegue de la aplicación en el servidor proporcionado por la Facultad de Informática [3], este servidor forma parte de un proyecto piloto, del cual hemos sido un grupo experimental. Esto nos ha conllevado una serie de inconvenientes, que se describen en el capítulo “Servidor” dentro del apartado “Implementación” de este documento. Es por esta razón que esta tarea se ha alargado hasta el final del proyecto. La tarea de conseguir una demo estable [4] de nuestra aplicación está relacionada también con los problemas surgidos con este servidor. La etapa de memoria corresponde con la última etapa del proyecto. Sin embargo, ciertas tareas relacionadas con la memoria se han realizado con anterioridad. 88/117 En el caso de la documentación de los servicios de la API [5], esta documentación se ha realizado con anterioridad para utilizarla como referencia, tanto en el back-end , como en el frontend , durante el desarrollo. En el caso de la documentación de las pruebas [6], estas pruebas se han documentado a medida que se han ido haciendo o al poco tiempo para evitar el olvido del proceso de realización de las mismas. 8.1 Modelo de desarrollo Durante el desarrollo de la aplicación utilizamos el framework de desarrollo ágil de software Scrum. Se basa en realizar continuamente pequeñas entregas de productos tangibles. Cada iteración (sprint) finaliza con la entrega de una parte operativa del producto (incremento). La duración de cada sprint tiene una duración típica de dos a cuatro semanas. Siguiendo Scrum, al comenzar la etapa de desarrollo, creamos una lista de tareas priorizadas. Cada uno de nuestros sprints duraba dos semanas. Estos sprints comenzaban y terminaban con una reunión con los tutores del TFG. En cada una de esas reuniones se mostraban las nuevas funcionalidades, se definían las tareas a llevar a cabo en el siguiente sprint y se repartía el trabajo entre los miembros del grupo. Las tareas estaban individualizadas y cada uno de nosotros era responsable de sacar adelante su parte del trabajo. 8.2 Herramientas de comunicación  Gmail, para la comunicación con los tutores del TFG en momentos puntuales.  Google Drive, para compartir todo tipo de archivos necesarios para el desarrollo del proyecto (imágenes, documentación, enlaces, código…), tanto entre nosotros, como con los tutores del TFG.  Telegram, para comunicarnos de forma rápida entre nosotros. 8.3 Herramientas de control de versiones Como sistema de control de versiones utilizamos Git y nuestro proyecto lo alojamos en GitHub, que es una plataforma de desarrollo colaborativo que utiliza el sistema de control de versiones Git. De esta forma, conseguimos mantener versiones de código estables en un lugar seguro. Para el uso de Git existen varias alternativas, se puede utilizar desde la consola, la aplicación oficial de GitHub para escritorio u otras. En nuestro caso se han utilizado: 89/117  Aplicación GitHub de escritorio: La aplicación permite usar todas las funcionalidades de Git: commit , push , etc. Es muy cómoda, ya que permite ver en forma de líneas de tiempo todas las diferentes ramas que tiene cada repositorio, entre otras cosas.  SourceTree: Es otra aplicación de escritorio, muy parecida a la de GitHub, pero en este caso tiene un control de conflictos más potente. Además, no solo sirve para G itHub , también para Bitbucket y otros tipos de control de versiones como Mercurial . 8.4 Herramientas de gestión de tareas Al utilizar una metodología de desarrollo ágil como la de Scrum, hemos necesitado disponer de una gestión del tiempo y de las tareas bastante flexible, cómoda y eficaz. Para ello buscamos entre varias herramientas, pero al final nos decantamos por Trello. Trello es una herramienta de colaboración que organiza los proyectos en tableros. Es decir, que gracias a Trello, se puede saber cuáles son las tareas que se llevan a cabo, quién trabaja en una tarea determinada y cuál es el estado de un proceso. Es una herramienta muy fácil y visual. Permite llevar un control de todas las tareas del proyecto en forma de tarjetas. Cada tarjeta se organiza en diferentes secciones o tarjeteros . Por ejemplo, en nuestro caso, hemos utilizado los tarjeteros : “Por hacer”, “En proceso”, “Terminado”. Figura 62: Ejemplo de Trello 90/117 Capítulo 9: APORTACIONES AL PROYECTO 9.1 Cristina Delgado Rodríguez Mi aportación en la etapa de investigación ha consistido en:  Investigación sobre las distintas tecnologías de RA, con el fin de elegir aquella que más se adaptara a nuestras necesidades.  Colaboración en la aportación de ideas y posterior definición de la funcionalidad de la aplicación.  Desarrollo de aplicaciones básicas de prueba de la RA, tanto con Android + Wikitude, como con Unity + Vuforia. El uso de estas tecnologías fue totalmente nuevo. En ninguna de las asignaturas de la carrera había aprendido o utilizado con anterioridad ni Android Studio, ni Unity, y mucho menos algo relacionado con la RA, como es el caso de Vuforia o Wikitude. Tampoco algunos de los lenguajes utilizados (C# para Unity + Vuforia o tecnologías web para Wikitude). El único conocimiento relacionado que tenía en un principio era Java, que es el lenguaje utilizado para el desarrollo en Android. Las aplicaciones que he creado como toma de contacto con ambas tecnologías han sido: o Prueba de reconocimiento en local de una imagen, con Unity + Vuforia. o Prueba de reconocimiento en local de una imagen, con Android + Wikitude. o Prueba de reconocimiento en la nube de imágenes, con Android + Wikitude.  Investigación en profundidad sobre la creación de servicios de arquitectura REST.  Colaboración en la definición de los servicios de la API.  Realización de tutoriales para aprender a utilizar el servidor de aplicaciones, Tomcat, y la herramienta para la gestión y construcción de proyectos Java, Maven.  Desarrollo de aplicaciones básicas con las distintas tecnologías implicadas en el desarrollo de servicios (Jersey e Hibernate/JPA). El desarrollo de servicios web en mi caso no era nuevo, pero sí el desarrollo de servicios web en Java con Jersey. Por otro lado, sí conocía el estándar de desarrollo JPA, pero no con el framework Hibernate. Las aplicaciones de prueba que he creado como toma de contacto con estas tecnologías han sido: o Las pruebas de servicios web REST con Jersey o Las pruebas con Hibernate/JPA  Creación de la aplicación básica inicial, integrando las distintas tecnologías implicadas en el desarrollo de los servicios, para el posterior desarrollo de los mismos.  Investigación sobre el funcionamiento de los dispositivos Beacon y su implementación en Java con el SDK para Android de Konkakt.io 91/117  Investigación sobre el funcionamiento de los sistemas de recomendación y su implementación en Java. En la etapa de desarrollo:  Mi principal aportación ha sido en el back-end : o Desarrollo de la API REST de servicios, junto con Jorge Rueda. o Realización de los scripts en Python necesarios. o Realización del servicio de prueba de publicación en Twitter.  Mi aportación en el front-end ha consistido en: o Desarrollo de la funcionalidad asociada a los dispositivos Beacon. o Colaboración en la integración de la aplicación Android. Mi aportación en la etapa de memoria ha consistido en:  Creación de la estructura de la memoria.  Redacción del estado del arte de los sistemas de recomendación (apartado 2.3).  Realización y explicación del diagrama de arquitectura (en el apartado 4.1).  Redacción del apartado 4.1.1 Relación entre front-end y back-end .  Realización y explicación del diagrama de módulos del back-end (en el apartado 4.2).  Redacción del apartado 4.2.1 Arquitectura de servicios  Redacción del apartado 4.2.3 Sistema de recomendación.  Colaboración en la documentación del apartado 4.2 Implementación del back-end .  Realización del diagrama de módulos del front-end (en el apartado 4.3)  Documentación del desarrollo asociado a los dispositivos Beacon en el front-end .  Documentación de las pruebas de arquitectura realizadas durante etapas anteriores (en el apartado 4.5).  Colaboración en la planificación de la evaluación de usuarios (en el apartado 5.1).  Realización y explicación del diagrama cronológico del proyecto (en el capítulo 8).  Colaboración en la redacción del capítulo 8 Organización del trabajo.  Colaboración en la documentación de los servicios de la API del ANEXO I.  Búsqueda de información y referencias que apoyen los datos y tecnologías mencionados en este documento.  Lectura de todo el documento y revisión del formato y contenidos del mismo.  Numeración de los distintos capítulos y apartados del documento. Además, mi aportación en cuestiones generales ha consistido en:  Colaboración en la toma de decisiones. 92/117  Asistencia a todas las reuniones quincenales con los tutores, tomando notas sobre los diferentes aspectos tratados en cada una de ellas y participando activamente.  Comunicación con los tutores, mediante correo electrónico o tutorías presenciales, para la resolución de dudas o el intercambio de recursos necesarios para el desarrollo del proyecto. 93/117 9.2 Ignacio Rocillo Landa Mi aportación en la etapa de investigación ha consistido en:  Investigación sobre las distintas tecnologías de RA, con el fin de elegir aquella que más se adaptara a nuestras necesidades.  Colaboración en la aportación de ideas y posterior definición de la funcionalidad de la aplicación.  Desarrollo de aplicaciones de prueba utilizando la tecnología Unity + Vuforia. Ya había utilizado Unity y C# en la carrera con anterioridad y no me resultó difícil de manejar. Sin embargo, Vuforia era una tecnología totalmente nueva y tuve que aprender a utilizarla para realizar las pruebas. Las pruebas que realicé fueron: o Prueba de reconocimiento de texto con Vuforia. o Prueba de reconocimiento de imágenes en la nube con Vuforia.  Colaboración en la definición de los servicios de la API.  Realización de tutoriales para aprender a utilizar el servidor de aplicaciones, Tomcat, y la herramienta para la gestión y construcción de proyectos Java, Maven, aunque luego terminara realizando la parte de cliente ( front-end ).  Investigación sobre las distintas fuentes de información de películas que nuestra aplicación podría hacer uso.  Investigación de implementación del GPS en aplicaciones Android y de aplicaciones que utilizan esta tecnología.  Investigación en la resolución de algunas cuestiones con la tecnología de RA Wikitude, tales como realizar llamadas entre Java y JavaScript en un mismo proyecto, botones y videos, etc.  Estudio y comprensión de Wikitude mediante los samples que hay a disposición de los usuarios. En la etapa de desarrollo:  Diseño y desarrollo de la RA y de todas sus funcionalidades, las cuales son: o Mostrar video de la película. o Mostrar información de la película. o Valorar la película. o Añadir película a lista de deseos. o Compartir película en Twitter. o Mostrar amigos cercanos, valoración de amigos cercanos y puntuación media.  Colaboración en la integración de la funcionalidad de los beacons en el proyecto. 100/117 REFERENCIAS 1. Höllerer, Tobias H. [En línea] http://web.cs.wpi.edu/~gogo/courses/imgd5100_2012f/papers/Hollerer_AR_2004.pdf. 2. La Realidad Aumentada facilita la visita al yacimiento de la Villa Romana de l´Albir. [En línea] http://www.canalpatrimonio.com/la-realialidad-aumentada-facilita-la-visita-al-yacimiento-de-lavilla-romana-de-lalbir/. 3. Bichlmeier, Christoph. Medical Augmented Reality. [En línea] http://medicalaugmentedreality.com/2016/02/helping-autists-to-interact-with-their-socialenvironment/. 4. Dequidt, Jeremie. Youtube. [En línea] https://www.youtube.com/watch?v=i6UrvuPPATk. 5. Using an iPhone and augmented reality to teach medical students. [En línea] http://www.imedicalapps.com/2014/04/iphone-augmented-reality-medical-students/. 6. Google glass for war: The US military funded smart helmet that can beam information to soldiers on the battlefield. [En línea] http://www.dailymail.co.uk/sciencetech/article2640869/Google-glass-war-US-military-reveals-augmented-reality-soldiers.html. 7. ¡DESCUBRE EN TU MÓVIL LAS CULTURAS DE AMÉRICA! [En línea] http://www.mecd.gob.es/museodeamerica/espacio-interactivo/Tanto-que-disfrutar-jugando--- /RACMA.html. 8. Sony. Playstation. [En línea] https://www.playstation.com/es-es/games/invizimals-psp/. 9. OpenCV. [En línea] http://opencv.org/. 10. Vuforia. [En línea] https://developer.vuforia.com/. 11. Metaio. [En línea] https://www.metaio.com/. 12. Mixare. [En línea] http://www.mixare.org/. 13. ARToolKit. [En línea] https://www.hitl.washington.edu/artoolkit/. 14. Wikitude. [En línea] http://www.wikitude.com/. 15. Metacritic. [En línea] http://www.metacritic.com/. 16. IMDb. [En línea] http://www.imdb.com/. 17. OMDb. [En línea] http://www.omdbapi.com/. 18. Tomatoes, Rotten. [En línea] http://www.rottentomatoes.com/. 101/117 19. Rotten Tomatoes API. [En línea] http://developer.rottentomatoes.com/. 20. TheMovieDb.org. [En línea] https://www.themoviedb.org/?language=es. 21. TheMovieDb.org API. [En línea] https://www.themoviedb.org/documentation/api. 22. ¿Qué son los sistemas de recomendación? [En línea] http://jarroba.com/que-son-lossistemas-de-recomendacion/. 23. LibRec. [En línea] http://www.librec.net/. 24. LensKit. [En línea] http://lenskit.org/. 25. Mahout. [En línea] http://mahout.apache.org/. 26. ounae. http://ounae.com/aplicaciones-usos-beacons-bluetooth-emisores/. [En línea] 27. Estimote Beacon. http://estimote.com/. [En línea] 28. RadBeacon. http://www.radiusnetworks.com/. [En línea] 29. Bluecat Beacon. http://bluecats.com/. [En línea] 30. Kontakt.io. https://kontakt.io/. [En línea] 31. Richardson Maturity Model. [En línea] http://martinfowler.com/articles/richardsonMaturityModel.html. 32. Hat Hexacta - Introducción a REST. [En línea] http://hat.hexacta.com/introduccion-a-rest-22/. 33. Asier Marques - Conceptos sobre APIs REST. [En línea] http://asiermarques.com/2013/conceptos-sobre-apis-rest/. 34. Creating a User-Based Recommender in 5 minutes. [En línea] https://mahout.apache.org/users/recommender/userbased-5-minutes.html. 35. MovieTweetings. [En línea] https://github.com/sidooms/MovieTweetings. 36. Konkakt.io - Android SDK Quickstart. [En línea] http://developer.kontakt.io/androidsdk/2.1.0/quickstart/. 37. Realidad aumentada con Unity 5. [En línea] http://emiliusvgs.com/realidad-aumentada-conunity-5/. 38. How to Create a Simple Cloud Recognition App in Unity. [En línea] https://developer.vuforia.com/library/articles/Solution/How-To-Create-a-Simple-CloudRecognition-App-in-Unity. 102/117 39. Portal para desarrolladores de Vuforia. [En línea] https://developer.vuforia.com/. 40. Creando aplicaciones de Realidad Aumentada con Reconocimiento de Imágenes. [En línea] http://www.desarrollolibre.net/blog/agrupados/creando-aplicaciones-de-realidad-aumentadacon-reconocimiento-de-imagenes/46. 41. Configurar el entorno de trabajo JEE con Eclipse Kepler y Tomcat 7. [En línea] https://www.youtube.com/watch?v=4NcOjx40_do. 42. Tutorial de introducción a Maven 3. [En línea] http://static1.1.sqspcdn.com/static/f/923743/15025126/1320942755733/Tutorial_de_Maven_3_ Erick_Camacho.pdf?token=bxGhbCQGvIElTO%2Fw6pK9Bz00iGY%3D. 43. Jersey hello world example. [En línea] http://www.mkyong.com/webservices/jax-rs/jerseyhello-world-example/. 44. Hibernate - Parte 2: Persistiendo Objetos Simples usando Anotaciones (metadatos). [En línea] http://www.javatutoriales.com/2009/05/hibernate-parte-2-persistiendo-objetos.html. 45. Get started quickly with Hibernate Annotations and JPA2. [En línea] http://www.ocpsoft.org/java/getting-started-quickly-with-hibernate-annotations/. 46. Twitter4J Code Examples. [En línea] http://twitter4j.org/en/code-examples.html. 47. Un poco de Twitter4J (Twitter + Java). [En línea] https://unpocodejava.wordpress.com/2014/10/06/un-poco-de-twitter4j-twitter-java/. 48. Tweet Button. [En línea] https://dev.twitter.com/web/tweet-button. 49. Gracia, Luis Miguel. unpocodejava.wordpress.com. Un poco de Facebook4J (Facebook + Java). [En línea] 7 de Octubre de 2014. https://unpocodejava.wordpress.com/2014/10/07/unpoco-de-facebook4j-facebook-java/. 50. RACMA: Aplicación de Realidad Aumentada para el Museo de América. [En línea] http://eprints.ucm.es/32915/1/Realidad%20aumentada%20para%20el%20Museo%20de%20A m%C3%A9rica.pdf. 51. Xloudia. [En línea] http://www.xloudia.com/. 52. TheMovieDb.org. API TheMovieDb.org. [En línea] https://www.themoviedb.org/documentation/api. 103/117 ANEXOS ANEXO I: API REST Esquema: Todo acceso a la API es a través de HTTP, y se hace desde el dominio container.fdi.ucm.es:20041/MuviAppREST. Todos los datos se envían y se reciben como JSON. Las URIs de nuestra API, por tanto, tienen la siguiente estructura: http://container.fdi.ucm.es:20041/ruta_del_recurso>?<consulta_de_filtrado> 1. Usuarios Login usuario Comprueba los datos de acceso de un usuario. POST /usuarios/{alias_usuario} Parámetros: Nombre Tipo Descripción password string La constraseña del usuario que desea acceder a la aplicación. Ejemplo: { "password": "p4ssw0rd" } Respuesta: Status: 200 OK { "id": 1, "alias": "carmengon", "password": "p4ssw0rd", "nombre": "carmen gonzalez", "email": "[email protected]" } Si el usuario introducido no corresponde con ninguna cuenta: Status: 422 Unprocessable Entity 104/117 Registro usuario Registra una nueva cuenta de usuario. POST /usuarios Parámetros: Nombre Tipo Descripción alias string El nombre del usuario de la nueva cuenta. password string La contraseña de la nueva cuenta. nombre string El nombre de pila asociado a la nueva cuenta. email string El correo electrónico asociado a la nueva cuenta. Ejemplo: { "alias": "carmengon", "password": "p4ssw0rd", "nombre": "carmen gonzalez", "email": "[email protected]" } Respuesta: Status: 201 Created { "id": 1, "alias": "carmengon", "password": "p4ssw0rd", "nombre": "carmen gonzalez", "email": "[email protected]" } Si ya hay un usuario registrado con el mismo alias: Respuesta: Status: 409 Conflict { "mensaje": "nombre de usuario no disponible" } Si ya hay un usuario registrado con el mismo correo electrónico: Respuesta: Status: 409 Conflict 105/117 { "mensaje": "correo electrónico no disponible" } Buscar usuario Busca un usuario por su nombre. GET /usuarios?usuario=name Respuesta: Status: 200 OK { "id": 1, "alias": "carmengon", "password": "p4ssw0rd", "nombre": "carmen gonzalez", "email": "[email protected]" } Si el usuario introducido no corresponde con ninguna cuenta: Status: 401 Unauthorized 2. Películas Buscar información de película Busca la información de una película por su título. GET /peliculas?titulo={titulo} Respuesta: Status: 200 OK { "id_IMDB": 3077214, "id_TheMovieDB": 245168, "titulo": "Suffragette", "sinopsis": "Based on true events about the foot soldiers of the early feminist movement who were forced underground to evade the State.", "generos": [ "Drama", "History" ], "votacion": 6.9, "trailer": "https://www.youtube.com/watch?v=gYXfARbezcA" } 106/117 Nota: Si no se encuentra el tráiler de esa película, el campo tráiler será null. Si no tiene id_IMDB, será 0. Si no se encuentra ninguna película que coincida con ese título: 107/117 Respuesta: Status: 422 Unprocessable Entity { "mensaje": "película no encontrada" } Listar películas Lista las películas que coincidan con un título. El resultado está limitado a 5 películas. GET /peliculas/list?titulo={titulo} Respuesta: Status: 200 OK { "id_IMDB": 3077214, "id_TheMovieDB": 245168, "titulo": "Suffragette", "sinopsis": "Based on true events about the foot soldiers of the early feminist movement who were forced underground to evade the State.", "generos": [ "Drama", "History" ], "votacion": 6.9, "trailer": "https://www.youtube.com/watch?v=gYXfARbezcA" } Nota: Si no se encuentra el tráiler de esa película, el campo tráiler será null. Si no tiene id_IMDB, será 0. Si no se encuentra ninguna película que coincida con ese título: Respuesta: Status: 422 Unprocessable Entity { "mensaje": "película no encontrada" } 108/117 3. Valoraciones Añadir valoración Añade una valoración de una película realizada por un usuario. POST /valoraciones Parámetros: Nombre Tipo Descripción id_usuario long El identificador del usuario que realiza la valoración. id_pelicula long El identificador de la película valorada. valoración int La valoración realizada de la película Ejemplo: { "id_usuario": 1, "id_pelicula": 1, "valoracion": 7 } Respuesta: Status: 201 Created { "id_usuario": 1, "id_pelicula": 1, "valoracion": 7 } Si ese usuario ya ha valorado esa película: Respuesta: Status: 422 Unprocessable Entity { "mensaje": "ese usuario ya ha valorado esa película" } Mostrar valoración Muestra la valoración de una película realizada por un usuario. GET /valoraciones?usuario={id_usuario}&pelicula={id_pelicula} 109/117 Respuesta: Status: 200 OK { "id_usuario": 1, "id_pelicula": 1, "valoracion": 7 } Si ese usuario no ha valorado esa película: Respuesta: Status: 422 Unprocessable Entity { "mensaje": "ese usuario no ha valorado esa película" } 4. Deseos Añadir deseo Añade una película a la lista de deseos de un usuario. POST /deseos Parámetros: Nombre Tipo Descripción id_usuario long El identificador del usuario que añade el deseo. id_pelicula long El identificador de la película que se añade como deseo. Ejemplo: { "id_usuario": 1, "id_pelicula": 20 } Respuesta: Status: 201 Created { "id_usuario": 1, "id_pelicula": 20 } Si ese deseo ya existe: