Desarrollo de una aplicación para la gestión de espacios en la Biblioteca de la Facultad de Informática

Grado en Ingenier´ıa Inform´atica Trabajo Fin de Grado Desarrollo de una aplicaci´on para la gesti´on de espacios en la Biblioteca de la Facultad de Inform´atica Realizado por: Carlos Gavidia Ortiz David Gorricho San Juan Iv´an Monterrubio Cerezo Director: Antonio Sarasa Cabezuelo Facultad de Inform´atica Universidad Complutense de Madrid Madrid, Junio 2018 I. Pr´ologo “Las buenas noticias solo llegan a los que se embarcan dispuestos a naufragar” All´a por el mes de febrero de 2017, tres amigos estudiantes de Ingenier´ıa Inform´atica de la Universidad Complutense de Madrid comenzaron a hablar sobre su Trabajo de Fin de Grado del curso siguiente. Ten´ıan claro que quer´ıan realizar un proyecto que perdurara en el tiempo, que quedara para la posteridad y que sirviera de ayuda para gran cantidad de gente. Hoy, 16 meses despu´es, estos tres alumnos por fin podemos decir que hemos finalizado un proyecto del que nos sentimos realmente orgullosos. Tras tres a˜nos en la facultad tocaba hacer uso de todo el conocimiento adquirido y de demostrar a profesores y a nosotros mismos que eramos capaces de desarrollar un verdadero proyecto inform´atico con todos sus apartados completamente desde cero. Adem´as, nuestros a˜nos de universidad y los per´ıodos interminables de estudio en la biblioteca, junto alg´un que otro intento frustrado de estudiar por no haber puestos libres, nos hab´ıan hecho darnos cuenta de un grave problema existente en las bibliotecas. As´ı pues, ya ten´ıamos idea sobre la que realizar el trabajo de fin de grado: una aplicaci´on m´ovil que permitiese ocupar el puesto y evitase que los descansos fuesen demasiado largos, todo ello haciendo uso de la geolocalizaci´on. A˜nadimos algunas funcionalidades extras a nuestra idea inicial, la pulimos un poco y nos embarcamos en la aventura del desarrollo del proyecto. Casi 500 d´ıas despu´es de la primera quedada del proyecto, tenemos una aplicaci´on completamente funcional disponible en Play Store con su respectiva p´agina web para la gesti´on por parte de los bibliotecarios. Confiamos en que se haga uso de ella en la biblioteca y que, ojal´a, pueda expandirse a otras muchas m´as bibliotecas para ayudar a cuanto mayor n´umero de estudiantes mejor. i II. Agradecimientos “No es verdad que las personas paran de perseguir sue˜nos porque se hacen viejos, se hacen viejos porque paran de perseguir sus sue˜nos.” No podemos comenzar esta memoria sin antes dar las gracias a nuestro director Antonio Sarasa Cabezuelo. Muchas gracias por confiar en el proyecto desde el primer momento, por todos los consejos que nos ha ido aportando y por todas las ideas que nos ha ido sugiriendo. Probablemente, este proyecto no podr´ıa haber sido desarrollado sin su ayuda. Gracias a nuestras familias y novias por aguantarnos en los d´ıas m´as dif´ıciles del desarrollo del proyecto, en los que siempre han estado ah´ı apoyando, y sobre todo por estos 4 largos a˜nos en los que hemos tenido momentos buenos y momentos malos, siendo en estos ´ultimos donde m´as se ha notado su gran apoyo, inquebrantable confianza e imprescindible ayuda. Muchas gracias. Ellos, junto a nuestros amigos a los que tambi´en queremos agradecer todo su apoyo, ´animos, sus sugerencias sobre el proyecto y esos d´ıas tan necesarios que nos han ayudado a respirar, han sido los que nos han aportado las energ´ıas necesarias para poder seguir con ilusi´on en los momentos en los que las cosas se torc´ıan un poco. Tambi´en, debemos agradecer al resto de profesores de la facultad que nos han dado clase durante estos a˜nos y que por tanto, de un modo u otro han aportado su granito de arena a este proyecto. A las bibliotecarias de la Facultad de Inform´atica, a los alumnos de la misma y a todos los usuarios de la aplicaci´on en general, muchas gracias por usarla y proporcionar el Feedback necesario con el que mejorar la aplicaci´on. Por ´ultimo, no quer´ıamos despedirnos sin hacer un par de menciones especiales a dos amigos que nos han ayudado mucho durante el proyecto. A ti, Mario, por estar ah´ı, ayudarnos con algunas dudas sobre Android que nos han surgido durante la realizaci´on del proyecto, gracias. Y a ti, Elena, por haber sido la betatester n´umero uno, por tus recomendaciones en cuanto al dise˜no y funcionalidades, y estar siempre pendiente de nuestro progreso, muchas gracias tambi´en. ii III. Resumen Biblioteko es una aplicaci´on ofrecida a estudiantes, profesores, visitantes y a todos los usuarios en general de la biblioteca de la Facultad de Inform´atica que permite conocer qu´e puestos est´an ocupados en tiempo real. Pero no solo eso, Biblioteko permite enviar sugerencias a los bibliotecarios/as, consultar el horario de la biblioteca, conocer estad´ısticas de el tiempo de estudio y descanso y compararlo con el tiempo medio de todos los estudiantes... Sin embargo, el principal atractivo de Biblioteko es intentar solucionar la problem´atica a la que cientos de estudiantes se ven sometidos durante los meses de enero y mayo. Durante estos meses las bibliotecas suelen estar m´as llenas y existen problemas con el n´umero de puestos disponibles. Algunos estudiantes espabilados acuden a ellas y se van a descansar durante tiempos superiores a las dos horas, dejando su puesto ocupado con un boli e impidiendo que otro estudiante lo ocupe. En este escenario se puede apreciar el gran potencial de Biblioteko, puesto que permite al usuario descansar hasta un m´aximo de 30 minutos, dependiendo de la cantidad de tiempo que haya estado estudiando. Si transcurrido el tiempo de descanso disponible, no ha vuelto a la biblioteca, su puesto ser´a liberado autom´aticamente. Adem´as, Biblioteko cuenta con una p´agina web dise˜nada exclusivamente para bibliotecarios/as y con acceso exclusivo para ellos. Desde esta p´agina, los bibliotecarios/as tienen acceso de una manera muy r´apida y sencilla a funcionalidades espec´ıficas para ellos tales como responder los mensajes enviados por los estudiantes, establecer el horario o consultar estad´ısticas de estudio referidas a cualquier rango de fecha de su inter´es. Palabras clave Biblioteca Aplicaci´on Estudio Puesto Descanso Biblioteko Inform´atica iii IV. Abstract Biblioteko is an app available for students, teachers, visitants and all users of the library of the Computer Science Faculty that offers real time information about which study spaces are busy. Furthermore, with Biblioteko users can send suggestions to the librarians, check the library opening hours, consult statistics about their study time and their study breaks, and compare them with the average of all the students... However, the main attraction of Biblioteko is a functionality that tries to solve the problem of a lot of students during the months of January and May. In these months, libraries are really busy and there are problems sometimes with the number of study spaces available. Some students go to the library and have never-ending breaks (even for more than 2 hours), leaving a pen in their study spaces and not letting other students use that study space. We can appreciate the big potential of Biblioteko here, as it allows the user to have breaks for a period no longer than 30 minutes, according to how many time he/she has been studying. If after the break time that was available for the user, he/she has not returned to the library, his/her study space will be release automatically. In addition, Biblioteko has a web page designed only and exclusively for the librarians and with exclusive access for them. From this web page, librarians have inmediately and easy access to some specific functionalities for them such as answer the messages sent by the students, set the opening hours and view statistics of the desired range by them. KeyWords Library Applicacion Study Study space Study break Biblioteko Computer Science iv ´ Indice I. Pr´ologo I II. Agradecimientos II III. Resumen III IV. Abstract IV 1. Introducci´on 1 1.1. Motivaci´on ....................................... 1 1.2. Objetivos ........................................ 2 1.3. Estadodelarte ..................................... 3 1.4. Estructuradelamemoria ............................... 5 2. Especificaci´on de los requisitos de la aplicaci´on 8 2.1. Funcionalidad aplicaci´on web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Funcionalidad aplicaci´on m´ovil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Fiabilidad........................................ 33 3. Tecnolog´ıas empleadas 34 3.1. Tecnolog´ıas en la aplicaci´on web . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2. Tecnolog´ıas en la aplicaci´on m´ovil . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3. Basesdedatos ..................................... 37 4. Arquitectura de la aplicaci´on 38 4.1. Aplicaci´onweb ..................................... 39 4.2. Aplicaci´onm´ovil .................................... 39 4.3. Basesdedatos ..................................... 40 4.4. Servidorexterno .................................... 40 4.5. APIs........................................... 40 5. Modelo de datos 41 5.1. BasededatosMySQL ................................. 41 5.2. BasededatosSQLite ................................. 47 5.3. Comunicaci´on entre los modelos de datos . . . . . . . . . . . . . . . . . . . . . . 48 6. Dise˜no de la aplicaci´on 50 6.1. Parteweb........................................ 51 6.2. Partem´ovil ....................................... 51 7. Implementaci´on de la aplicaci´on 53 7.1. Aplicaci´onweb ..................................... 53 7.1.1. Iniciodesesi´on................................. 54 7.1.2. Buz´on de sugerencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1.3. Estad´ısticas................................... 59 7.1.4. Horario ..................................... 61 7.1.5. Cerrarsesi´on .................................. 64 7.1.6. Qui´enessomos ................................. 64 7.1.7. Header...................................... 64 7.1.8. Footer...................................... 65 v 7.2. Aplicaci´onm´ovil .................................... 67 7.2.1. Starter...................................... 70 7.2.2. Iniciarsesi´on .................................. 72 7.2.3. Registrar .................................... 75 7.2.4. Bibliotecas ................................... 77 7.2.5. Plantas ..................................... 78 7.2.6. Mesa....................................... 83 7.2.7. Ocuparpuesto ................................. 86 7.2.8. Vaciarpuesto.................................. 88 7.2.9. Hacer descanso/Finalizar descanso . . . . . . . . . . . . . . . . . . . . . . 92 7.2.10.Estad´ısticas................................... 99 7.2.11.Contacto ....................................101 7.2.12.Horario .....................................103 7.2.13. Modificar contrase˜na . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.2.14.Cerrarsesi´on ..................................109 7.2.15. Ay´udanos a mejorar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.2.16.ServiceUbicaci´on................................111 7.2.17.Alarma .....................................115 7.2.18.AlarmaEstoyVivo...............................117 7.3. Otros componentes del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 8. Evaluaci´on de usuarios y pruebas 124 8.1. Iniciodelproyecto ...................................124 8.2. Duranteelproyecto ..................................124 8.3. Traselproyecto.....................................124 9. Conclusiones y trabajo futuro 132 9.1. Conclusiones ......................................132 9.2. Conclusions.......................................133 9.3. Trabajofuturo .....................................134 9.4. Trabajoindividual ...................................135 9.4.1. Carlos Gavidia Ortiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.4.2. David Gorricho San Juan . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 9.4.3. Iv´an Monterrubio Cerezo . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 10.Bibliograf´ıa 142 11.Ap´endices 144 11.1. Ap´endice A: Manual de instalaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 144 11.1.1.P´aginaweb ...................................144 11.1.2.AndroidStudio.................................144 11.1.3.SublimeText..................................144 11.1.4.MySQL .....................................144 11.1.5. Aplicaci´on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 11.2. Ap´endice B: Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 11.2.1.Aplicaci´onweb.................................145 11.2.1.1. Iniciar sesi´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 11.2.1.2. Buz´on de sugerencias . . . . . . . . . . . . . . . . . . . . . . . . 146 11.2.1.3.Estad´ısticas..............................147 11.2.1.4. Establecer Horario . . . . . . . . . . . . . . . . . . . . . . . . . . 148 11.2.1.5. Descargar app . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 11.2.1.6.Qui´enessomos ............................149 vi 11.2.1.7. Cont´actanos/Redes Sociales . . . . . . . . . . . . . . . . . . . . . 149 11.2.1.8.Cerrarsesi´on.............................149 11.2.2.Aplicaci´onm´ovil ................................149 11.2.2.1. Iniciar sesi´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 11.2.2.2.Registrarse ..............................150 11.2.2.3.Bibliotecas ..............................151 11.2.2.4.Plantas ................................152 11.2.2.5. Hacer descanso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 11.2.2.6.Liberarpuesto ............................154 11.2.2.7.Estad´ısticas..............................154 11.2.2.8.Contacto ...............................155 11.2.2.9.Horario ................................156 11.2.2.10.Modificar contrase˜na . . . . . . . . . . . . . . . . . . . . . . . . . 157 11.2.2.11.Cerrarsesi´on.............................157 11.2.2.12.Ay´udanos a mejorar . . . . . . . . . . . . . . . . . . . . . . . . . 158 12.Anexo 159 vii 1. Introducci´on En este primer cap´ıtulo de la memoria se va a desarrollar la motivaci´on del proyecto desarrollado, cu´ales han sido sus objetivos y la estructura general de esta memoria. Adem´as, es necesario destacar que se ha realizado la publicaci´on de la aplicaci´on ‘Biblioteko’ en Google Play y registrado el dominio http://biblioteko.es en el que se encuentra alojada la aplicaci´on web. In this first chapter of the memory, the motivation, objectives of the project and the general structure of the project are going to be explained. In addition, it is important to mention that the application Biblioteko has been released in Google Play and the webpage is located in the domain http://biblioteko.es 1.1. Motivaci´on Durante los meses de Enero y Mayo, la ocupaci´on en las bibliotecas llega a su punto m´aximo, repletas de estudiantes que tratan de ocupar hasta el ´ultimo puesto disponible. Para ayudar a que todos los estudiantes puedan estudiar, la mayor´ıa de las bibliotecas retrasan los horarios de cierre, de forma que los estudiantes puedan aprovechar las instalaciones durante m´as tiempo. Durante el tiempo de estudio, es com´un en los estudiantes realizar descansos con el fin de despejar la mente peri´odicamente. Cuando se realizan los descansos es cuando se producen ciertos problemas con respecto a la ocupaci´on de los sitios de estudio de la biblioteca. Cuando una persona abandona su sitio y regresa del descanso puede verse sorprendido y que su sitio haya sido ocupado por otra persona. Por esa raz´on, muchos estudiantes se ven obligados a dejar objetos encima de su puesto antes de tomar ese descanso para despreocuparse de este problema. Por ello, es habitual ver varios sitios con objetos y sin ocupaci´on aparentemente. Sin embargo, el hecho de reservar puestos hace que surja otra problema puesto que, a veces, algunos estudiantes reservan puestos por tiempos excesivamente largos, privando a otros usuarios de poder ocupar un puesto. El sistema que se propone en este trabajo tiene como objetivo ayudar a aquellos estudiantes que quieran descansar (siempre que respeten y no sobrepasen el tiempo de descanso) a que ya no tengan que dejar objetos encima de la mesa, con el riesgo que supone, debido a que pueden sustraerlo. As´ı un estudiante que entrase a la biblioteca ver´ıa que este puesto est´a ocupado y no puede ocuparlo. Un mapa de la ocupaci´on de la biblioteca ser´a donde el estudiante podr´a visualizar los sitios disponibles. Adem´as, el sistema ser´ıa el encargado de liberar autom´aticamente un puesto en el caso de que el usuario haya superado el tiempo de descanso que ten´ıa disponible. Tambi´en ofrece la posibilidad de consultar estad´ısticas, el horario disponible y permite enviar mensajes a los/as bibliotecarios/as. La aplicaci´on desarrollada tambi´en dispondr´ıa de una aplicaci´on web, de acceso exclusivo para los bibliotecarios en la cual podr´ıan contestar los mensajes de los estudiantes, consultar estad´ısticas generales de la biblioteca y especificar su horario. 1 2. Especificaci´on de los requisitos de la aplicaci´on En esta secci´on se van a mostrar la especificaci´on de requisitos del sistema. Para ello se ha dividido en varias partes. En la primera parte, se presentan los requisitos referidos a la parte web del proyecto. En la segunda parte aparecen los referidos a la parte Android. Finalmente en la tercera es un apartado reservado para la fiabilidad del proyecto. 2.1. Funcionalidad aplicaci´on web La p´agina web ser´a una herramienta con la que contar´an y podr´an consultar todos los d´ıas los/as bibliotecarios/as y podr´an realizar algunas de sus funciones diarias m´as r´apidamente. Por esto el desarrollo de la p´agina web tiene como objetivo que el bibliotecario pueda contestar y leer los correos del buz´on de sugerencias que los alumnos hayan enviado, actualizar los horarios de apertura y cierre de la biblioteca o consultar distintas estad´ısticas de ocupaci´on y estudio. A continuaci´on en la Figura 1 se presenta el diagrama de casos de uso, que resume todas las funcionalidades que tendr´a el usuario de la p´agina web. Figura 1: Casos de uso aplicaci´on web 8 Funcionalidad 1: Inicio de sesi´on Ser´a la pantalla principal de la aplicaci´on web y en ella el bibliotecario podr´a iniciar su sesi´on introduciendo una cuenta y contrase˜na(ambas suministradas por la facultad, por lo que todos los bibliotecarios iniciar´an sesi´on con la misma cuenta) en dos ´areas de texto designadas para ello. Si los datos suministrados no coinciden con los de la base de datos de la aplicaci´on, el usuario ser´a notificado. Figura 2: Iniciar sesi´on web 9 Funcionalidad 2: Limpiar base de datos Esta funci´on se realizar´a autom´aticamente, sin intervenci´on del usuario, y consistir´a en una limpieza de la base de datos, es decir las estad´ısticas de los usuarios pasado un tiempo, para evitar el colapso de la base de datos. Figura 3: Limpiar base de datos 10 Funcionalidad 3: Establecer horario Como la biblioteca no tendr´a unos horarios fijos durante todo el a˜no(por ejemplo en ´epocas de ex´amenes estar´a abierta m´as tiempo),el bibliotecario se encargar´a de escribir en la p´agina el horario de cada d´ıa de la semana; el horario de apertura y de cierre gracias a la interfaz sencilla, informando adem´as de periodos no lectivos o d´ıas especiales. Figura 4: Establecer horario 11 Funcionalidad 4: Consultar estad´ısticas generales El bibliotecario podr´a ver las mismas estad´ısticas que las recogidas en la app. Figura 5: Consultar estad´ısticas generales 12 Funcionalidad 5: Leer/contestar buz´on de sugerencias Los correos que lleguen al bibliotecario de los usuarios de la app a partir del buz´on de sugerencias podr´an ser le´ıdos y contestados a la persona que los envi´o. Adem´as, el bibliotecario no sabr´a quienes los han mandado (ser´an an´onimos). Figura 6: Buz´on de sugerencias - Mensajes recibidos 13 Figura 7: Buz´on de sugerencias - Contestar mensaje 14 2.2. Funcionalidad aplicaci´on m´ovil Las funciones que podr´an realizar los usuarios ser´an ocupar/desocupar un sitio dentro de la biblioteca, visualizar el mapa donde podr´an observar los sitios libres y ocupados, adem´as de ver informaci´on de la biblioteca como el horario de apertura y cierre, enviar mensajes a los bibliotecarios a partir de un buz´on de sugerencias, ver sus estad´ısticas personales y globales de tiempo de estudio y ocupaci´on y por ´ultimo revisar su informaci´on personal (email,cambiar su contrase˜na,etc.). A continuaci´on, en la Figura 8 se incluye el diagrama de casos de uso en el que se pueden observar todas las funcionalidades que tendr´a el usuario de la aplicaci´on m´ovil Android. Figura 8: Casos de uso aplicaci´on m´ovil 15 Funcionalidad 1: Inicio de sesi´on Esta ser´a la primera ventana que aparecer´a al usuario al abrir la aplicaci´on, en caso de que sea la primera vez que entre en la app. En ella se podr´a conectar al sistema, si ya est´a registrado, con su email y su contrase˜na. Si los datos suministrados no coinciden con los almacenados en la base de datos, el usuario ser´a notificado. En caso de no estar registrado, podr´a pulsar en un enlace que le llevar´a a la ventana de registro. Figura 9: Iniciar sesi´on aplicaci´on m´ovil 16 Funcionalidad 2: Registro En el caso de que no se encuentre registrado en la aplicaci´on, llegar´a a esta pantalla a trav´es del acceso que aparece en la pantalla de inicio de sesi´on. En la misma, el usuario proporcionar´a su correo electr´onico y la contrase˜na que quiera para registrarse. Si las contrase˜nas no coinciden o el email ya est´a registrado en la base de datos, el registro no se completar´a y se informar´a al usuario del error acontecido. Una vez se ha finalizado el registro, un email ser´a enviado a la cuenta de correo electr´onico para confirmar el alta y que el usuario tiene acceso a ese correo. Figura 10: Registrarse aplicaci´on m´ovil 17 Funcionalidad 9: Modificar contrase˜na Desde la misma, el usuario podr´a modificar la contrase˜na tras introducir su contrase˜na antigua e introducir la nueva contrase˜na dos veces para garantizar que no se ha equivocado. Una vez hecho, pulsar´a el bot´on de aceptar y la app se comunicar´a con la base de datos para modificar la contrase˜na del usuario almacenada. Figura 17: Modificar contrase˜na 24 Funcionalidad 10: Horario Los usuarios podr´an consultar el horario de la biblioteca, as´ı como informaci´on relevante, a trav´es de una opci´on del men´u. Este horario ser´a asignado por el bibliotecario a trav´es de la aplicaci´on web. Figura 18: Horario 25 Funcionalidad 11: Buz´on de sugerencias Esta opci´on tendr´a una doble funcionalidad. Al ser pulsada aparecer´an dos opciones. La primera de ellas ser´a escribir sugerencia. Se tratar´a de sugerencias que el bibliotecario leer´a de forma an´onima y podr´a responder tambi´en sin conocer qui´en fue el que la escribi´o. Es aqu´ı cuando entra en escena la otra funcionalidad, llamada leer respuestas. En el caso de que un bibliotecario conteste a una de las sugerencias enviadas por un usuario determinado, ´este podr´a leer su respuesta desde esta opci´on. (a) Enviar sugerencia (b) Leer respuestas Figura 19: Buz´on de sugerencias 26 Funcionalidad 12: Informaci´on aplicaci´on Estar´a disponible desde el men´u, informaci´on sobre la aplicaci´on, como su versi´on, datos sobre sus desarrolladores o una opci´on para ponerse en contacto con ellos. Figura 20: Informaci´on de la aplicaci´on 27 Funcionalidad 13: Comprobar disponibilidad puesto Una vez el usuario haya seleccionado el puesto que desea ocupar, la app se comunicar´a con la base de datos para garantizar que el puesto que quiere ocupar est´a disponible y pasar´a a ser de otro color diferente al resto de puestos ocupados. En caso contrario, se notificar´a al usuario que ha habido un error y podr´a volver a seleccionar puesto. Figura 21: Comprobar disponibilidad de puesto 28 Funcionalidad 14: Temporizador ocupar puesto La aplicaci´on debe encargarse de comprobar que un usuario no se encuentre en la biblioteca ocupando un puesto de estudio sin haberlo notificado. Para ello, cuando detecte que el usuario ha entrado en la biblioteca, comenzar´a a incrementar un temporizador. En el caso de que este llegue a 20 minutos y el estudiante a´un no haya ocupado un puesto, se le mostrar´a un mensaje en el que se le sugerir´a que por favor, ocupe un puesto de estudio si va a permanecer en la biblioteca durante m´as tiempo. Figura 22: Mensaje: ’Por favor ocupa puesto’ 29 Funcionalidad 15: Preguntar por descanso Si el usuario decide salir de la biblioteca sin haber anunciado que iba a realizar un descanso, autom´aticamente se pondr´a en modo descanso siempre que le quedan minutos de descanso disponibles. Adem´as, se mostrar´a un mensaje al usuario que le preguntar´a si ha abandonado la biblioteca o si por el contrario se est´a tomando un descanso. De no contestar el usuario en un plazo de 5 minutos, se liberar´a su puesto y quedar´a disponible para el resto de estudiantes. Figura 23: Mensaje: ’Preguntar por descanso’ 30 Funcionalidad 16: Temporizador descanso Una vez que el usuario ha decidido tomarse un descanso, el temporizador de tiempo disponible (tiempo que el usuario hab´ıa ido acumulando mientras estudiaba) comienza a decrementar. Cuando nos encontramos a cinco minutos de que llegue a 0, un mensaje es mostrado al usuario avis´andole de que s´olo quedan 5 minutos para que le d´e tiempo a regresar a la biblioteca para estudiar. Figura 24: Mensaje: ’Aviso de fin de descanso’ 31 Funcionalidad 17: Env´ıo de localizaci´on La aplicaci´on necesitar´a saber la ubicaci´on del usuario en ciertas situaciones para comprobar que este no est´a tratando de introducir datos que no son reales. Cada cierto intervalo de tiempo, que ser´a establecido por los desarrolladores, la aplicaci´on enviar´a al servidor la ubicaci´on exacta del usuario, utilizando para ello el sistema de geolocalizaci´on integrado en todos los smartphones. La aplicaci´on har´a uso de estos datos para varias funcionalidades, como saber si el usuario se encuentra dentro o fuera de la biblioteca, incrementar o decrementar el temporizador de tiempo de estudio, avisar al estudiante si ha terminado su descanso y debe volver a entrar en la biblioteca, etc´etera. Funcionalidad 18: Temporizador estudio Tras haber iniciado el estudio el usuario, se pondr´a en marcha un temporizador de estudio que se incrementar´a en un minuto por cada minuto que el usuario pase estudiando hasta un m´aximo de 30 minutos. Este tiempo ser´a del que podr´a disponer el usuario para tomarse descansos. Una vez vuelva de descansar, el temporizador volver´a a incrementarse desde los minutos que ha dejado sin usar el usuario, hasta un m´aximo total de 30. Funcionalidad 19: Comprobar situaci´on dentro/fuera biblioteca La base de datos tendr´a almacenada la ubicaci´on exacta de la biblioteca en la que se encuentra el estudiante, de modo que cuando se env´ıe la localizaci´on, la app podr´a saber si se encuentra dentro de la misma o ha salido fuera del per´ımetro establecido. Esto permitir´a comprobar que la posici´on del estudiante coincide con el estado actual que ha establecido en la app, los cuales pueden ser estudiando, descansando o fuera de la biblioteca. De esta forma, se evita que el usuario falsifique su posici´on. Por ejemplo, si en la app aparece como estudiando pero se detecta que se encuentra fuera de la biblioteca, se le preguntar´a si est´a realizando un descanso, como se explica en el apartado ‘Preguntar por descanso’. Funcionalidad 21: Aviso fin de descanso Se mostrar´an diferentes mensajes al usuario que le avisaran de que le quedan tan solo 5 minutos para que finalice su descanso, as´ı como otro que avisar´a de que su descanso ha finalizado. Funcionalidad 22: Cerrar sesi´on Si el usuario desea cerrar sesi´on en la aplicaci´on m´ovil, podr´a hacerlo. Esto conllevar´a eliminar la sesi´on activa de la base de datos interna del m´ovil y parar de comprobar la ubicaci´on del usuario. 32 2.3. Fiabilidad La aplicaci´on Android est´a desarrollada en la versi´on 7 de Android, permitiendo que pueda funcionar para versiones anteriores, siendo esta versi´on donde se han realizados las pruebas durante el proyecto. La gesti´on de errores de la aplicaci´on est´a pensada para informar al usuario en todo momento de lo que ocurre en la aplicaci´on, con mensajes claros, especificando los fallos que se han producido. Algunos de ellos son referidos al usuario y otros a la comunicaci´on con el servidor, temporizadores o de conexi´on. Uno de los puntos fundamentales para el limpiado de datos en la base de datos, es la funci´on autom´atica que se realiza en la web, la cual agrupa las estad´ısticas de los usuarios de tiempo de estudio, usuarios inactivos de hace m´as de un a˜no o mensajes del buz´on de sugerencias, para as´ı poder reciclar espacio en la base de datos. De esta manera se consigue reducir el n´umero de problemas que pueden surgir al tratar con tablas de gran tama˜no. 33 Adem´as, se pueden consultar las estad´ısticas personales y globales de tiempo de estudio y descanso, para as´ı poder hacer un balance de estudio personal. Tambi´en permite enviar y recibir mensajes a los bibliotecarios, pudiendo enviar sugerencias y dudas y permitiendo un hilo de comunicaci´on entre bibliotecarios y estudiantes. Como a˜nadido, presenta otras funciones como ver horarios, siempre que ´estos hayan sido configurados por los bibliotecarios, tal y como se describi´o en el apartado anterior. 4.3. Bases de datos Las funciones que tienen las bases de datos son la de almacenar la informaci´on general (en el caso de la base de datos relacional), y del propio usuario (la del SQLite). La base de datos relacional, la cual utiliza MySQL, guarda datos de todos los usuarios, mensajes, horarios, puestos y plantas de las bibliotecas dadas de alta en la base de datos, coordenadas de cada una de ellas... Adem´as, almacena un hist´orico con todas las conexiones de todos los usuarios a las diferentes bibliotecas, para as´ı poder mostrarle a cada uno sus estad´ısticas de estudio. Por otro lado, la base de datos local de cada tel´efono m´ovil tan solo se encarga de guardar los datos del usuario, as´ı como el puesto ocupado actualmente, las coordenadas actuales del usuario, estado, tiempo que tiene para descansar... 4.4. Servidor externo El servidor externo es utilizado para guardar toda la informaci´on de la base de datos, adem´as de alojar todos los archivos necesarios para el correcto funcionamiento tanto de la p´agina web como de la aplicaci´on. Se ha optado por un servidor de pago, con 6GB de almacenamiento SSD que nos garantiza un r´apido acceso a todos los archivos, con una latencia extremadamente baja y 1GB de RAM. Considerando que estas caracter´ısticas eran suficientes para este determinado proyecto. 4.5. APIs La API de geolocalizaci´on es necesaria para conseguir las coordenadas geoespaciales del usuario m´ovil, una vez este haya iniciado sesi´on. Para poder obtener la ubicaci´on del usuario cada cierto per´ıodo de tiempo se ha usado una aplicaci´on en segundo plano, un Service, que est´a consultando con la API anterior, la de geolocalizaci´on para as´ı poder conocer la latitud y longitud del usuario. En el cap´ıtulo de implementaci´on se desarrollar´a por qu´e fue necesario conocer la ubicaci´on de cada usuario cada cierto tiempo. Para las estad´ısticas, tanto del cliente web como del cliente m´ovil se ha utilizado una determinada API, con varias funciones en JavaScript que permiten visualizar los gr´aficos interactivos que tenemos implementados. Y en cuanto a la API PIP, punto en pol´ıgono, es utilizada para, una vez suministrado el pol´ıgono formado por la biblioteca, determinar as´ı si las coordenadas geogr´aficas que obtenemos del usuario est´an dentro del recinto de esta, o fuera de ella. 40 5. Modelo de datos En este cap´ıtulo se detalla la base de datos empleada y se describe la funcionalidad y significado de cada tabla y campo. En primer lugar se realiza la explicaci´on de la base de datos ubicada en el servidor para, posteriormente, explicar la que se aloja localmente en el dispositivo m´ovil de cada usuario. Finalmente, se concluye con una secci´on en la que se relacionan los dos modelos, los cuales son ambos relacionales. Se ha optado por la implementaci´on de un modelo de datos relacional para tratar de garantizar la persistencia de los datos y hacer uso de su gran rendimiento y estabilidad, logrando as´ı un ahorro tanto en bater´ıa como en datos. 5.1. Base de datos MySQL La base de datos MySQL, la cual ofrece un gran rendimiento y es estable, es la base de datos en la que concentramos toda la informaci´on de la aplicaci´on. Esto incluye todos los usuarios registrados, el hist´orico de los mismos o todos los horarios de las bibliotecas implementadas entre otras cosas. A ella se accede en m´ultiples ocasiones, cuando se quiere comprobar la disponibilidad de puestos, ver las bibliotecas disponibles, los mensajes intercambiados con los bibliotecarios, las estad´ısticas... Se trata de la base de datos maestra y es la que prevalece en caso de conflicto con la base de datos local del m´ovil de cada usuario. Sobre ella se produce la concentraci´on de todos los datos provenientes de los diferentes usuarios registrados en la aplicaci´on. Se trata de una base de datos MySQL. Consta de 9 tablas relacionadas entre s´ı mediante claves for´aneas y atributos: bibliotecas, envia, historico, horarios, ocupa, puestos, usuarios, usuariosActivos y usuariosTemp. Cada una de ellas guarda informaci´on espec´ıfica acerca de diferentes aspectos necesarios para el funcionamiento de la app. A continuaci´on, en la Figura 26 se muestra el diagrama entidad-relaci´on, para poder resumir de una manera visual y gr´afica como est´a dispuesta la base de datos y qu´e relaciones hay entre las diferentes tablas. 41 Figura 26: Diagrama entidad-relaci´on de la base de datos MySQL Bibliotecas Se trata de una tabla en la cual se almacenan las diferentes bibliotecas que est´an implementadas. Aunque en la actualidad tan solo existe una fila con la biblioteca de la facultad de inform´atica, el prop´osito es que la aplicaci´on crezca e ir implementado m´as bibliotecas, para lo cual es necesario disponer de esta tabla. Es una tabla a la cual solo se puede acceder mediante PHPMyAdmin, de forma que ´unicamente pueden acceder a la misma los 3 miembros del equipo de desarrollo. De esta forma, cuando se produzca la implementaci´on de una nueva biblioteca, los desarrolladores ser´an los encargados de insertar todos los campos de la misma. Consta de once campos, los cuales son los siguientes: siglas: Es la clave primaria de la tabla, se trata de una cadena de 3 caracteres may´usculas que sirven para identificar a la biblioteca. nombre: Es un campo varchar con una longitud m´axima de 100 caracteres. En este campo es donde se almacena el nombre completo de la biblioteca. contrasenia: De igual manera que en el campo anterior, se trata de un campo varchar con una longitud m´axima de 100 caracteres. Aqu´ı se almacena la contrase˜na hasheada necesaria, junto a las siglas, para acceder a la p´agina de gesti´on de los bibliotecarios. NO Lat: Se trata de un campo double en el cual se almacena la latitud del punto situado m´as al noroeste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. NO Lon: Se trata de un campo double en el cual se almacena la longitud del punto situado m´as al noroeste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. 42 NE Lat: Se trata de un campo double en el cual se almacena la latitud del punto situado m´as al noreste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. NE Lon: Se trata de un campo double en el cual se almacena la longitud del punto situado m´as al noreste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. SO Lat: Se trata de un campo double en el cual se almacena la latitud del punto situado m´as al suroeste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. SO Lon: Se trata de un campo double en el cual se almacena la longitud del punto situado m´as al suroeste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. SE Lat: Se trata de un campo double en el cual se almacena la latitud del punto situado m´as al sureste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. SE Lon: Se trata de un campo double en el cual se almacena la longitud del punto situado m´as al sureste del recinto de la biblioteca. Sirve para determinar si nos encontramos dentro de la biblioteca o fuera. Envia En esta tabla, est´an recogidos los diferentes mensajes intercambiados entre los usuarios y la biblioteca correspondiente. A ella se accede cuando se produce el env´ıo de un mensaje, tanto por parte del usuario como por parte del bibliotecario. En ese caso, se produce la inserci´on de una nueva fila en la tabla. Adem´as, tambi´en se accede a ella, como bibliotecarios, cuando quieren leer los mensajes que les han mandado los usuario y, como usuarios, cuando quieren leer las respuestas que les han dado los bibliotecarios. A pesar de que los mensajes almacenados en esta tabla constan de un campo email, de forma que ser´ıa posible saber qui´en es el usuario que ha escrito cada mensaje, al bibliotecario se le mostrar´an sin dicho campo para garantizar el anonimato de todos los estudiantes. Consta de siete campos, los cuales son los siguientes: email: Forma parte de la clave primaria, se trata de una clave for´anea que hace referencia al campo email de la tabla usuarios. Es un varchar de 40 caracteres que permite saber qui´en es el usuario que ha escrito el mensaje, para as´ı poder mostrar la respuesta tan solo a dicho usuario, no a todos. biblioteca: Forma parte de la clave primaria, se trata de una clave for´anea que hace referencia al campo siglas de la tabla bibliotecas. Es un varchar de 3 caracteres que permite saber hacia qu´e biblioteca iba dirigido el mensaje, para as´ı mostrar dicho mensaje a tan solo esa biblioteca. fecha: Se trata de un datetime que permite almacenar la fecha en la que fue escrito el mensaje. respuesta: Forma parte de la clave primaria, se trata de un tinyint, tambi´en conocido como booleano que permite saber si el mensaje se trata de un mensaje enviado por el usuario o de una respuesta del bibliotecario. En el caso de que se trate de un mensaje 43 enviado por el usuario estar´a a 0, en el caso de que sea respuesta del bibliotecario, estar´a a 1. asunto: Se trata de un campo varchar de longitud 100 caracteres en el cual se almacena el asunto del mensaje. contenido: Se trata de un campo varchar de longitud 4000 caracteres en el cual se almacena el contenido del mensaje, es decir, el mensaje propiamente. idMensaje: Forma parte de la clave primaria, se trata de un entero que se va autoincrementando a medida que van llegando nuevos correos de los estudiantes. Cuando un bibliotecario responda a uno de estos mensajes, se introducir´a en la tabla envia con el mismo idMensaje pero con el campo respuesta a 1. Historico Esta tabla es la que se usa para almacenar y mantener un hist´orico de todas las conexiones de los diferentes usuarios a todas las bibliotecas implementadas en la aplicaci´on. Es muy ´util puesto que sin ella luego no ser´ıa posible mostrar las estad´ısticas, ni al usuario ni a los bibliotecarios, del tiempo que han estado estudiando o descansando los estudiantes. Puesto que se produce una nueva inserci´on cada vez que un usuario pasa de estado estudiando a descansando y, por tanto, el n´umero de inserciones por usuario y por d´ıa puede ser muy elevado, se ha realizado un CRON Job que, cada d´ıa de madrugada, agrupe las conexiones anteriores a un a˜no en a˜nos, qued´andose solo con las conexiones espec´ıficas del ´ultimo a˜no y agrupando el resto por a˜nos. As´ı, se consigue reducir el tama˜no de la tabla historico considerablemente. Consta de cinco campos, los cuales son los siguientes: email: Forma parte de la clave primaria, se trata de una clave for´anea que hace referencia al campo email de la tabla usuarios. Es un varchar de 40 caracteres que permite saber qui´en es el usuario que ha estado estudiando/descansando en ese momento, para as´ı tener luego sus estad´ısticas personales que poder mostrar. fecha inicio: Forma parte de la clave primaria. Se trata de un timestamp que permite almacenar cu´ando comenz´o el estado de ese usuario. Es decir, el momento en el que comenz´o a estudiar o a descansar. duracion: Se trata de un entero en el cual se almacena la duraci´on en segundos de ese determinado estado. Es decir, si un estudiante ha estado estudiando 10 minutos antes de iniciar su descanso, su entrada respectiva tendr´a el campo duracion a 600. estudiando: Se trata de un tinyint, tambi´en conocido como booleano que permite saber si el estudiantes estaba estudiando o descansando. En el caso de que estuviera estudiando estar´a a 1, mientras que si estaba descansando, estar´a a 1. puesto: Forma parte de la clave primaria, se trata de una clave for´anea que hace referencia al campo ID de la tabla puestos. Se trata de un varchar de longitud 10 que permite conocer en qu´e puesto estaba estudiando el usuario. 44 Horarios En esta tabla se almacenan los horarios seg´un cada d´ıa de la semana para las diferentes plantas de cada biblioteca implementada en la aplicaci´on. El bibliotecario es el ´unico que puede modificar los horarios de las diferentes plantas de la biblioteca a la que pertenece, seg´un vayan a estar abiertas. Es una tabla a la cu´al se accede para modificarla desde el apartado establecer horario de la p´agina web si se quieren modificar los horarios que hay establecidos o desde la aplicaci´on m´ovil, como estudiantes, para as´ı poder consultar el horario de la biblioteca en la que se encuentre. Consta de cinco campos, los cuales son los siguientes: biblioteca: Forma parte de la clave primaria, se trata de una clave for´anea que hace referencia al campo siglas de la tabla bibliotecas. Es un varchar de 3 caracteres que permite saber a qu´e biblioteca hace referencia dicho horario. planta: Forma parte de la clave primaria, se trata de un varchar de longitud m´axima 40 caracteres que permite saber el nombre de la planta a la cual hace referencia dicho horario. Esto est´a as´ı implementado puesto que hay bibliotecas en las cuales cada planta puede cerrar a una determinada hora. El nombre de la planta es especificado por el bibliotecario cuando establece el horario. dia: Forma parte de la clave primaria, se trata de un varchar de longitud 10 en el cual se almacena el d´ıa de la semana al cual hace referencia dicho horario. hora inicio: Se trata de un time en el cual se almacena la hora de apertura de la biblioteca para ese d´ıa. Por convenio, si est´a cerrada ese d´ıa se almacenar´a 11:11:11 y si est´a abierta 24 horas 23:59:59. hora fin: Se trata de un time en el cual se almacena la hora de cierre de la biblioteca para ese d´ıa. Por convenio, si est´a cerrada ese d´ıa se almacenar´a 11:11:11 y si est´a abierta 24 horas 23:59:59. Ocupa Esta tabla contiene la ocupaci´on actual de todas las bibliotecas que est´en implementadas en la aplicaci´on. Es muy ´util puesto que es la tabla que se comprueba a la hora de realizar las estad´ısticas en las que se muestran a tiempo real el n´umero de puestos que est´an ocupados Adem´as, se usa para garantizar la integridad entre la tabla puestos y la tabla ocupa, de forma que todos los puestos que aparezcan como ocupados en la tabla puestos deben tener su respectiva entrada en la tabla ocupa. Consta de cuatro campos, los cuales son los siguientes: email: Forma parte de la clave primaria, se trata de una clave for´anea que hace referencia al campo email de la tabla usuarios. Es un varchar de 40 caracteres que permite saber qui´en es el usuario que est´a ocupando ese determinado puesto. Es una informaci´on que es ´util para as´ı mostrar su propio puesto de otro color al usuario en el mapa de puestos de la biblioteca. puesto: Se trata de una clave for´anea que hace referencia al campo ID de la tabla puestos. Se trata de un varchar de longitud 10 que permite conocer en qu´e puesto est´a estudiando el usuario. En combinaci´on con el campo anterior permite saber qu´e usuario es el que est´a ocupando cada puesto. 45 temporizador: Se trata de un entero en el cual se almacena el tiempo que lleva el estudiante en dicho puesto. Originalmente iba a servir para ver cu´anto era el tiempo de descanso disponible de cada usuario pero finalmente no se hace uso del mismo puesto que la implementaci´on del tiempo disponible se realiza desde la app para evitar conexiones con el servidor que gasten bater´ıa. dentro: Se trata de un tinyint, tambi´en conocido como booleano que permite saber si el estudiante si encuentra descansando o estudiando. Si est´a a 0 est´a descansando y si est´a a 1 estudiando. Puestos Esta tabla incluye todos los puestos de todas las bibliotecas implementadas en la aplicaci´on. Adem´as, existen puestos comod´ın del estilo XXXGlobal y TGlobalXXX que permiten agrupar todas las estad´ısticas de un determinado usuario en a˜nos pasados (para la problem´atica de que la tabla historico fuera demasiado grande). Es una tabla en la cual ni los bibliotecarios ni los usuarios pueden hacer nuevas inserciones. Son los tres desarrolladores los responsables de incluir nuevos puestos en el caso en el que se incluya una nueva biblioteca en la aplicaci´on. El acceso desde la aplicaci´on a esta tabla solo se producir´a en el caso de que un puesto pase a estar ocupado. Consta de tan solo dos campos, los cuales son los siguientes: ID: Es la clave primaria, se trata de un varchar de longitud 10 caracteres con la forma SIG PL XXX que permite identificar cada puesto de cada biblioteca implementada. SIG son las siglas de la biblioteca a la que se refiere, PL el id de la planta de esa biblioteca y XXX el n´umero de puesto de esa planta en concreto. ocupado: Se trata de un tinyint, tambi´en conocido como booleano que permite saber si el puesto ocupado o no. Si est´a a 0 est´a libre y si est´a a 1 est´a ocupado. Como se ha indicado antes, para cada puesto ocupado, debe haber una entrada en la tabla ocupa. Usuarios En esta tabla aparecen todos los usuarios que se encuentran registrados en la aplicaci´on, con sus respectivas contrase˜nas. Es una tabla a la cual se accede en el momento en el que se crea un usuario nuevo (insert´andolo en la tabla) y cuando un estudiante abre la aplicaci´on para verificar que su contrase˜na es correcta. Consta de tres, los cuales son los siguientes: email: Es la clave primaria, se trata de un varchar de longitud 40 caracteres que permite identificar al usuario. contrasenia: Se trata de un varchar de longitud 100 caracteres en el cual se almacena la contrase˜na del usuario hasheada. Permite comprobar que la contrase˜na introducida es correcta. activado: Se trata de un tinyint, tambi´en conocido como booleano que permite saber si el usuario est´a activado o no. Si est´a a 0 no est´a activado y si est´a a 1 s´ı lo est´a. A la hora de acceder a la aplicaci´on se comprueba que este campo est´a a 1 para as´ı permitir el acceso a la misma. 46 UsuariosActivos En esta tabla se almacena el email del usuario junto a su ´ultimo env´ıo de se˜nal activo. Con ello, se puede determinar si ese m´ovil sigue estando encendido o no. Es una tabla en la cual se inserta una fila cuando un usuario ocupa un puesto y dicha fila se va actualizando peri´odicamente cada 15 minutos, siempre que no se libere dicho puesto o se apague el m´ovil. Adem´as, a esta tabla accede peri´odicamente un CRON Job para verificar qu´e moviles siguen activos. Consta de tan solo dos campos, los cuales son los siguientes: email: Es la clave primaria, se trata de una clave for´anea que hace referencia al campo email de la tabla usuarios. Es un varchar de 40 caracteres que permite saber qui´en es el usuario el cu´al su m´ovil sigue encendido. Es una informaci´on importante, puesto que, de no aparecer aqu´ı su email, su puesto se liberaba en la siguiente ejecuci´on del CRON Job. ultimaInfo: Se trata de un timestamp que permite conocer cu´ando fue mandada por ´ultima vez informaci´on desde el m´ovil de su usuario. Es una informaci´on muy importante ya que, dependiendo de ese valor, el CRON Job interpretar´a que el m´ovil ha sido apagado o no y liberar´a su puesto asociado o lo mantendr´a. Usuariostemp Se trata de una tabla temporal, usada para verificar los correos de los diferentes usuarios que se registran en el sistema. Cuando un usuario se registra en el sistema, se almacena su email y contrase˜na hasheada en la tabla usuarios. Pero adem´as, tambi´en se almacena aqu´ı su email y su email hasheado y se le manda un email con un enlace para que certifique que el email que ha registrado le pertenece. Consta de tan solo dos campos, los cuales son los siguientes: email: Es la clave primaria, se trata de una clave for´anea que hace referencia al campo email de la tabla usuarios. Es un varchar de 40 caracteres que permite saber qui´en es el usuario que acaba de ser verificado al pulsar sobre el enlace. emailHashed: Se trata de un varchar de longitud 100 en el cual almacenamos el email del usuario hasheado. Permite verificar a qu´e usuario pertenece la cadena de caracteres a la cu´al se acaba de acceder mediante el PHP, para as´ı activar dicho usuario. 5.2. Base de datos SQLite Esta base de datos es utilizada ´unicamente de manera local en la aplicaci´on m´ovil. Gracias a ella se realiza una sesi´on correspondiente al usuario al iniciar sesi´on. La primera vez que el usuario inicia sesi´on en la aplicaci´on se procede a la generaci´on de esta base de datos permanente en el la memoria del dispositivo. De esta forma, cada vez que el usuario abra la app, se inicia la sesi´on directamente obteniendo sus credenciales de la base de datos, logrando as´ı una mejor experiencia de usuario y evitando el repetitivo proceso de iniciar sesi´on cada vez que se inicia la app. Adem´as, cuenta con otros campos en los que se almacenan otros datos que permiten reducir el n´umero de consultas a la base de datos MySQL. Esta sesi´on consta de los siguientes campos: 47 email: Corresponde al email del usuario que est´e registrado en la aplicaci´on en ese m´ovil en ese momento. contrasenia:Se trata de la contrase˜na hasheada para evitar poner en riesgo la cuenta del usuario. estado: Se trata del estado actual del usuario. Estos estados pueden ser ’Descansando’, ’Ocupando puesto’, ’Dentro biblioteca’ o ’Fuera biblioteca’. Estos estados var´ıan seg´un la acci´on que est´e desarrollando el usuario y permiten que se mantengan activas unas u otras funciones en la app. latitud: Corresponde a la latitud del usuario actualmente, medida mediante redes gps. longitud: Corresponde a la longitud del usuario actualmente, medida mediante redes gps. puesto: En esta variable se almacena el puesto ocupado por el usuario actualmente, en el siguiente formato: nombre de la biblioteca + planta de la biblioteca + sitio. Un ejemplo podr´ıa ser: FDI 01 020. inicioEstado: En este campo se almacena la fecha en la que el usuario inici´o su estado actual. Es un campo utilizado para, por ejemplo, determinar el tiempo de descanso disponible por un usuario determinado, como se desarrollar´a m´as adelante. duraci´onAcumulada: Aqu´ı se almacena la duraci´on acumulada, en segundos, que tiene el usuario disponible para poder descansar. planta1: Aqu´ı se almacena el nombre de la primera planta de la Biblioteca de la Facultad de Inform´atica para poder mostrarlo en la app. planta2: Aqu´ı se almacena el nombre de la segunda planta de la Biblioteca de la Facultad de Inform´atica para poder mostrarlo en la app. planta3: Aqu´ı se almacena el nombre de la tercera planta de la Biblioteca de la Facultad de Inform´atica para poder mostrarlo en la app. 5.3. Comunicaci´on entre los modelos de datos Existe una conexi´on entre las dos bases de datos que implementan el proyecto, mediante la cual se intercambian datos para mantener la consistencia y actualizar el sistema a medida que vayan produci´endose acontecimientos. En la Figura 27 se puede observar de manera gr´afica las relaciones entre los algunos de los campos de la base de datos local con los campos de varias tablas de la base de datos del servidor. 48 Figura 27: Diagrama de las relaciones entre las dos bases de datos En todas las conexiones, a excepci´on de una, la base de datos SQLite env´ıa informaci´on relevante al usuario que quiere interactuar con el sistema, ya sea iniciando sesi´on, registr´andose, ocupando un puesto, desocup´andolo o haciendo descansos. En todos estos casos, el servidor recibe el email del usuario junto al resto de datos necesarios para efectuar la operaci´on e inserta o actualiza en las tablas correspondientes el nuevo acontecimiento. Esto resulta imprescindible para mantener la unicidad y consistencia de los datos. La ´unica excepci´on es la relativa a la tabla horarios de la base de datos MySQL. Cada aplicaci´on m´ovil lee de ah´ı el nombre de las plantas de la biblioteca para poder identificarlas dentro de la app. Es el ´unico caso en el que la base de datos SQLite recibe datos para almacenarlos en lugar de enviar los que ya incorporan sus tablas. 49 A continuaci´on se va a describir el dise˜no de la p´agina de iniciar sesi´on. Figura 33: Errores al iniciar sesi´on En la Figura 33 se observan los dos posibles errores que pueden llegar a aparecer, los cuales son: Siglas y/o contrase˜na incorrectos: aparece en caso de que el usuario o la contrase˜na no aparezca en la base de datos. Se ha elegido el color rojo por convenio para que el usuario sepa reconocer que se trata de un error. Este mensaje de error se muestra o se oculta gracias a una funci´on en Javascript. Completa este campo: sale durante unos segundos en el campo que falte por rellenar. ´ Unicamente se comprueba antes de enviar la informaci´on del usuario y la contrase˜na al PHP. En cuanto a los colores, el negro ha sido elegido para el header y el footer, para los botones, una gama de colores rojos (debido al ser el color de la UCM), y para el resto el blanco, que combina visualmente bien con los dos colores anteriores. Por ´ultimo, destacar que el dise˜no de esta p´agina ha sido consensuado para que sea lo m´as simple y sencillo posible, con el objetivo de que el usuario identifique f´acilmente las potencialidades de la p´agina y de darle el menor n´umero de funciones posibles para no sobrecargarle. En este caso solo tendr´ıa que rellenar dos campos. 56 7.1.2. Buz´on de sugerencias Esta funcionalidad proporciona un canal de comunicaci´on entre estudiantes y bibliotecarios. En un vistazo general a la p´agina web se puede ver que el header y el footer se repiten a lo largo de las diferentes p´aginas, con la misma estructura. En este apartado se pueden ver todos los mensajes que la biblioteca ha recibido (en este caso la Biblioteca de la Facultad de Inform´atica), donde cada uno est´a dividido en tres columnas: ‘Respondido’, que indica si se ha respondido o no el mensaje, ‘Fecha’ y ‘Asunto’. A la derecha se encuentra el bot´on ‘Mostrar’, sobre el que se puede clicar para leer el di´alogo que se ha mantenido con el usuario, es decir, los mensajes que se han intercambiado. Es importante saber que no se muestra al bibliotecario la identidad del usuario que mand´o el mail para poder respetar su privacidad. Se ha utilizado el icono de una caja vac´ıa para el caso en el que el mensaje no se ha respondido, y una caja con un check si el mensaje ya ha sido respondido. Se ha definido a 10 el n´umero m´aximo de mensajes a mostrar por p´agina. Figura 34: Buz´on de sugerencias - Aplicaci´on web Al pulsar el bot´on ‘Mostrar’ de un mensaje se abrir´a para poder interactuar con ´el. En el caso de que ya se haya respondido, aparecer´an tanto el mensaje recibido como la respuesta del bibliotecario. En caso caso contrario, el bibliotecario tendr´a la opci´on de responder con un campo en el que se podr´a introducir texto. El recurso utilizado para mostrar el mensaje es un pop-up para poder superponer el mensaje a la lista de mensajes sin tener que redirigir a otra p´agina distinta, disminuyendo la sobrecarga de pesta˜nas al usuario. 57 En las Figuras 35 y 36 se pueden ver dichos ejemplos respectivamente: Figura 35: Buz´on de sugerencias - Contestar mensaje Figura 36: Buz´on de sugerencias - Mensaje ya contestado En lo que respecta a la implementaci´on, en primer lugar se comprueba que el bibliotecario est´e logueado. En caso de que el usuario quiera entrar en esta p´agina sin haber iniciado sesi´on antes, se le redirigir´a directamente a la p´agina de login para que inicie sesi´on. Este es un aspecto que sucede en todas las funcionalidades en las cuales es necesario registrarse. Los mensajes se muestran en la lista en orden de fecha descendente y se establece el l´ımite de mensajes por p´agina a 10. 58 Lo primero que se muestra de los mensajes es si ha sido respondido (si el id de dicho mensaje aparece en dos ocasiones en la base de datos) o est´a pendiente de ello (eso querr´a decir que solo se ha encontrado una coincidencia con el id). Una vez mostrada la fila de cada mensaje se habilita el bot´on ‘Mostrar’, para que se pueda conocer el contenido del mensaje. Al pulsar en dicho bot´on, primero se muestra el mensaje que corresponde a dicho id y luego existen dos posibles caminos: mostrar el mensaje contestado, en caso de que aparezca dos veces el mismo id en la base de datos de la tabla env´ıa, o mostrar un cuadro de texto para poder insertar una nueva fila en dicha tabla si tan solo aparece una. En cuanto al dise˜no, se emplean las cajas de respuesta del mensaje con los iconos de glyphicon, que aportan un dise˜no responsive. Al ser el header y el footer negros, se ha utilizado una gama de colores blanco para no sobrecargar al usuario con colores muy llamativos. 7.1.3. Estad´ısticas Se trata de una funcionalidad para la cual es necesario hacer uso de Highcharts [16], una biblioteca a la que se accede mediante Javascript y con la que se puede especificar el intervalo de tiempo que se quiere consultar. En la Figura 37 se aprecia c´omo se establece la conexi´on con dicha librer´ıa y se configura alguna opci´on del gr´afico como es el selector. Figura 37: Fragmento de c´odigo correspondiente a la generaci´on de la gr´afica Para la obtenci´on de los datos desde la base de datos es necesario hacer una consulta a la misma. La l´ogica de la funcionalidad est´a implementada en estad´ısticas.php de la carpeta que lleva su mismo nombre. En ese fichero se encuentra, entre otras cosas, la query con la que se selecciona del hist´orico la suma total de la duraci´on de los tiempos de estudio y se agrupan por d´ıas: “SELECT ((SUM(duracion) / COUNT(DISTINCT(email))) / 60) as minutosPorEstudiante, DATE FORMAT(fecha inicio,’asd %e- %m- %Y’) as dia FROM ‘historico‘ WHERE estudiando = 1 AND SUBSTRING(puesto, 1, 3) = ’$usuario’ GROUP by DATE FORMAT(fecha inicio, ’ %e- %m- %Y’) ORDER BY DATE FORMAT(fecha inicio, ’ %Y- %m- %d’)” 59 Uno de los principales problemas encontrados en el desarrollo de esta funcionalidad fue el hecho del desarrollo de la query. Como se puede ver, se trata de una consulta bastante compleja, por lo que llev´o un poco de tiempo al equipo de desarrollo dar con la query que satisfaciera todas las condiciones planteadas. Adem´as, como problema a˜nadido a la hora de migrar a la versi´on final, el gr´afico mostraba una l´ınea hacia atr´as desde, por ejemplo, el d´ıa 19 de cada mes hasta el d´ıa 2. Este peque˜no problema era debido a que a la hora de rescatar los datos de la BBDD, no se obten´ıa el 0 delantero de los n´umeros del 1 al 9, por lo que la ordenaci´on no era la adecuada. Por ´ultimo, otro gran problema que surgi´o al pasar al servidor de pago, con unas configuraciones horarias diferentes, fue que el gr´afico de Highcharts no funcionaba, no mostraba nada en pantalla. Finalmente y tras probar varias soluciones, se di´o con la soluci´on correcta, que consisti´o en establecer la zona horaria cuando se generaba el gr´afico a la zona horaria de Madrid mediante la siguiente l´ınea de c´odigo: date default timezone set(’Europe/Madrid’) En lo que concierne al dise˜no, al igual que en el resto de funcionalidades implementadas en la web, se muestra en la parte superior un encabezado en el cual aparecen disponibles todas las funcionalidades implementadas en la p´agina web. Adem´as, aparece el mismo footer que est´a desarrollado para todas las p´aginas una vez se ha iniciado sesi´on. En cuanto al dise˜no propiamente de la parte de las estad´ısticas, se trata de un gr´afico en el cual mediante un selector se puede establecer el rango concreto sobre el que queremos hacer la consulta. Figura 38: Gr´afica estad´ısticas en la web Como se puede apreciar en la Figura 38, en la parte inferior del gr´afico existe un selector corredero que permite ajustar las fechas a consultar. A medida que se establece el rango, el gr´afico se va adaptando din´amicamente, modificando su escala a los datos proporcionados para ese intervalo. 60 7.1.4. Horario Otro de los atractivos que tiene la aplicaci´on web es que el bibliotecario podr´a establecer el horario de su biblioteca y modificarlo las veces que sean necesarias. Incluso existe la posibilidad de asignar horarios diferentes a cada una de las plantas o salas que conforman la biblioteca en el caso de que no lo compartan entre ellas, como ocurre en la biblioteca de la Facultad de Inform´atica. Esta funcionalidad cubre una doble necesidad. Por un lado, en determinadas circunstancias la biblioteca se ve obligada a alterar su horario normal de apertura y/o cierre y necesita que los usuarios que frecuentan las instalaciones conozcan la nueva situaci´on. Puede encontrarse aqu´ı una herramienta id´onea donde actualizar tal informaci´on, que quedar´a reflejada instant´aneamente en la aplicaci´on m´ovil. Gracias a que el horario se establece de manera semanal, resultar´a muy sencillo cambiar ´unicamente el d´ıa o d´ıas que se deseen sin tener que modificar el resto de la semana. Por otro lado, para quien acude a la biblioteca siempre puede existir la duda de qu´e d´ıas y a qu´e hora abr´ıa o cerraba cierta biblioteca. Seleccionar en la app la biblioteca que se quiera consultar y acceder al apartado Horario resolver´a la inc´ognita de manera muy sencilla y r´apida. En lo relativo al dise˜no y estructura, en la Figura 39 se puede el aspecto de este apartado de la web. Figura 39: Establecer horario en la web A esta funcionalidad de la aplicaci´on web se puede acceder a trav´es de la pesta˜na del header en la que se puede leer “Establecer Horario”. Al hacer clic, ser´a redirigido al fichero index.php ubicado en la carpeta horario del ´arbol de directorios. La p´agina est´a dividida en pesta˜nas, correspondi´endose cada una de ellas con las diferentes plantas o salas de las que dispone la biblioteca, mostr´andose en esta imagen la pesta˜na correspondiente a la primera planta. El color rojo de la barra de pesta˜nas indica cu´al est´a seleccionada y se muestra actualmente, pudiendo cambiar entre plantas para asignar los distintos horarios. Como indica el s´ımbolo a la izquierda del nombre de la planta situado bajo la barra, ese nombre puede cambiarse y ser sustituido por el que el bibliotecario considere oportuno. En este caso, al tratarse de la biblioteca de la 61 Facultad de Inform´atica, las plantas est´an identificadas como Primera, Segunda y Tercera, pero si se tratase de la Biblioteca Mar´ıa Zambrano, por ejemplo, las salas podr´ıan llamarse Sala de Filolog´ıa o Sala de Derecho para que los usuarios de la aplicaci´on sepan identificarlas. A la derecha de la barra de tareas se encuentra un bot´on en el que se lee “A˜nadir otra planta”. Al pulsarlo, se generar´a autom´aticamente otra pesta˜na que tendr´a por nombre la palabra “Planta” seguido del n´umero de pesta˜na que le corresponda. Es decir, en la imagen anterior, al pulsar en ese bot´on se a˜nadir´ıa otra pesta˜na con el nombre de “Planta 4”, y quedar´ıa seleccionada y abierta para poder realizar directamente cambios en ella. Si se cambia el nombre de alguna de las plantas, ser´a necesario guardar y refrescar la p´agina para que el cambio quede reflejado en la barra de pesta˜nas. El horario est´a representado por una tabla horizontal que dispone de 8 columnas, 7 de ellas se designan a cada uno de los d´ıas de la semana, y 3 filas, siendo 2 de ellas para indicar la hora de apertura y cierre de la biblioteca. Obviando la primera fila y la primera columna, que son empleadas por los t´ıtulos, el resto de las celdas se corresponden con las horas de apertura y cierre de los diferentes d´ıas de la semana. Cada una de estas celdas la compone un bot´on desplegable en el que aparecen como opci´on, por cada una de las 24 horas del d´ıa, la hora en punto y la media hora. Es decir, al desplegar uno de los botones se puede elegir una hora entre las 00:00, 00:30, 01:00, 01:30, hasta las 23:30, adem´as de dos opciones especiales que tienen por nombre “Cerrado” y “Todo el d´ıa”. Al seleccionar alguna de estas dos opciones como hora de apertura, se selecciona autom´aticamente la misma opci´on como hora de cierre en ese d´ıa y adem´as se deshabilita ese bot´on para que no pueda ser modificado y las horas de apertura y cierren sean coincidentes. En la parte inferior de la tabla se dispone de un bot´on con la palabra “Enviar” con el que se guarda el nuevo horario en la base de datos, cre´andolo si no existe o modific´andolo en otro caso. Cabe destacar que al pulsar este bot´on se guardar´an en la base de datos todas las plantas que existan en la p´agina con sus horas establecidas, no ser´ıa necesario enviar cada planta individualmente, si no que todo funciona como un mismo formulario. Por ´ultimo, cabe destacar la existencia en la parte inferior de la p´agina web de un mapa donde aparece se˜nalada la ubicaci´on de la biblioteca que tiene la sesi´on iniciada en la web, con objeto de comprobar que su localizaci´on en la base de datos es correcta. Tras conocer el dise˜no, se explicar´a ahora c´omo ha sido su implementaci´on. Como ya se ha dicho, este apartado de la web se corresponde con el fichero index.php de la carpeta horario. La primera misi´on de este php es conectarse con la base de datos y comprobar, en la tabla horarios, si ya existe un horario guardado para esta biblioteca. Si es as´ı, se recogen los datos y para posteriormente ir recorri´endolo y pint´andolo. En el caso contrario, se mostrar´a una plantilla para que el encargado de asignarlo lo complete con los datos correctos. Se expondr´a en primer lugar el caso en el que no se encuentren datos sobre esta biblioteca. Lo primero que genera este fichero php es la barra de pesta˜nas en las que se pueden ver las diferentes plantas. Se mostrar´a solamente una, llamada “Planta 1”, que directamente aparecer´a seleccionada en color rojo, y el bot´on “A˜nadir otra planta”. A continuaci´on se crear´a un nuevo elemento <div>cuyo identificador ser´a el nombre de la planta, en este caso “planta1”, y que servir´a para identificar la tabla correspondiente a esta planta. En ´el, se abrir´a un formulario y se comenzar´a a generar, mediante un bucle que recorre todos los d´ıas de la semana, la tabla del horario con cada una de sus opciones, quedando selec62 cionadas por defecto las 09:00 como hora de apertura y las 21:00 como hora de cierre. Requieren especial atenci´on los atributos ‘id’ y ‘name’ de cada una de estas celdas, ya que asignarles un correcto identificador solucion´o un gran problema que surgi´o y que se explicar´a m´as adelante. Para concluir el formulario, se crea el bot´on “Enviar” que transferir´a los datos del formulario a otro fichero ubicado en la misma carpeta llamado “guardarHorario.php”, que insertar´a este horario en la base de datos. Este archivo se encargar´a de recoger los datos que se mandan, contabilizar el n´umero de plantas que se van a ingresar en la base de datos y mediante un bucle que dar´a tantas vueltas como platas haya, recoger´a los datos de cada planta y los insertar´a o reemplazar´a en la tabla ‘horarios’ de la base de datos. Si ya existen datos almacenados para esa biblioteca, antes de generar ning´un elemento HTML se hace una nueva consulta para determinar el n´umero de plantas almacenadas en la base de datos, con el objetivo producir tantas pesta˜nas y tantos bloques como sean necesarios. Se crea la barra y se le asigna a las pesta˜nas el nombre que se lee de la base de datos. Ahora se crean los bloques que se corresponden con las distintas plantas, cada uno con su nombre correspondiente. De la misma manera que en la plantilla, se generan las celdas de la tabla, pero esta vez comprobando qu´e opci´on de los desplegables debe quedar seleccionada. Para ello, se realiza una nueva consulta que devuelve los datos correspondiente a una planta, ya que se consiguen los nombres de las mismas en la consulta anterior. Por cada una, se leen los valores de las horas de apertura y cierre y es el que queda seleccionado al generar las celdas de la tabla, repitiendo este proceso en todas las plantas existentes. Finalmente, tras haber sido creados todos los bloques con su correspondiente tabla, se crea el bot´on “Enviar” y se cierra el formulario, que englobar´a a todas las plantas, quedando cada una de sus variables perfectamente diferenciadas por sus atributos ‘id’ y ‘name’. Al desarrollar todo este proceso surgieron varios problemas, siendo dos los m´as importantes: uno fue c´omo hacer para que un mismo bot´on sirviera para enviar los datos de distintos formularios y otro diferenciar las horas de apertura y cierre de las distintas plantas. La soluci´on del primero fue simplemente agrupar todas las plantas en un ´unico formulario, cada una contenida en un elemento <div>y con las variables diferenciadas. Esta soluci´on, que parece tan sencilla, no se pens´o desde el primer momento debido a que las diferentes plantas estaban siendo interpretadas como elementos completamente independientes, pero cuando se comprendi´o bien que aunque los bloques est´en ocultos siguen siendo parte de la web, incluidas sus variables, se colocaron todos dentro de un ´unico formulario, quedando as´ı englobadas por un ´unico bot´on. Esto lleva al segundo problema, saber c´omo diferenciar las diferentes variables de cada una de las plantas, es decir, c´omo diferenciar el valor correspondiente a, por ejemplo, la hora que abr´ıa el lunes la planta 1 y la planta 2. Dado que la forma de identificar cada una de las variables de un formulario pasa por consultar su atributo ‘name’, la soluci´on era darle un identificador ´unico y que fuese lo suficientemente claro, el cual fue “numeroDePlanta diaDeLaSemana abre” para la hora de apertura y “numeroDePlanta diaDeLaSemana cierra” para la hora de cierre. De manera similar se hizo para el ‘id’. Por ejemplo, para la hora de apertura del lunes de la planta 1, el ‘name’ de su variable era “1 Lunes abre”. Por ´ultimo, es de menci´on c´omo funciona la barra de pesta˜nas de las distintas plantas. Su correcto funcionamiento es posible gracias a dos funciones, una en Javascript llamada “abrirPlanta” para mostrar las diferentes plantas y otra en jQuery encargada de a˜nadir una nueva al pulsar en el bot´on correspondiente. La primera buscar´a el bloque <div>que tenga como identificador el nombre de la planta que aparece en la pesta˜na que pulsada, lo har´a visible, ocultar´a el bloque de la pesta˜na que se estaba mostrando y pondr´a la pesta˜na seleccionada de color rojo. La segunda de ellas es m´as compleja, ya que tiene que generar una nueva pesta˜na, un nuevo bloque y nombrar cada uno de sus elementos correctamente para identificarlos individualmente 63 de manera inequ´ıvoca. El procedimiento pasa por clonar el <div>de la primera planta, para posteriormente cambiar todos sus atributos y valores. El nombre y el id se conseguir´a averiguando cu´al es el n´umero de la nueva planta, contabilizando las ya creadas. Se le asigna ese nombre y se coloca justo encima del bot´on “Enviar”. Lo siguiente es renombrar el ‘id’ y ‘name’ de todas las variables del formulario de la manera explicada anteriormente, y dejar seleccionadas las horas que se definieron en la plantilla. Por ´ultimo, se crea la nueva pesta˜na en la barra, con el nombre adecuado, y se hace clic mediante una funci´on Javascript para que se abra autom´aticamente tras haber pulsado en “A˜nadir otra planta”. 7.1.5. Cerrar sesi´on Como se coment´o previamente en este cap´ıtulo, algunas de las carpetas en las que se divide la web no presentan ninguna interfaz gr´afica, tan solo ejecutan una funcionalidad. Cerrar sesi´on es una de ellas. Se trata de una funcionalidad presente siempre en el lateral derecho del encabezado que permite cerrar la sesi´on iniciada en la web. Se le ha asignado ese emplazamiento siguiendo el patr´on Sign-In tools, el cual dice que es una forma de situar al usuario en la p´agina web y que si quiere realizar la funci´on de cerrar sesi´on la encontrar´a r´apidamente, debido a que est´a acostumbrado a tener esa opci´on en el mismo sitio en la mayor´ıa de portales web. Para cerrar sesi´on, una vez se pulsa sobre dicha opci´on, se desenlazan todos las variables de la sesi´on con session unset() y se destruye la sesi´on con session destroy(). Una vez realizado esto, se redirige a la p´agina principal, en la que existe la posibilidad de volver a loguearse. 7.1.6. Qui´enes somos Esta p´agina, presente en el pie de p´agina, es la huella, marca o presentaci´on de los integrantes y desarrolladores de la web. Al acceder a ella, se observa una p´agina sencilla pero elegante en la que aparecen el nombre, los apellidos y la foto de cada uno de los tres estudiantes desarrolladores del presente Trabajo de Fin de Grado. Es una p´agina a la cual se puede acceder indistintamente de haber iniciado sesi´on, no requiere de ninguna contrase˜na ni usuario para ser accesible como s´ı que ocurre con la mayor´ıa de p´aginas restantes. 7.1.7. Header El encabezado es un elemento que est´a siempre presente en la web. A la hora de realizarlo, se pens´o c´omo hacer que fuera intuitivo, r´apido y, sobre todo f´acil, de usar. Tras barajar varias opciones, se determin´o que, puesto que las funciones que iban a estar disponibles en la p´agina web eran, a grandes rasgos, cuatro, lo ideal ser´ıa que estuvieran todas a la vista del usuario, sin tener que navegar por complejos men´us para encontrarlas. As´ı pues, se estableci´o un header que contase con las cuatro funcionalidades principales: buz´on de sugerencias, estad´ısticas, establecer horario y cerrar sesi´on. En el centro de las cuatro opciones, puesto que de momento la ´unica biblioteca implementada es la de la Facultad de Inform´atica de la UCM, se decidi´o colocar el escudo de la Universidad Complutense de Madrid. Se trata de un header responsive, que se adapta perfectamente a las diferentes dimensiones de pantalla y a dispositivos m´oviles. En cuanto al dise˜no, se opt´o por el color negro, con los iconos de Material Design de color blanco para darle un estilo sobrio y elegante. Al pasar el mouse sobre cada uno de los elementos del encabezado, se remarca en un color gris claro, poniendo el icono de color negro para as´ı ofrecer al usuario informaci´on clara de qu´e opci´on es en la que va a pulsar. 64 Preside el encabezado (v´ease Figura 40) el escudo de la UCM sobre una circunferencia de color rojo. Figura 40: Encabezado con la sesi´on iniciada No tendr´ıa sentido que las cuatro opciones del encabezado se mostraran cuando la sesi´on no est´a iniciada. En ese caso (como ocurre por ejemplo en la pesta˜na de iniciar sesi´on), las opciones desaparecen quedando tan solo el escudo de la UCM, como se puede apreciar en la Figura 41 siguiente. Figura 41: Encabezado sin haber iniciado sesi´on 7.1.8. Footer De igual modo que en el caso del header, se trata de un elemento que se encuentra siempre presente en la p´agina web. A la hora de dise˜narlo, se han incluido las diferentes opciones que deben estar disponibles a cualquier usuario que accediese a la web, independientemente de que estuviera logueado o no. Adem´as, es necesario que sea muy visual, intuitivo y amigable. Es por ello por lo que se apost´o por el dise˜no actual y se decidi´o incluir todas esas opciones. Se ha cre´ıdo necesario que cualquier usuario que acceda a la web pueda informarse sobre qui´enes son los desarrolladores del proyecto y pudiese descargar la app m´ovil, que es la parte del proyecto que est´a destinada al gran p´ublico. Por eso ha sido creado un grupo de opciones llamado Explorar en el que se enuentran estas dos opciones: Qui´enes somos y Descargar app. Descargar app se trata de un enlace a Play Store donde se puede descargar la app m´ovil Biblioteko. Tras este grupo de opciones aparece otro, denominado Comenzar, en el cual est˜na la opci´on Iniciar sesi´on, que redirige a la p´agina de login. Esta es la ´unica parte del footer que difiere seg´un se haya iniciado sesi´on o no, ya que no tiene sentido que haya un enlace a iniciar sesi´on si ya est´a iniciada. Por ´ultimo, a la derecha, est´a la parte en la que los usuarios pueden comunicarse con los desarrolladores. Es ah´ı donde aparecen los tres iconos de las redes sociales en las cu´ales existen perfiles creados y activos (Twitter, Facebook e Instagram). Adem´as, existe un bot´on Cont´actanos mediante el cual, al pulsarlo, se le abre al usuario su programa de correo para que pueda enviar un correo electr´onico al equipo desarrollador. En lo que respecta al dise˜no, se ha optado por el mismo color negro que en el encabezado, para as´ı dar homogeneidad a la p´agina y un aspecto serio. A la izquierda del pie de p´agina se encuentra el escudo de la Universidad Complutense de Madrid, al igual que en el encabezado sobre un fondo rojo. Hacia la derecha podemos apreciar los dos grupos de opciones comentados anteriormente. Al pasar por encima de alguna de las opciones, ´esta se resaltar´a en un blanco m´as intenso. Por ´ultimo, a la derecha del todo, se ubican los enlaces de las redes sociales y un bot´on en color rojo, que que destaca del resto, para que los usuarios puedan contactar con 65 7.2.2. Iniciar sesi´on Ser´a la primera pantalla al iniciar la aplicaci´on en el m´ovil. Tendr´a la apariencia que se observa en la Figura 49. Figura 49: Inicio de sesi´on en Android El primer requisito indispensable para poder iniciar sesi´on es estar registrado, adem´as de haber activado el usuario. Si a´un no se ha hecho, podr´a hacerse pulsando en el enlace inferior. El formulario para iniciar sesi´on dispone tan solo de dos campos, el email y la contrase˜na. En caso de no completar alguno de ellos se notifica al usuario el error con un mensaje que dice “Completa todos los campos”. Del mismo modo ocurre en el caso de que no exista el usuario en la base de datos o la contrase˜na no sea la correcta. Si el proceso resulta satisfactorio, se realizar´a un intent (lanzamiento as´ıncrono de una nueva actividad) a la p´agina de bibliotecas. 72 (a) Error por campos vac´ıos (b) Credenciales incorrectas Figura 50: Error al iniciar sesi´on en la app En cuanto a la disposici´on de los elementos se ha optado por colocar el logo de la aplicaci´on en el centro de la p´agina y los dos campos para el inicio de la sesi´on. Como se puede observar en las diferentes figura de este apartado, una vez clicas en un campo la letra del rotulo disminuye de tama˜no, se sit´ua en la parte superior y cambia la raya del campo de color blanco a negro, dando feedback instant´aneo al usuario de que el campo est´a seleccionado. Todos los elementos est´an anclados al centro de la imagen para poder hacer un buen reajustado de ellos en las diferentes dimensiones que tienen las pantallas de los dispositivos Android. En el encabezado est´a indicado el t´ıtulo de la actividad actual para guiar al usuario cuando se desplace por las diferentes pantallas de la aplicaci´on (en este caso Iniciar sesi´on). El enlace a la pantalla de registro est´a subrayado para aumentar su visibilidad y darle aspecto de enlace. En cuanto a la implementaci´on, esta tarea se trata de un Activity, debido a que tiene una vista XML asociada, como se puede ver en la carpeta ‘layouts’. En este layout se han utilizado recursos como un editText personalizado para dar la funci´on de minimizar la letra y poder introducir texto y un button para el bot´on, adem´as de un TextView para indicar el enlace a Registro y un ImageView para insertar el logo. El archivo Java correspondiente a esta actividad tiene el nombre de MainActivity. Una vez se haya cargado la vista se esperar´a a que el usuario haya completado los campos y pulse el bot´on, entonces se recoger´an las credenciales introducidas y se ejecutar´a un m´etodo as´ıncrono para poder contactar con la base de datos. Dicha clase heredar´a de AsyncTask, que ofrece varios m´etodos. En la Figura 51 se muestra un fragmento del c´odigo de dicha clase, con 73 uno de los m´etodos implementados, y la llamada al php que realiza la comprobaci´on del usuario. Figura 51: Fragmento de c´odigo de Iniciar Sesi´on En el PHP al que se accede mediante el AsyncTask conseguiremos el usuario y la contrase˜na (hasheada, para no poner en peligro al usuario), y despu´es se comprobar´a en la base de datos del servidor la existencia de ese usuario, que la contrase˜na introducida es correcta y sea un usuario activado. El PHP devolver´a a la clase java un objeto JSON en el que se podr´a saber si la operaci´on se ha efectuado con ´exito, y se notificar´a al usuario, con un TextView, en el caso de que el usuario no haya sido activado o haya errores en las credenciales introducidas. En caso de que no haya dichos errores se pasar´a a la siguiente pantalla de la app y quedar´a guardada la sesi´on en la base de datos SQLite, para que cuando se abra la aplicaci´on de nuevo, el usuario no tenga que volver a iniciar sesi´on, ofreciendo de esta manera ventajas considerables de tiempo y usabilidad. 74 7.2.3. Registrar Esta funcionalidad permite crear una cuenta a los usuarios que a´un no lo hayan hecho. Tan solo se han de rellenar 3 campos, el correo electr´onico y la contrase˜na, que ser´a introducida dos veces para que si se comete alguna equivocaci´on al escribirla, el usuario no se registre con una contrase˜na err´onea. A continuaci´on podemos ver como ser´ıa la pantalla de registrar, en la figura 52. Figura 52: Registro en Android La ´unica restricci´on que habr´a es que la contrase˜na debe tener como m´ınimo de 8 caracteres incluyendo letras y n´umeros, haciendo as´ı que la contrase˜na sea segura. Ambas contrase˜nas deber´an coincidir. Tambi´en se asegura que el usuario ha elegido un usuario que no existe en la base de datos. A continuaci´on, en la Figura 53 se ven los posibles errores que podr´ıan darse. 75 (a) Email no v´alido (b) Contrase˜na demasiado d´ebil (c) Contrase˜nas no coinciden Figura 53: Posibles errores en el registro En cuanto al dise˜no empleado, se ha elegido los mismos colores y la misma disposici´on que en iniciar sesi´on, promoviendo as´ı una familiaridad con el usuario respecto a las diferentes pantallas. Se podr´a volver a la pantalla de inicio sesi´on mediante el link que aparece en la parte inferior, para que no se produzca el denominado “callej´on sin salida en las pantallas”. Para la implementaci´on de dicha actividad, se ha realizado un archivo XML definido en la carpeta ‘layouts’ definido para esta vista, basado en editText, button y textView. La clase Java donde se ha implementado esta actividad es Registro. Como en la anterior secci´on, tambi´en se comienza por cargar la vista y esperar a que se rellenen los campos. Una vez rellenos y pulsado el bot´on de registrar, se lanza una clase as´ıncrona que conectar´a con la base de datos. Se recuperar´a el email y la contrase˜na y se llamar´a al PHP de registrar, el cu´al esperar´a dichos campos. Una vez recibidos, comprobar´a que no el email no exist´ıa anteriormente en la base de datos y lo insertar´a junto con la contrase˜na en la tabla usuarios. Ser´a justo aqu´ı donde se env´ıe por correo al usuario un mensaje de activaci´on para que pueda activar su cuenta. El correo que recibir´a ser´a como el que aparece en la Figura 54. Figura 54: Mensaje para activar el usuario 76 Al clicar en dicho link, aparecer´a la confirmaci´on de que se ha activado la cuenta del usuario, se dar´a de alta en la tabla de usuarios, y se podr´a iniciar sesi´on con total normalidad. 7.2.4. Bibliotecas En esta pantalla se muestran las bibliotecas implementadas en la aplicaci´on y se podr´a elegir cualquiera de ellas (como ya se sabe, por ahora la ´unica implementada es la de la Facultad de Inform´atica). Tendr´a la funci´on de home o pantalla principal ya que, tras iniciar sesi´on por primera vez, no volvr´a a aparecer la pantalla de login si no que se redirigir´a directamente a esta pantalla, la pantalla de bibliotecas. Adem´as, es la pantalla a la que se volver´a si, estando en cualquiera de las opciones disponibles dentro de cada una de las bibliotecas, se pulsa el bot´on atr´as. Como se aprecia en la siguiente captura, se trata de una pantalla bastante sencilla en la que se ofrecen todas las bibliotecas disponibles en la app con su direcci´on y su logo. El resto se encuentran en este ListView a modo de ejemplo para mostrar c´omo se ver´ıa cuando estuvieran m´as bibliotecas implementadas. A pesar de tan solo contar con una biblioteca, el proyecto se ha desarrollado para permitir la implementaci´on de otras bibliotecas. Adem´as, est´a realizado de un modo que su implementaci´on resulte sencilla, siendo lo m´as costoso el dise˜no y esquema de las diferentes salas de la nueva biblioteca a implementar. Tal como se puede apreciar en la Figura 55, este es el dise˜no que tiene dicha pantalla. Figura 55: Pantalla de selecci´on de biblioteca en Android Una vez pulsada la biblioteca deseada, en este caso la de la Facultad de Inform´atica, se redirigir´a a la pantalla de la planta principal de la biblioteca. En el caso de la biblioteca de 77 la FDI, se ha determinado que la planta principal es la planta 1, puesto que es ah´ı donde se encuentra el mostrador de pr´estamo. Por tanto, tras pulsar ah´ı se nos mostrar´a la primera planta de la biblioteca con sus puestos libres y ocupados. 7.2.5. Plantas Una vez se seleccione una biblioteca, se acceder´a al mapa de la biblioteca en cuesti´on. En este proyecto se ha implementado la de la Facultad de Ingenier´ıa Inform´atica, por lo que aparecer´a una representaci´on real de la disposici´on de los sitios y las mesas de la primera planta. A la izquierda de la pantalla, oculto y accesible a trav´es de un bot´on en el encabezado o deslizando la pantalla hacia la derecha, se encuentra el men´u principal citado anteriormente, a trav´es del cual se podr´a acceder a las diversas funciones implementadas. Esta funcionalidad est´a implementada en ´el, ya que si el usuario se encuentra en otra p´agina, como por ejemplo estad´ısticas, y quiere volver a plantas, puede pulsar en esa funci´on para volver a ver el mapa de la biblioteca. En cuanto al dise˜no de este apartado en el men´u, se ha tratado de utilizar un icono representativo, el cual son tres l´aminas superpuestas que aparentan ser las plantas de un edificio y que se ha obtenido de Material Design. En la esquina inferior derecha de la pantalla se aprecia un bot´on flotante que permite seleccionar la planta que se quiere consultar (habiendo 3 plantas en total). Este bot´on contiene el mismo icono de las tres l´aminas utilizado en el men´u. Al pulsar en ´el se despliegan tres botones que identifican a cada una de las plantas, pudiendo pulsar en cualquiera de ellos para elegir una de las tres, como se puede apreciar en la Figura 56. Figura 56: Bot´on flotante desplegado 78 Los puestos son representados en la aplicaci´on mediante cuadrados, agrup´andose de la manera que mejor convenga para representar las mesas de cada planta. El estado de cada uno de ellos se indica mediante diferentes colores, como se explica a continuaci´on. Aunque de manera minimalista, cada planta se ha intentado representar con la mayor fidelidad posible respecto a la distribuci´on real que presentan en la biblioteca de la facultad. La interfaz posee elementos como PUERTA o MOSTRADOR para poder orientar y situar al usuario de manera que f´acilmente pueda identificar y relacionar los puestos de la aplicaci´on con el que le corresponde a cada uno en la planta real. Los colores elegidos para indicar el estado de los puestos han sido el verde para un puesto que se encuentra libre, el color rojo para se˜nalar que el sitio est´a ocupado por otro estudiante, el color azul que indica que ese es el puesto que est´a ocupando el usuario y el naranja para el puesto que est´a ocupando el usuario mientras realiza un descanso. A continuaci´on, en la Figura 57 vamos a observar las diferentes plantas, con puestos ocupados y libres, pero sin que el usuario actual haya ocupado ning´un sitio. (a) Planta 1 (b) Planta 2 (c) Planta 3 Figura 57: Vista de las plantas de la Biblioteca FDI 79 En la Figura 58 se observa c´omo aparece un puesto ocupado por un usuario y el mensaje en el que se le notifica que se ha ocupado correctamente. Figura 58: Usuario estudiando 80 Si el usuario, realiza un descanso mientras tiene un puesto ocupado, el color de su puesto cambiar´a de azul a naranja (v´ease Figura 59). Figura 59: Usuario descansando La elecci´on de dichos colores tan distintos tiene el prop´osito de que los usuarios diferencien con facilidad los diferentes estados, a la vez de ayudar en la medida de lo posible a aquellos usuarios que puedan sufrir daltonismo. El color del fondo es un blanco ligeramente rojizo que combina con la paleta de colores utilizada. El prop´osito de que sea blanco es no distraer la atenci´on del usuario y que toda su atenci´on vaya dirigida a las mesas y puestos de las plantas. Es destacable que existen distintos archivos XML para cada una de las plantas, estando dirigido cada uno de ellos a las diferentes dimensiones de las pantallas de los dispositivos m´oviles. Para cada tama˜no y resoluci´on se muestra la vista correspondiente, consiguiendo as´ı que no se descuadren los sitios en distintos dispositivos. La implementaci´on es similar en las 3 plantas. En cada una, los puestos son im´agenes cuadradas que se agrupan para formar mesas y son envueltos por un bot´on transparente que cubre todos los sitios de una determinada mesa. La intenci´on de este bot´on es evitar la dificultad que tendr´ıa pulsar sobre un puesto de peque˜no tama˜no y que est´a rodeado por otros botones, pues la imprecisi´on en el toque ser´ıa alta. Para pulsar en un puesto se pulsar´a sobre toda la mesa, que se expandir´a (iniciando la actividad Mesa) y permitir´a seleccionar de manera mucho m´as sencilla un puesto en concreto. 81 do (en modo “OCUPANDO PUESTO”), y esto servir´a m´as adelante para poder establecer el tiempo de descanso y para insertar una nueva fila en la tabla hist´orico de la base de datos del servidor. Por ´ultimo, se observa un toast que dice que se ha podido ocupar el puesto correctamente. Si el resultado obtenido en el JSON no ha sido favorable, se muestra por pantalla cu´al ha sido el causante del error, que se identifica por el valor entero que contiene. Tras finalizar todo este proceso, se volver´a directamente a la planta en la que se encuentra el puesto que se ha tratado de ocupar. Si ha sido posible se mostrar´a en azul, gracias al m´etodo onResume implementado en cada una de las plantas. Si no ha sido as´ı, el puesto permanecer´a en el estado en el que se encontraba. 7.2.8. Vaciar puesto Esta funcionalidad aparecer´a en el men´u lateral una vez el usuario haya ocupado un puesto. Para hacerlo ha debido de pasar las restricciones como se ha visto en el cap´ıtulo anterior. En caso de no haber ocupado un puesto, no se mostrar´a al usuario esta funcionalidad, ya que ser´ıa un error, porque no puede liberar un puesto que no posee. A continuaci´on, en la Figura 66, se puede ver c´omo se muestra el men´u, sin haber ocupado un puesto. Figura 66: Men´u de Android sin haber ocupado un puesto 88 Al ocupar un puesto, aparecer´an autom´aticamente en el men´u dos nuevas opciones (v´ease Figura 67), hacer descanso yliberar puesto. Esta secci´on se centra en liberar puesto y la desarrollar´a en profundidad, la otra opci´on se ver´a en la secci´on siguiente. Figura 67: Men´u de Android tras ocupar un puesto Para liberar un puesto, no solo se puede hacer desde el men´u, si no que tambi´en es posible ir a la mesa en la que estamos ocupando el puesto y clicar en el sitio ocupado. En ese caso saldr´a la misma alerta que si se hubiese dado a liberar puesto en el men´u. Se preguntar´a si se desea confirmar dicha operaci´on, y se liberar´a el puesto correctamente. Este cuadro de confirmaci´on, que se puede ver a continuaci´on, est´a implementado para confirmar con el usuario que es esa operaci´on la que quiere realizar, ya que si desocupa el puesto perder´a su tiempo acumulado para descansar. Es por tanto necesario asegurarse (v´ease Figura 68) de que el usuario le ha dado a prop´osito y que quiere terminar su estudio. 89 Figura 68: Mensaje de confirmaci´on de liberar puesto El icono del men´u pertenece a Material Design. Se dispone de la imagen en diferentes tama˜nos, colores y resoluciones, para que se pueda ajustar a los distintos m´oviles. Al igual que en el resto de aspectos de la interfaz, todos los iconos de las funciones tienen la misma tonalidad de color, para as´ı poder mantener una misma gama de color y homogeneidad. Se ha pretendido que el icono sea representativo y se asemeja a la opci´on de liberar, para representar que el usuario quiere abandonar el puesto, haciendo que sea intuitivo con tan solo con ver el dibujo. En cuanto a la implementaci´on de dicha funcionalidad, se acopl´o una fila m´as en el men´u del XML (se puede ver en el archivo activity biblioteca fdiplanta1 drawer.xml). Por otro lado, en cada Java en los que aparece el listener de cada bot´on del men´u, se a˜nadi´o la funcionalidad de liberar puesto (v´ease Figura 69). Figura 69: Fragmento de c´odigo - Listener liberar puesto 90 Y para poder ocultar dicha funci´on se ha utilizado la funci´on itemLiberar.setChecked(false), donde itemLiberar se refiere al bot´on de liberar puesto, y con esto se oculta dicho apartado del men´u. Si el usuario de la sesi´on tiene ocupado un puesto se habilita haciendo el opuesto de dicha funci´on (es decir, poni´endolo a true). A continuaci´on, en la Figura 70, vemos el c´odigo que realiza dicha funci´on. Figura 70: Fragmento de c´odigo - Habilitar opciones Una vez hayamos clicado en desocupar el puesto haremos un intent al Java de VaciarPuesto. En ´el, a partir de la sesi´on del usuario, conseguiremos el puesto que est´a ocupando y el usuario en cuesti´on, la fecha de inicio del estado y el tiempo que ha estado estudiando. Con todo eso se conecta con el PHP para, en primer lugar, eliminar dicha fila de la tabla ocupa y as´ı que se muestre desocupado el sitio en el mapa, y para, posteriormente, actualizar el hist´orico y as´ı a˜nadir nueva informaci´on del tiempo de estudio de dicho usuario a sus estad´ısticas personales y globales. Una vez hecho esto se reinicia el estado del usuario a “FUERA BIBLIOTECA”, hasta que consiga de nuevo la ubicaci´on del usuario y comience de nuevo el ciclo de estados del usuario. 91 7.2.9. Hacer descanso/Finalizar descanso Ambas funciones aparecer´an (una u otra), una vez el usuario haya ocupado un sitio, como se ha visto en el capitulo anterior. Est´a dise˜nada e implementada de la misma manera que antes, es decir, se ha a˜nadido a los XML una nueva fila en la que aparece “Hacer descanso” o “Finalizar descanso”, cuando la sesi´on del usuario marque un puesto ocupado. En caso de no tener puesto no aparecer´a dicha opci´on. En la Figura 66 de la secci´on anterior se puede observar como no aparece ninguna de estas opciones si no se est´a ocupando un puesto, mientras que en la Figura 67 se ve que tras haberlo ocupado, se ha a˜nadido la opci´on “Hacer descanso”. En cambio, aparecer´a la opci´on “Finalizar descanso” si est´a realizando un descanso, como se aprecia en la Figura 71. Figura 71: Men´u con usuario descansando En el caso de que se ocupase un puesto y se est´e estudiando, si se llevaran unos 22 minutos estudiando y se quisiera realizar un descanso (para tomar un caf´e, por ejemplo), se le puede dar a esa opci´on del men´u. En ese momento (v´ease Figura 72) saldr´a el tiempo acumulado estudiando (en este caso 22 minutos que se puede desocupar el puesto sin perderlo). 92 Figura 72: Mensaje que avisa sobre tiempo de descanso disponible Autom´aticamente, el puesto cambiar´a de azul a naranja, para indicar que se est´a descansando. 93 Si se sobrepasa este tiempo de descanso, se liberar´a el puesto autom´aticamente si el usuario se encuentra fuera de la biblioteca, o volver´a a mostrarse ocupado si se encuentra dentro. Pero para que el usuario sepa cu´anto tiempo le queda antes de que finalice su descanso, saldr´a una notificaci´on (v´ease Figura 73) 3 minutos antes de que acabe su tiempo de descanso disponible advirti´endole de ello. (a) Notificaci´on en la barra de estado (b) Notificaci´on flotante Figura 73: Mensaje de 3 minutos restantes para fin de descanso 94 Si se pulsa en “Finalizar descanso” antes de que este termine, se acumular´a el tiempo sobrante para el siguiente descanso y se le informar´a de cu´al es ese tiempo acumulado mediante un mensaje en la pantalla (v´ease Figura 74). Figura 74: Mensaje que avisa sobre tiempo acumulado para el siguiente descanso 95 Se puede dar la situaci´on en la que el usuario se encuentre dentro de la biblioteca ocupando un puesto y sin hacer un descanso ni liberar el puesto salga de ella. Ante esto, se pasa directamente su estado a “DESCANSANDO” para que no pierda su sitio, comenzando la cuenta atr´as de su tiempo de descanso disponible. Se le notificar´a esta situaci´on y se le da la opci´on de liberar su puesto, para evitar tener un puesto ocupado por nadie si su intenci´on es abandonar la biblioteca definitivamente (v´ease Figura 75). (a) Notificaci´on en la barra de estado (b) Notificaci´on flotante Figura 75: Notificaci´on ‘Has salido’ 96 En el caso de que el usuario se encuentre descansando fuera de la biblioteca y se detecte que vuelve a entrar a ella tambi´en se lo notificar´a para que, si quiere volver al estudio, finalice el descanso y acumule de esta manera el tiempo de descanso que le ha sobrado (v´ease Figura 76). (a) Notificaci´on en la barra de estado (b) Notificaci´on flotante Figura 76: Notificaci´on ‘Has vuelto’ En cuanto al dise˜no de estas dos nuevas filas del men´u, han sido implementadas de igual forma que en la secci´on anterior, por lo que no se explicar´a de nuevo. En cuanto al Java, para poder desarrollar todas las funciones, se ha implementado la clase Descansar, la cu´al ser´a llamada una vez el usuario haya clicado en la funci´on de “Hacer descanso” o “Finalizar descanso”. Se obtendr´a el email del usuario de la sesi´on junto al tiempo que ha estado estudiando/descansando y comprobaremos su estado para as´ı determinar si antes estaba estudiando y ahora quiere realizar el descanso o por lo contrario, si estaba descansando y ahora va a seguir estudiando. Se ver´a el primer lugar el caso en el que el usuario est´a estudiando y quiere realizar un descanso. Su estado cambiar´a a “DESCANSANDO”, se actualizar´a su tiempo de descanso acumulado, que ser´a la diferencia del momento actual con el momento en el que inici´o el estudio, y se iniciar´a una alarma que saltar´a 3 minutos antes de que termine el descanso y lo volver´a a hacer cuando finalice totalmente. Este hecho se puede apreciar en la Figura 77. 97 Figura 84: Horario En cuanto a la implementaci´on es muy similar a estad´ısticas, ya que se establece una conexi´on con la base de datos para obtener el horario de la biblioteca. Esta informaci´on se env´ıa a la clase Horario para que se muestre. Los cambios que se produzcan en la biblioteca por parte del bibliotecario, tanto de cambio en el nombre de las plantas como el horarios de apertura o cierre, se ver´an reflejados tambi´en aqu´ı. Al igual que en las secciones anteriores, se hace uso de tabs o pesta˜nas para poder separar los horarios de las diferentes plantas. 104 7.2.13. Modificar contrase˜na Si el usuario desea modificar su contrase˜na podr´a hacerlo con esta funcionalidad. Esta funci´on, junto con Cerrar sesi´on, pertenece a un apartado del men´u lateral llamado perfil. Se realiza el mismo proceso descrito en las anteriores secciones para incorporar esta funci´on la men´u. A continuaci´on, en la Figura 85 se muestra lo que ver´ıa el usuario al clicar en dicho apartado. Figura 85: Modificar contrase˜na 105 Como se puede observar, habr´a tres campos referidos todos ellos a las contrase˜nas. Primero se debe escribir la contrase˜na actual del usuario para asegurar que no ha entrado alguien en la aplicaci´on que no sea el propio usuario y que quiera cambiar su contrase˜na, para quedarse ´el con la cuenta. En caso de no ser correcta se har´a saber al usuario (v´ease Figura 86). Figura 86: Modificar contrase˜na - Contrase˜na incorrecta 106 A continuaci´on se le pedir´a que ingrese la nueva contrase˜na, la cu´al deber´a tener una longitud de 8 caracteres incluyendo letras y n´umeros (la misma condici´on que cuando un usuario nuevo se registra). En caso de no cumplir con dicha restricci´on, se le har´a saber al usuario con la siguiente alerta (v´ease Figura 87). Figura 87: Modificar contrase˜na - Contrase˜na no segura 107 Si se cumplen estos requisitos adem´as de coincidir los dos campos en los que hay que introducir la nueva contrase˜na, se modificar´a la contrase˜na. En otro caso, le aparecer´a el mensaje de la Figura 88. Figura 88: Modificar contrase˜na - Las contrase˜nas no coinciden Como se observa, se han comprobado todos los posibles casos de fraude hacia la cuenta de un usuario, comprobando que el usuario es realmente ´el antes de cambiar su contrase˜na. Adem´as, con la doble verificaci´on de la nueva contrase˜na es perfectamente consciente de cu´al es la nueva contrase˜na a utilizar. En cuanto a la l´ogica, se puede observar en ’modificarContrasenia.java’. Despu´es de conseguir las contrase˜nas, se comprueba que las dos contrase˜nas nuevas sean iguales y que respetan la restricci´on de los 8 caracteres con n´umeros y letras. A continuaci´on, se hashean para mantener la privacidad del usuario y evitar vulnerabilidades. Se env´ıan al PHP donde se comprueba en primer lugar que la contrase˜na a cambiar coincide con la de la base de datos de ese usuario para, posteriormente, actualizar la fila de ese usuario cambiando su contrase˜na por la nueva. Despu´es de realizar esta funci´on, al volver a iniciar sesi´on, como es l´ogico, no ser´a v´alida la contrase˜na que ten´ıamos anteriormente, ´unicamente la que se ha introducido como nueva. 108 7.2.14. Cerrar sesi´on Esta funci´on se encargar´a de cerrar la sesi´on actual. Adem´as, tambi´en parar´a la alarma implementada encargada de mantener la conexi´on con la base de datos y el usuario y y se detendr´a el service de ubicaci´on que determina la ubicaci´on del dispositivo. Una vez cerrada la sesi´on, se redirigir´a a la p´agina de Iniciar sesi´on. En este caso, no se mostrar´a ninguna pantalla adicional para no sobrecargar al usuario, tan solo se mostrar´a un dialogo de alerta (v´ease Figura 89) para que el usuario est´e convencido de que quiere cerrar su sesi´on. Figura 89: Di´alogo de cerrar sesi´on La implementaci´on de esta funci´on es simple, ya que al llamar a esta funci´on se elimina la sesi´on activa de la base de datos SQLite y se detienen las alarmas actuales. Adem´as, si el usuario ten´ıa un puesto ocupado, se liberar´a el puesto llamando a VaciarPuesto. En la Figura 90 se puede ver un fragmento de c´odigo donde se realiza la destrucci´on de la sesi´on y la detenci´on de las alarmas. 109 Figura 90: Fragmento de c´odigo - Cerrar sesi´on 7.2.15. Ay´udanos a mejorar Como funci´on extra para la aplicaci´on, se ha realizado un formulario de Google con el que se pretende conseguir un feedback directo de los destinatarios finales de la aplicaci´on. En ´el se pueden encontrar preguntas como “¿Entiendes bien qu´e es Biblioteko y para qu´e sirve?”, “¿Qu´e te parece que haya un tiempo de descanso m´aximo de 30 minutos?” o “¿Utilizar´ıas esta aplicaci´on?” entre otras. Esta funci´on se encuentra en el men´u lateral de la aplicaci´on, dentro de una secci´on llamada Sugerencias. Al clicar en dicho apartado aparece un peque˜no texto en el que se explica qui´en ha desarrollado la aplicaci´on y se pide a los usuarios que rellenen el formulario al que se puede acceder pulsando en la imagen que aparece bajo el texto (v´ease Figura 91). Figura 91: Formulario ay´udanos 110 Las respuestas recibidas por los usuarios ser´an analizadas en el siguiente cap´ıtulo y en el apartado de conclusiones. Se estudiar´an las posibles correcciones propuestas por los mismos y se propondr´an las correspondientes soluciones a partir de las necesidades de los usuarios. 7.2.16. Service Ubicaci´on Uno de los platos fuertes de la aplicaci´on es el uso de la ubicaci´on GPS del dispositivo para ubicar al usuario en el interior o exterior del recinto de las bibliotecas. Como ya se explic´o, la intenci´on de este proyecto es gestionar la ocupaci´on de los puestos de estudio de la biblioteca, de manera que un puesto solamente aparezca ocupado si realmente el usuario se encuentra en ´el, a excepci´on del tiempo en el que se le permite estar fuera descansando. El objetivo de esta condici´on es que no haya puestos desocupados, todo puesto en el que no haya alguien sentado debe aparecer como libre en la aplicaci´on, optimizando as´ı la ocupaci´on de las bibliotecas y su aprovechamiento por parte de los estudiantes. Esto supone un gran reto, ya que es necesario saber d´onde se encuentra el usuario de la app en cada momento. Y para esto se hace uso de la se˜nal GPS que pr´acticamente todos los dispositivos Android incorporan y que tantas posibilidades de explotaci´on tiene. La intenci´on inicial era que la aplicaci´on pudiera detectar ´unicamente con la se˜nal GPS en qu´e puesto de la biblioteca se encontraba el usuario. R´apidamente se tuvo que desechar esta idea al comprobar que, a pesar de lo mucho que ha avanzado esta tecnolog´ıa en los ´ultimos a˜nos, la imprecisi´on de este m´etodo era, para este prop´osito, tremendamente elevada. Se barajaron otras posibilidades y tras varias propuestas, la opci´on que parec´ıa id´onea para solucionar el problema fue la que definitivamente ha quedado implementada. La aplicaci´on detecta cu´ando ha habido un cambio en la ubicaci´on del dispositivo y comprueba, cada vez que esto ocurre, si se encuentra en el interior o en el exterior de alguna de las bibliotecas implementadas. La soluci´on para saber qu´e puesto est´a ocupando o quiere ocupar el usuario no es tan automatizada como se pretend´ıa, pero es altamente efectiva. Cuando un estudiante quiera ocupar un puesto, debe abrir la aplicaci´on e indicar manualmente cu´al es el puesto exacto en el que se sentar´a, y se proceder´a a realizar la acci´on tal y como se explica en las secciones Mesa y Ocupar Puesto. Este es, en detalle, el proceso para obtener la ubicaci´on del dispositivo. Antes de nada, y acorde con el sistema de seguridad que implementa Android en todos sus dispositivos, es imprescindible que el usuario acepte los permisos de ubicaci´on de la aplicaci´on. Esto autorizar´a a la app a acceder a la ubicaci´on del dispositivo. Sin este permiso, la aplicaci´on no podr´a funcionar correctamente. La ubicaci´on se conoce gracias a la ejecuci´on ininterrumpida de un service. En Android, un service es un componente sin interfaz gr´afica que se ejecuta en segundo plano y puede hacer todo tipo de operaciones. La app lo utiliza como m´etodo de tratamiento de los cambios en la ubicaci´on del dispositivo. Se lanza este service en el momento en el que el usuario inicia sesi´on y selecciona una biblioteca. Desde entonces, se ejecuta en segundo plano y se controla que nunca se detenga, o que si lo hace, sea autom´aticamente lanzado de nuevo sin tener que realizar ninguna acci´on, independientemente de que la aplicaci´on est´e abierta o cerrada. Incluso si el dispositivo se apagara, al volverse a encender se iniciar´ıa de nuevo por s´ı solo. De este modo, aunque el usuario reinicie su dispositivo y no vuelva a abrir la app se podr´a seguir comprobando si se encuentra dentro o fuera de la biblioteca. Cabe destacar que la ubicaci´on tan solo queda almacenada en la base de datos SQLite incorporada en el dispositivo, en ning´un caso se almacena en el servi111 dor ni existe forma de saber cu´al es la ubicaci´on de un usuario, todo queda gestionado localmente. Este service es el que se encarga de gestionar el ciclo de estados del usuario, adem´as de las clases OcuparPuesto, VaciarPuesto, Descansar, CerrarSesion, Alarma y AlarmaEstoyVivo. Los posibles estados que puede adoptar un usuario son los siguientes: “FUERA BIBLIOTECA”, que indica que no se encuentra en niguna biblioteca, “DENTRO”, el usuario est´a dentro de una biblioteca pero sin ocupar ning´un puesto (´unicamente se comprueba la Biblioteca de la Facultad de Inform´atica por ser, de momento, la ´unica implementada), “OCUPANDO PUESTO”, el usuario tiene un puesto ocupado, y “DESCANSANDO”, tiene un puesto ocupado pero est´a en su tiempo de descanso. Al crear el service, se inicializa un objeto de la clase Polygon (una clase Java que junto a las clases Line y Point, todas de c´odigo abierto y licencia libre, conforman el algoritmo PIP[19] que permite saber si un punto est´a contenido en un pol´ıgono) con las coordenadas de la biblioteca de la facultad, que ser´a el que permita saber si el usuario se encuentra dentro o fuera de la misma. Tambi´en en su creaci´on se establece un listener de la ubicaci´on del dispositivo que el sistema Android proporciona, y en el m´etodo onLocationChanged, el principal de esta clase, es donde se gestiona el estado en funci´on de la nueva ubicaci´on. Tras varias comprobaciones, se ha detectado que la precisi´on con la que el dispositivo capta nuevas ubicaciones puede ser extremadamente variada, del orden de 15 hasta 700, y tan solo las que ten´ıan una precisi´on inferior a 20 localizaban el dispositivo con la exactitud necesaria, de modo que son solo estas las que se aceptan c´omo v´alidas. Una vez se percibe una ubicaci´on lo suficientemente precisa, se actualiza la base de datos local con la ubicaci´on recibida m´as recientemente y se comprueba si la misma se encuentra contenida en el pol´ıgono que se cre´o anteriormente. Si lo est´a, se realizan una serie de comprobaciones para actualizar, si fuese necesario, el estado del usuario, adem´as de otras acciones complementarias. En el caso de que el estado del usuario fuese “FUERA BIBLIOTECA”, se actualiza el estado a “DENTRO” y se lanza una notificaci´on (v´ease Figura 92) en la que se le sugiere que si va a ocupar un puesto lo indique en la app. El otro caso a tener en cuenta en esta situaci´on es cuando estaba descansando y su anterior ubicaci´on era fuera de la biblioteca (lo que se consigue saber comprobando si la ´ultima ubicaci´on que conoc´ıamos est´a o no dentro del pol´ıgono). Si esto ocurre, estaba descansando fuera y entra en la biblioteca, se le muestra otra notificaci´on (v´ease Figura 93) en la que se le invita a finalizar su descanso para que acumule el tiempo que le sobra, si es que realmente desea finalizarlo, aunque esto no se hace autom´aticamente. 112 (a) Notificaci´on en la barra de estado (b) Notificaci´on flotante Figura 92: Notificaci´on al entrar en la biblioteca (a) Notificaci´on en la barra de estado (b) Notificaci´on flotante Figura 93: Notificaci´on al volver del descanso 113 Como se puede apreciar, lo primero que hace es insertar en un puesto temporal llamado TGlobalXXX donde XXX son las siglas de la biblioteca la suma total del tiempo que ha estado estudiando o descansando ese usuario agrupado por a˜nos. Es importante tener en cuenta que solo se van a agrupar datos anteriores al a˜no, pues se considera importante conocer al detalle los momentos de estudio del ´ultimo a˜no. Una vez hecho esto, se borran los datos de los puestos XXXglobal, puesto que ya est´an incluidos esos datos en el puesto temporal TGlobalXXX. Tras esto, se eliminan todos los registros anteriores al a˜no que sean diferentes de TGlobalXXX para as´ı realizar la limpieza propiamente dicha de los puestos ocupados. Una vez hecho esto, se insertan los datos de los puestos TGlobalXXX en XXXglobal, poniendo como fecha el d´ıa 1 de enero de cada a˜no, a las 00:00:00 si se corresponde con descansando y a las 00:00:01 si se corresponde con estudiando. Por ´ultimo, borramos los puestos TGlobal puesto que, como ya se ha mencionado, se trata de un puesto temporal. En cuanto al otro tipo de CRON implementado, tiene la misi´on de gestionar la conexi´on entre la aplicaci´on y la base de datos. Con esto se asegura que no se ha perdido la conexi´on. Por ejemplo, si el usuario de la aplicaci´on m´ovil ha reservado un puesto de estudio, y a continuaci´on apaga el m´ovil, se deja de tener contacto con ´el y no se podr´ıa liberar su puesto. Este fue uno de los problemas que surgieron sobre c´omo gestionar las conexiones con el usuario y ver si estaba con el m´ovil encendido, y que se consigui´o resolver finalmente gracias a dicho m´etodo. En un principio no fue la opci´on que se plante´o para resolverlo. Antes de ella, se estuvo pensando en c´omo hacerlo y, tras investigar, vimos que tal vez se pod´ıa hacer con Firebase. Sin embargo, tras probar e investigar un poco con todas las opciones que hab´ıa disponibles, se observ´o que no era exactamente lo que se buscaba. Tras seguir durante un par de d´ıas d´andole vueltas a c´omo resolverlo, un d´ıa surgi´o la feliz idea de que fuera el servidor el encargado de comprobar y gestionar peri´odicamente las conexiones con los diferentes dispositivos activos. Para ello, una vez el usuario inicie sesi´on, enviar´a un mensaje al servidor que almacenar´a a ese usuario como ’vivo’ en una tabla junto a la ´ultima vez que le ha llegado una prueba de dispositivo vivo. Una vez ocupado el puesto y cada 15 minutos, siempre que la ubicaci´on permanezca activada, el dispositivo volver´a a mandar una nueva prueba de vida. Paralelamente, cada 5 minutos se produce la ejecuci´on de un CRON Job que verifica si los dispositivos presentes en la tabla usuariosActivos cumplen la condici´on de estar vivos (esto es que su ´ultima informaci´on recibida haya sido recibida hace como mucho 20 minutos). De no estar vivos, el PHP act´ua en consecuencia liberando el puesto. As´ı se asegura que si al usuario se le ha acabado la bater´ıa del m´ovil y ten´ıa un sitio reservado pero se va a ir de la biblioteca, si no se vuelve a tener respuesta de dicho estudiante, se desocupa el sitio en este periodo de tiempo. Con esto se consigue que los sitios que est´an ocupados en la biblioteca sean reales, y, en segundo lugar, que si alg´un estudiante quiere hacer trampas, ocupando indefinidamente un sitio en la biblioteca, se elimine esta posibilidad. 120 En cuanto a la implementaci´on, se basa en un c´odigo PHP, que se puede observar en la Figura 102. Figura 102: PHP lanzado por el CRON Job que gestiona las conexiones vivas Y que se puede traducir a nivel usuario, como: en primer lugar seleccionar el email de todos los usuariosActivos cuya ´ultima informaci´on es de hace m´as de 20 minutos y establecer aquellos sitios de la tabla puestos que est´en ocupados por esos usuarios a 0 (sitios desocupados). Adem´as, se borran todos los usuarios de los que no hemos recibido informaci´on en los ´ultimos 20 minutos de la tabla ocupa y por ´ultimo se eliminan tambi´en de la tabla usuariosActivos. Gracias a este servidor se ha podido implementar esta funcionalidad, la cu´al en el anterior gratuito no se dispon´ıa de tal posibilidad y que ha aportado al proyecto un control sobre la aplicaci´on. Otra gran funcionalidad que ha propiciado el hecho de migrar a un servidor de pago ha sido la posibilidad de poder mandar correos autom´aticamente. Pr´acticamente, desde el primer momento se vio necesario que los usuarios verificaran sus correos para evitar que cualquiera se pudiera registrar en la app incluso con un correo inexistente. Se estuvo pensando c´omo conseguir esto y buscando ideas para lograrlo. Un buen d´ıa, tras finalizar una de las clases surgi´o la soluci´on que hemos implementado finalmente. En primer lugar, se deb´ıa a˜nadir un campo a la tabla usuarios, un campo booleano activado que nos permitiese saber si ese usuario hab´ıa sido activado o no para permitirle o negarle el acceso a la aplicaci´on. Adem´as, se cre´o otra tabla, usuariostemp, en la cual se almacena el email de cada usuario que se registra y su email hasheado. Una vez hecho esto, se genera un email que se manda al usuario que se acaba de registrar en el cual se encuentra un enlace con el emailHasheado para que active su usuario. Si al acceder al enlace, el emailHasheado coincide con uno de los emailHasheados de la tabla usuariostemp, se produce la activaci´on que del email que corresponde a dicho emailHasheado en la tabla usuarios y se elimina la entrada de usuariosTemp. Todo esto se realiza en el PHP que se puede observar en la Figura 103. 121 Figura 103: PHP que activa un usuario determinado Tras esto, se consigui´o solucionar el problema de c´omo activar los usuarios. Ahora bien, quedaba el hecho de que el correo se enviase autom´aticamente. Para ello, se encontr´o finalmente una clase PHP, PHPMailer, en internet que permit´ıa generar los correos en el mismo momento en el que el usuario se registraba. Se descarg´o la clase, se configur´o y se prob´o, y funcionaba a la perfecci´on. El problema lleg´o al hacer la migraci´on al servidor gratuito. Se encontr´o el problema de que los puertos para el env´ıo de correos estaban capados y, a pesar de realizarse la inserci´on del usuario correctamente en las dos tablas, el correo no se enviaba. Se consult´o de nuevo con el equipo de soporte e indicaron que al tratarse de un servidor gratuito no estaba permitido el env´ıo masivo y autom´atico de correos. As´ı pues, tras barajar varias opciones se decidi´o pasar al actual servidor, con el cual se volvi´o a recuperar la funcionalidad de enviar correos. La otra base de datos utilizada ha sido una base de datos interna SQLite que guardar´a los datos relativos al propietario de la aplicaci´on. Se tuvo que investigar sobre como crear una base de datos interna y de como mantener la sesi´on de un usuario a lo largo del uso de la aplicaci´on. Se descubri´o que hay muchas variaciones para guardar la informaci´on, como tarjetas SD, ficheros, etc. Se ha preferido guardar la informaci´on en una base de datos, para poder preservar la privacidad del usuario, entre otros aspectos. Como se puede ver en la implementaci´on, para poder trabajar con SQLite en Android Studio se ha creado una carpeta llamada SQlite, con dos clases Java: SQLiteHelper: clase utilizada para gestionar la base de datos, en la que se crea la base de datos interna (sesion). Usada en su apertura y cierre, as´ı como para facilitar su gesti´on en el ciclo de vida de las actividades. Utilizar´a los siguientes m´etodos: onCreate yonUpgrade, utilizados para la creaci´on y la destrucci´on de la sesi´on activa en ese momento. 122 Control Sesion: utilizada para crear la sesi´on. Esta clase se llamar´a en la p´agina principal, una vez que el usuario haya iniciado la sesi´on. Tendr´a m´etodos como crearUsuario que crear´a una sesi´on a partir del nombre, estado, la ubicaci´on... Y m´etodos para seleccionar, a˜nadir, actualizar o insertar un usuario selectSesion, insertarSesion, updateSesion, borrarSesion. A continuaci´on, en la Figura 104 se puede ver un fragmento de c´odigo de ejemplo de como se inserta una sesi´on: Figura 104: Fragmento de c´odigo que inserta una sesi´on en SQLite Para finalizar esta secci´on, se va a hablar de la implicaci´on en las redes sociales sobre la aplicaci´on. Se ha creado un usuario en Instagram, Twitter, y Facebook, con la misi´on de dar a conocer el proyecto a nivel de la facultad y de la Universidad Complutense de Madrid, para incentivar a la gente a que pruebe la aplicaci´on, y que as´ı sirva de ayuda para mejorarla y corregirla de fallos o funciones/dise˜no que puedan no gustar. Cabe recordar que la misi´on principal al iniciar este proyecto era que la gente lo pudiera usar en la biblioteca, por lo que hab´ıa que asegurarse de su correcto funcionamiento. 123 8. Evaluaci´on de usuarios y pruebas Cuando se comenz´o la realizaci´on de este proyecto, el objetivo era llegar a tener finalizada la app para el 11 de mayo para que as´ı estuviera disponible para los ex´amenes y poder conseguir el feedback de los estudiantes. Sin embargo, el feedback de los usuarios no solo se ha obtenido tras finalizar la aplicaci´on, si no que ha estado presente en varias fases, que son las siguientes. 8.1. Inicio del proyecto En un inicio, se cont´o con la opini´on de de una de las bibliotecarias de la facultad para la versi´on web, puesto que es m´as relevante su opini´on en este caso que la de estudiantes que ni siquiera van a tener acceso a la p´agina web. As´ı pues, los principales aspectos que fueron mencionados por ella son que deb´ıa tratarse de una web sencilla y muy intuitiva para que todas las bibliotecarias pudieran adaptarse r´apidamente a la utilizaci´on de la misma. Adem´as, destac´o que ser´ıa muy ´util que estuvieran presentes funciones como poder establecer el horario, para evitar tener que poner un cartel a mano en el que se reflejase el horario. Para la versi´on m´ovil, se opt´o por ense˜nar un prototipo de la aplicaci´on y ver c´omo era el comportamiento de los estudiantes con ella. Tras ver sus reacciones y escuchar sus opiniones, se procedi´o a modificar algunos aspectos del prototipo inicial. Una de los aspectos modificados tras esta prueba inicial fue el hecho de implementar la posibilidad de liberar el puesto tanto desde el mismo puesto como desde una nueva opci´on incluida en el men´u desplegable si exist´ıa un puesto ya seleccionado. Otro aspecto criticado por los usuarios en este prototipo y cuyo cambio se ha visto reflejado en la versi´on final ha sido el color del fondo. Gran n´umero de los encuestados resaltaron que el color azul era demasiado intenso. Es por ello que en la versi´on final se ha establecido un color blanco ligeramente rojizo, para no desentonar con la paleta de colores de la UCM. 8.2. Durante el proyecto Tras la realizaci´on de la primera iteraci´on de la aplicaci´on m´ovil, se procedi´o a la realizaci´on de la evaluaci´on de los usuarios. En dicha evaluaci´on no se produjo ninguna cr´ıtica rese˜nable por lo que se procedi´o a continuar con la segunda iteraci´on. En la tercera evaluaci´on realizada a los usuarios tras la segunda iteraci´on s´ı que se obtuvieron resultados relevantes. De igual modo que en la primera evaluaci´on, los colores utilizados para representar los puestos libres y ocupados no fueron del agrado de los estudiantes, quienes criticaron el hecho de que fueran demasiado llamativos para el ojo humano. As´ı pues, finalmente se decidi´o implementar con unos colores de los propuestos por Material Design, presentes en multitud de aplicaciones desarrolladas en Android. 8.3. Tras el proyecto Uno de los principales errores m´as reportados por los usuarios tras haber publicado la aplicaci´on en Google Play fue el hecho de que, en las primeras versiones, la app se bloqueaba y se cerraba continuamente. Una vez le´ıdos los informes de Google Play Console, se consigui´o establecer un patr´on com´un en todos los m´oviles afectados por este fallo. Se trataba de un error que afectaba a m´oviles que no dispon´ıan de Android puro, con capas de personalizaci´on como las de Xiaomi, Samsung o LG. 124 Este error fue solucionado tras un per´ıodo de investigaci´on sobre posibles soluciones y se public´o la nueva versi´on actualizada en Google Play que solventaba la problem´atica. La soluci´on implementada consiste en a˜nadir intentProblematico.addFlags(Intent.FLAG ACTIVITY NEW TASK antes de lanzar determinados ’intent’. En la Figura 105 se puede observar, como se ha ido reduciendo el n´umero de bloqueos de la aplicaci´on a medida que han ido pasando los d´ıas y nuevas versiones que solventaban bugs iban siendo actualizadas en Google Play. Es por tanto que la aplicaci´on m´ovil ha sido testeada en casi todo tipo de m´oviles, con diferentes versiones (desde 5.0 a 8.1), y diferentes tama˜nos y resoluciones de pantalla. Figura 105: Gr´afica que muestra el n´umero de bloqueos diarios de la app Otro de los aspectos que se ha podido perfeccionar en la app tras lanzarla al mercado y ponerla al servicio de los estudiantes ha sido el hecho de determinar correctamente si un usuario est´a dentro de la biblioteca o no. Tras observar que la tabla ocupa daba informaci´on de un puesto ocupado por un usuario a unas horas en las que era imposible que lo estuviera se determin´o que exist´ıa un problema en el caso de desactivar la ubicaci´on una vez el puesto hab´ıa sido ocupado. En ese caso, el puesto quedaba ocupado sin importar si el usuario abandonaba la biblioteca o no hasta que se activase la ubicaci´on. Se trataba de un fallo muy grave que permit´ıa a los estudiantes descansar ilimitadamente. Es por ello que fue solventado r´apidamente, a˜nadiendo una condici´on nueva a la alarmaEstoyVivo. La nueva condici´on implementada consiste en que el usuario debe tener la ubicaci´on activada para que se produzca el env´ıo de dicha se˜nal. En caso contrario, el puesto del usuario es liberado. Existen disponibles varias v´ıas de comunicaci´on para que los usuarios se pongan en contacto con los desarrolladores del proyecto. Tales v´ıas son cualquiera de los perfiles del proyecto en redes sociales (Twitter, Instagram y Facebook) las cuales son actualizadas diariamente, correo electr´onico y, por supuesto, el boca a boca. Adem´as, existe un cuestionario [20] del que ya se ha hablado previamente disponible en la app para que los usuarios dejen su opini´on. Hasta la 125 fecha de hoy se han registrado 31 respuestas, las cu´ales se anexar´an a continuaci´on. Figura 106: Pregunta : ¿Entiendes bien qu´e es Biblioteko y para qu´e sirve? Como se puede apreciar en la Figura 106, m´as del 80 % de los encuestados entienden qu´e es Biblioteko y para qu´e sirve, frente al 19’4 % que dice no entenderlo. Se trata de una pregunta clave para el inicio y el n´umero de descargas y desinstalaciones de la aplicaci´on, puesto que de ser este n´umero muy elevado, la aplicaci´on no permanecer´a en los dispositivos de los usuarios, ya que desconocen su funcionamiento. Figura 107: Pregunta : ¿Recuerdas alg´un momento en el que te hubiese sido ´util conocer la ocupaci´on actual de la biblioteca? 126 En la Figura 107 se puede observar que, tan solo algo menos del 13 % de los estudiantes afirman no haber necesitado nunca conocer la ocupaci´on en un determinado instante. Es por ello que se puede determinar que Biblioteko viene a ocupar un gran hueco existente en lo que a gesti´on de puestos de bibliotecas se refiere, ya que se trata de algo que hubiera sido ´util para la mayor´ıa de los estudiantes en alg´un momento de sus vidas. Figura 108: Pregunta : ¿Cu´ando crees que ser´ıa ´util saber qu´e puestos est´an libres? En la Figura 108 existe pr´acticamente un 85 % de los encuestados que considera que s´ı que ser´ıa ´util conocer la disponibilidad de puestos de la biblioteca, frente a poco m´as de un 15 % que no lo considera necesario. Del 85 % que s´ı lo consideran, casi un 58 % considera que ser´ıa ´util siempre mientras que el 42 % lo ver´ıa ´util principalmente en ´epoca de ex´amenes, cuando las bibliotecas presentan mayor afluencia. Figura 109: Pregunta : ¿Qu´e te parece que haya un tiempo de descanso m´aximo de 30 minutos? 127 Nota aclaratoria con respecto a la Figura 109: Tras la publicaci´on del cuestionario, se advirti´o de la existencia de una errata, por lo que se subsan´o y hay que mencionar que la opci´on morada y la naranja son la misma. Ante esta pregunta, poco mas del 15 % de los encuestados consideran que el tiempo de descanso deber´ıa ser libre, frente al 67’7 % que piensan que 30 minutos est´a genial. Adem´as, hay un 9’7 % que lo considera insuficiente y un 6’5 % al que le parece demasiado. Figura 110: Pregunta : ¿Tienes claro cu´ales son las funciones de Biblioteko? En la Figura 110 se puede observar como una abrumadora mayor´ıa, superior al 80 % dice tener claras las funciones de la aplicaci´on. Algo m´as del 9 % dice no tener claro qu´e es lo que puede hacer ni c´omo hacerlo mientras que es la misma cantidad de encuestados la que es m´as tajante y afirma no saber lo qu´e puede hacer y lo qu´e no. Figura 111: Pregunta : ¿Te resulta f´acil utilizar la app? En la Figura 111 se observa que a casi el 85 % de los encuestados le resulta f´acil utilizar la app. De todos ellos, pr´acticamente un 85 % la encuentran simple de usar mientras que el 15 % restante considera que podr´ıa ser m´as clara. Por otra parte, existen un 9’7 % de los encuestados a los que no les parece del todo sencilla y tan solo un 6’4 % a los que les parece complicada. 128 Figura 112: Pregunta : ¿Has encontrado alg´un fallo en la aplicaci´on? En la Figura 112 se aprecia que tan solo un usuario ha reportado un error, en este caso una sugerencia. Inicialmente no se desarroll´o la funcionalidad Cerrar sesi´on para evitar que a trav´es de un mismo dispositivo se pudiera iniciar sesi´on en varias cuentas y ocupar m´as de un puesto, pero este problema de seguridad se subsan´o con la implantaci´on de la Alarma Estoy Vivo y su correspondiente CRON de conexiones vivas explicados anteriormente, por lo que esto ya no supon´ıa ning´un riesgo para el uso de la aplicaci´on. Por lo tanto, se consider´o muy ´util esta respuesta y se incorpor´o la citada funcionalidad gracias a la aportaci´on de uno de los usuarios. Figura 113: Pregunta : ¿Consideras ´util esta aplicaci´on? La Figura 113 supone un gran impulso para la aplicaci´on ya que en ella se puede apreciar como casi el 85 % de los encuestados consideran ´util esta aplicaci´on. De ellos, m´as del 88 % consideran que la aplicaci´on facilita sus d´ıas de estudio mientras que el resto consideran que es ´util en algunas ocasiones. Son tan solo poco m´as del 15 % de los encuestados los que no ven ninguna ventaja en la aplicaci´on. 129 Despu´es de tener experiencia en la programaci´on en estos dispositivos m´oviles, comenzamos los tres miembros del grupo a la realizaci´on de iniciar sesi´on y registrase. Trabaj´abamos en paralelo los tres, investigando y desarrollando dicha pagina. Gracias a los aportes de todos los miembros conseguimos realizar estas p´aginas y tras esto reunimos mucha experiencia. A continuaci´on, ten´ıamos que elegir entre realizar las p´aginas de estad´ısticas, buz´on de sugerencias,u horarios que ofrec´ıan una menor dificultad, o comenzar con la p´agina de plantas ya que era la p´agina m´as importante del proyecto. Elegimos comenzar con la p´agina de plantas, que a pesar de su dificultad, al no tener demasiada experiencia, nos importante comenzar con esta parte por si acaso no hubi´eramos tenido tiempo suficiente de realizar las dem´as p´aginas. Para comenzar a desarrollar dicha pantalla, primero realizamos una reuni´on los tres miembros junto con el director, para poder pensar como podr´ıamos implementar el dise˜no de las mesas y los puestos de la biblioteca. Aporte al igual que el resto de mis compa˜neros ideas de como realizarlo. Hasta que se nos ocurri´o realizarlo con botones, cada puesto de estudio. Fueron muchas reuniones las que hicimos los tres miembros para poder realizar dicha pantalla, hasta que conseguimos realizarla trabajando tanto los tres juntos presenciales, como cada uno en paralelo. A continuaci´on tuvimos que pensar como poder conocer la ubicaci´on de un usuario cada cierto periodo de tiempo, para determinar si se haya o no en la biblioteca. Para ello realizamos varias reuniones con el director y tras varios aportes tanto mio, como del resto de los miembros tuvimos la idea de utilizar un Service, para obtenerla cada cierto tiempo. Esta fue el periodo m´as costoso y en la que nos encontr´abamos mas perdidos a la hora de saber como solucionarlo, pero gracias a esa idea pudimos solventarla. Un vez terminamos la p´agina de las pantallas, nos dividimos las funciones que quedaban, y que para seguir el orden normal que hab´ıamos llevado en la aplicaci´on web, me asign´e el buz´on de sugerencias de la aplicaci´on m´ovil. El proceso fue el mismo, primero me centr´e en el dise˜no tanto del buz´on de entrada como de enviar mensajes, una vez termine de implementar dicho dise˜no, hicimos una reuni´on para hablar posibles modificaciones en cuanto a colores, estilos... Tras cambiar dichos aspectos, implement´e la l´ogica del buz´on de sugerencias como fueron el desarrollo de los eventos, inserci´on actualizaci´on en la base de datos, entre otras funciones. Tras acabar esta funci´on juntamos las funciones que nos hab´ıamos asignado y realic´e junto con el resto de mis compa˜neros, las peque˜nas funciones que quedaban como por ejemplo, modificar contrase˜na o cerrar sesi´on. Cuando acabamos todas las funciones lanzamos a Play Store para que la aplicaci´on fuese probada y corregimos los peque˜nos errores que hab´ıa. Por ´ultimo he colaborad como el resto del grupo, en la realizaci´on de la memoria, asign´andonos diferentes cap´ıtulos, y luego leyendo y modificando las redacciones de quien lo hab´ıa hecho desde un primer momento. Por lo que cada cap´ıtulo que aparece ha sido hecho y le´ıdo por los tres integrantes del grupo. 136 9.4.2. David Gorricho San Juan Al igual que el resto de mis compa˜neros, he colaborado en muchas partes del proyecto, investigando en multitud de tecnolog´ıas, y aportando, al igual que el resto de los integrantes del grupo, el m´aximo rendimiento posible. Cuando comenzamos el proyecto, por el mes de octubre, lo primero que hicimos fue plantear c´omo desarrollar el tema que desde el primer momento propusimos. Nos sentamos los tres junto a nuestro director y, partiendo desde la idea inicial que ten´ıamos, pensamos en qu´e cosas se pod´ıan implementar f´acilmente y que sab´ıamos c´omo desarrollarlas, y cu´ales eran las que ve´ıamos que pod´ıamos desarrollar pero que para ello deber´ıamos aprender nuevas tecnolog´ıas y recurso. Una vez tuvimos la idea de c´omo quer´ıamos desarrollar el proyecto, qu´e funciones extra iban a aparecer y c´omo iba a ser mostrado al usuario, nos dispusimos a realizar los bocetos correspondientes de las diferentes pantallas y funcionalidades que habr´ıa en las aplicaciones. Tras tener realizados tanto yo como mis compa˜neros del grupo los bocetos repartidos en bloques, los pasamos a formato digital mediante un programa de generaci´on de bocetos. A medida que una nueva pantalla era realizada, acord´abamos una nueva reuni´on para estar todos de acuerdo en c´omo hab´ıa quedado finalmente desarrollada dicha pantalla y qu´e funciones y c´omo hab´ıan sido implementadas. Una vez finalizado el trabajo anterior me dispuse a obtener, al igual que el resto de mis compa˜neros, informaci´on y feedback de los posibles usuarios de la aplicaci´on. En un primer momento, obtuve opini´on del c´ırculo m´as cercano (novia, padres y familia) para despu´es acabar recibiendo Feedback tambi´en del grupo de amigos y estudiantes de la facultad. Tras obtener este Feedback, tuvo lugar una reuni´on en la que compartimos impresiones sobre las opiniones que hab´ıamos recolectado previamente. Consideramos cu´ales de ellas eran m´as relevantes y nos repartimos los diferentes aspectos a modificar por recomendaci´on de los usuarios. Adem´as, una vez estos cambios fueron realizados, nos centramos todos juntos en la creaci´on de la p´agina web. Tras un d´ıa entero en la facultad que sirvi´o para sentar las bases, dise˜no y distribuci´on final de la p´agina web, nos repartimos las funcionalidades a desarrollar de la misma, para as´ı poder ir avanzando en paralelo. En mi caso, decid´ı encargarme de la parte de estad´ısticas. En lo que concierne a esta parte, he de destacar que la implementaci´on no fue f´acil. Quer´ıa que se tratase de una funcionalidad que aportase la mayor cantidad de informaci´on a los bibliotecarios y para ello precisaba de una implementaci´on que les permitiese modificar din´amicamente el rango de fechas a consultar. Finalmente, tras una profunda investigaci´on por la red di con el recurso que necesitaba, Highcharts. Adem´as, era necesario desarrollar una query que permitiese recopilar todos los datos que era necesario mostrar en la gr´afica. Tras alg´un que otro problema, gracias a la experiencia adquirida durante estos a˜nos en MySQL logr´e dar con la query que obtuviese de la base de datos todo ello. Finalizada ya la funcionalidad de estad´ısticas, realic´e la funcionalidad web de limpiar base de datos, funcionalidad que, como ya se ha mencionado, finalmente no ha sido implementada en la web si no que se ha optado por automatizar. En un principio la automatic´e con el planificador de eventos de MySQL pero finalmente la realic´e mediante un CRON Job, debido a la restricci´on 137 existente en los servidores de la red con el planificador de eventos de MySQL. Otra de los aspectos en los que m´as he trabajado, adem´as de en la implementaci´on de la automatizaci´on de tareas mediante CRON Jobs, ha sido en la generaci´on, implementaci´on y desarrollo de los PHP. Despu´es de juntar estas funciones con el resto de mis compa˜neros, realizamos una reuni´on para asegurarnos de que no faltaba ninguna funcionalidad y poder empezar a desarrollar la aplicaci´on m´ovil. A continuaci´on empec´e a ver tutoriales, junto al resto de mis compa˜neros, y gu´ıas de c´omo desarrollar aplicaciones Android, debido a que no ten´ıamos ninguna experiencia en este aspecto. Uno de los miembros del grupo, Iv´an, s´ı que ten´ıa experiencia en el tema puesto que hab´ıa estado matriculado en una asignatura de aplicaciones Android y fue el que nos gui´o en estos compases iniciales. Tras este proceso de aprendizaje, empezamos los tres miembros del equipo a implementar las primeras pantallas de la aplicaci´on, es decir iniciar sesi´on y registrarse. Hicimos varias reuniones todos juntos para poder realizarlas, a la vez que busc´abamos informaci´on y trabaj´abamos en paralelo para poder conseguir que funcionasen las pantallas. Fue bastante costoso el inicio, puesto que ninguno de nosotros ten´ıa experiencia anterior a este tipo de proyectos. Una vez conseguimos terminar estas pantallas, decidimos en una reuni´on realizar la pantalla de plantas, donde se muestra el estado de la biblioteca actual. Acordamos una reuni´on los miembros del equipo con el director del proyecto e hicimos una lluvia de ideas de c´omo poder desarrollar e implementar dicha funcionalidad. Tras dicha reuni´on, decidimos implementar los puestos mediante botones. Debido a que era esta pantalla de la aplicaci´on donde se encontraba la principal funcionalidad del proyecto, decidimos realizarla juntos, haciendo reuniones presenciales casi todos los d´ıas. Adem´as, los d´ıas que no nos encontr´abamos personalmente, cada integrante del grupo dedicaba tiempo individual para buscar recursos o tecnolog´ıas que ayudasen. Tras el dise˜no de las diferentes plantas, tuvimos que investigar c´omo implementar el tema de la ubicaci´on y conseguir cada cierto per´ıodo de tiempo la obtenci´on de la misma. Una vez implementamos la funcionalidad principal del proyecto, nos aseguramos de su funcionamiento y dise˜no, nos repartimos las funcionalidades sobrantes. En mi caso me encargu´e de estad´ısticas, ya que fue esta parte tambi´en la que realic´e en la p´agina web, de modo que, a priori, me ser´ıa m´as f´acil implementarla a m´ı. Sin embargo, no muchas veces lo que se espera en teor´ıa es lo que acaba ocurriendo en realidad y esta fue una de ellas. Para empezar, solo una query de la parte web sirvi´o para la implementaci´on de esta funcionalidad en la parte m´ovil y. Por ello, me dispuse a realizar el resto de queries que permitiesen obtener la informaci´on necesaria de la base de datos. Una vez estuvo obtenida dicha informaci´on y verificada que fuera correcta, me centr´e en c´omo mostrarla gr´aficamente. Hice uso de una de las librer´ıas de Android, investigu´e con ella acerca de c´omo usarla y me dispuse a la creaci´on de los gr´aficos. Adem´as, para la interfaz gr´afica decid´ı hacer uso de pesta˜nas, funcionalidad que posteriormente ha sido usada en el proyecto. Una vez acabamos todas las funcionalidades restantes, y realizamos las pruebas, subimos la aplicaci´on a Play Store para que las personas que se la descargasen pudiesen probarla. Despu´es de varios reportes de errores, tanto mis compa˜neros como yo estuvimos arreglando fallos que se 138 hab´ıan producido, muchos de ellos por problemas de compatibilidad en las versiones no puras del Android. Para finalizar, tambi´en particip´e junto al resto de mis compa˜neros en la realizaci´on de la memoria. Nos dividimos los cap´ıtulos y cada vez que uno de los integrantes del equipo terminaba uno de ellos, los dem´as lo le´ıamos, correg´ıamos y reescrib´ıamos alg´un punto que nos parec´ıa que quedaba mejor de otro modo, siempre consult´andolo con los dem´as. Para terminar quer´ıa decir que ha habido momentos a lo largo del proyecto, en los que estebamos algo atascados, como en el proceso de determinar la ubicaci´on del usuario, o cuando necesitamos de un Service en segundo plano y no daban los resultados que esper´abamos. Creo que ha sido algo positivo el hecho de trabajar en grupo puesto que nos apoy´abamos unos a los otros en momentos dif´ıciles para tratar de sacarlo adelante, siendo siempre un grupo unido. 139 9.4.3. Iv´an Monterrubio Cerezo Comenzamos el proyecto reflexionando de como seria la aplicaci´on web y m´ovil, mediante una lluvia de ideas. Pens´e tanto yo como el resto de los compa˜neros del equipo en que funcionalidades habr´ıa que tener en cuenta antes de comenzar con el desarrollo del proyecto. Comenzamos desarrollando bocetos de como iba a ser la aplicaci´on web y m´ovil, como ser´ıan las pantallas, que funciones se le iban a mostrar al usuario a primer vista, que otras funciones podr´ıan estar recogidas en diferentes m´odulos... Tras tener un esquema principal de como ser´ıan las aplicaciones comenzamos a desarrollar en diferentes programas unos prototipos del aspecto de ambas aplicaciones. Una vez los ten´ıamos desarrollado por completo, ense˜namos nuestros bocetos a personas como amigos y familiares, usuarios no expertos en la aplicaci´on para que valorasen como iban a encontrar nuestra aplicaci´on. Despu´es de varias modificaciones en estos bocetos, comenzamos a dibujar que bases de datos necesitar´ıamos, y como se iban a relacionar las bases de datos con la aplicaci´on. A continuaci´on comenzamos desarrollando la aplicaci´on para web debido a que ten´ıamos experiencia en el desarrollo de las mismas, por varias asignaturas que hab´ıamos tenido a lo largo de la carrera sobre este tipo de proyectos. As´ı que como ten´ıamos experiencia en el desarrollo de este tipo de proyectos, nos dividamos los m´odulos de funciones, yo me encargue del horario. Para la realizaci´on de la misma, quer´ıa que no solo el bibliotecario/a pudiera determinar la hora de apertura y cierre si no tambi´en que pudiera crear nuevas plantas y llamarlas de diferente manera, eso fue uno de los aspectos que m´as me cost´o. Tuve que investigar bastante para encontrar unos recursos que me ayudaran a conseguir mostrar bien los horarios. Una vez realic´e eso y hab´ıa puesto dise˜no a los horario, concertamos una reuni´on los integrantes del equipo para poder determinar los fallos que podr´ıa haber y discutir el dise˜no. Una vez corregidos los fallos, implement´e con ayuda de una API de geolocalizaci´on un mapa para poder mostrar la ubicaci´on de la biblioteca. Despu´es de acabar con el desarrollo de la aplicaci´on web, pasamos al desarrollo de la aplicaci´on m´ovil. Yo era el ´unico que hab´ıa tenido experiencia en el desarrollo de aplicaciones m´oviles, debido a que el a˜no anterior hab´ıa cursado la asignatura de Programaci´on de Dispositivos M´oviles, y hab´ıa realizado alg´un proyecto de este tipo. Por lo que les ense˜n´e a Carlos y David, las diferentes formas de realizar una aplicaci´on m´ovil, como pudiera ser en nativo o con aplicando tecnolog´ıas web. Tras hacer varias reuniones donde vimos los pros y los contras entre una y otra opci´on, terminamos por decidirnos por hacer la aplicaci´on exclusiva para Android. Les ense˜n´e cu´al era el framework por el que nos ´ıbamos a ir moviendo, y proyectos b´asicos para realizar varias pruebas. A continuaci´on tanto ellos como yo investigamos y aprendimos sobre el desarrollo de aplicaciones. La primera pantalla, la de iniciar sesi´on y registrarse, la hicimos juntos, para poder ir cogiendo soltura. Una vez depuramos la primera pantalla y nos aseguramos de que funcionaba, y que est´abamos de acuerdo en el dise˜no, decidimos seguir con el desarrollo y empezamos el desarrollo de la p´agina fuente del proyecto, plantas. 140 Dicha pantalla la realizamos entre los tres componentes del grupo, debido a su complejidad. Primero realizamos una reuni´on los miembros del grupo, con el director, para poder hacer una lluvia de ideas de como hacer la realizaci´on del dise˜no y como representar los puestos de estudio y las mesas. Tras esta charla salimos con la idea de realizarla mediante botones. Una vez hab´ıamos hecho esto, vino lo m´as complicado y en lo que invertimos m´as tiempo, y era saber como obtener la ubicaci´on del usuario en cierto periodo de tiempo. Esto nos llev´o muchas reuniones para poder llegar alguna soluci´on, justamente la que tenemos ahora mismo implementada. Una vez conseguimos terminar el pilar principal del proyecto, nos aseguramos de que no hab´ıa fallos, empezamos a dividir las funciones restantes entre los miembros del equipo, yo realic´e horarios. Dicha funcionalidad fue mas levadera que la anterior mencionada. Me encargu´e de leer de la base de datos los horarios y mostrarlos. Una vez hab´ıa acabado esto, realizamos una reuni´on para determinar el dise˜no de los horarios y conforme a esto corregirlos. Una vez corregido a˜nad´ı esta funci´on al proyecto. Despu´es de terminar el desarrollo del proyecto, lanzamos la aplicaci´on a la conocida Play Store, para que la gente la pudiese probar. Despu´es de esto, nos enviaron varios reportes los usuarios de fallos y problemas y los acabamos corrigiendo los tres integrantes del grupo. Una vez finalizado el tema de la aplicaci´on m´ovil, desarroll´e a la par de mis compa˜neros los cap´ıtulos de la memoria, cada vez que un integrante desarrollaba un capitulo los otros dos lo revisaban y correg´ıan. Por ´ultimo destacar el trabajo realizado por el grupo, debido al esfuerzo que hemos realizado durante todo el a˜no, en situaciones en la que no estaba muy claro como avanzar con el proyecto. Adem´as creo que hemos sabido ser un buen grupo de trabajo, apoy´andonos, buscando todos informaci´on, y siempre con una buena organizaci´on. Desde un primer momento siempre quisimos en desarrollar un proyecto que fuese de utilidad y eso fue una de las cosas que nos motiv´o a seguir el proyecto y a saber disfrutar mientras lo realiz´abamos. 141 10. Bibliograf´ıa [1] P´agina web en la que aparecen los puestos disponible de los laboratorios de la FDI - http: //informatica.ucm.es/puestos-disponibles-por-laboratorio/ [2] P´agina web en la realizar la reserva de salas de trabajo en grupo de la facultad de educaci´on de la UCM - http://cisne.sim.ucm.es/record=b3601291~S6*spi [3] Aplicaci´on m´ovil de Cinesa - https://play.google.com/store/apps/details?id=com. codiwans.cinesa [4] Aplicaci´on m´ovil de PLM - https://play.google.com/store/apps/details?id=com. ingeniacom.plm [5] Ventajas y desventajas de JSON y de XML - https://www.oscarblancarteblog.com/ 2014/07/18/json-vs-xml/ [6] Ventajas y desventajas de MySQL - http://www.foc.es/2013/04/11/ 988-razones-por-la-que-utilizar-mysql.html [7] Summary of Don Norman’s Design Principles - http://www.csun.edu/science/courses/ 671/bibliography/preece.html [8] Documento de estilo web de la UCM - https://www.ucm.es/ssii/introduccion [9] Font Awesome Icons - https://www.w3schools.com/icons/fontawesome_icons_intro. asp [10] Glyphicons Icons - https://www.w3schools.com/icons/bootstrap_icons_glyphicons. asp [11] Principios aplicaci´on m´ovil - http://appdesignbook.com/es/contenidos/ patrones-interaccion-moviles/ [12] Material Design - https://material.io/design/ [13] Roboto - https://fonts.google.com/specimen/Roboto [14] Pegatina NFC - https://computerhoy.com/paso-a-paso/apps/ etiquetas-nfc-como-usarlas-que-sirven-4351 [15] Descarga de la app Biblioteko desde Google Play - https://play.google.com/store/ apps/details?id=es.tfg.montevichomasters [16] Highcharts, librer´ıa escrita en Javascript que permite la creaci´on de gr´aficas - https:// www.highcharts.com/ [17] Android Developers - https://developer.android.com/ [18] C´odigo PHP del algoritmo Punto en Pol´ıgono (PIP) - http://assemblysys.com/es/ algoritmo-punto-en-poligono/ [19] C´odigo Java del algoritmo Punto en Pol´ıgono (PIP) - https://github.com/sromku/ polygon-contains-point 142 [20] Cuestionario realizado para la evaluaci´on de la aplicaci´on - https://docs.google. com/forms/d/e/1FAIpQLSdOKCU0aHXo3tffTLBjTn1ksODsAp0xEoZtD0KgPCv2iU609Q/ viewanalytics [21] Curso de Programaci´on Android sgoliver - http://www.sgoliver.net 143 11. Ap´endices 11.1. Ap´endice A: Manual de instalaci´on Como el pensamiento que se ten´ıa antes de realizar el proyecto era realizar una aplicaci´on web y m´ovil f´acil de usar es por ello que para poder probar la aplicaci´on y para su instalaci´on se trata de un proceso simple. Para probar la aplicaci´on tan solo es necesario descargarse de Google Play la aplicaci´on ‘Biblioteko’ [15] y para acceder a la p´agina web en el link http://biblioteko.es/ Se puede acceder al contenido de todo el proyecto a trav´es de una carpeta de Google Drive habilitada para ello. En ella se puede encontrar esta memoria, una carpeta llamada ‘Aplicaci´on m´ovil’ y otra ‘Aplicaci´on web’. En la primera se encuentra el archivo .apk listo para instalarse en cualquier dispositivo Android y otra carpeta que contiene el proyecto de Android Studio, con todos los archivos, c´odigo e im´agenes que lo componen. En la segunda de las carpetas se puede ver un archivo .sql con la base de datos de la aplicaci´on web, y otra carpeta a su vez que contiene el ´arbol de directorios completo de la p´agina web. A continuaci´on se van a describir los recursos necesarios para poder ver todo el proyecto desarrollado en su totalidad: 11.1.1. P´agina web Para visualizar la p´agina web bastar´a con visitar el siguiente enlace: http://biblioteko.es/ Si una biblioteca quiere darse de alta en la plataforma el proceso a seguir es ponerse en contacto con los desarrolladores a trav´es del apartado Cont´actanos de la web, desde donde se establecer´an los requisitos y se solicitar´an todos los datos necesarios para que el equipo desarrollador cree esa nueva biblioteca en ambas aplicaciones. Cuando se haya finalizado, se facilitar´a a la biblioteca sus datos de acceso y podr´a acceder a la web de manera normal. Si se quiere visualizar en local, primero deberemos se deber´a descargar el archivo .sql y la carpeta ’biblioteko’, que contiene el c´odigo para visualizar la p´agina web, ambos se adjuntan en a carpeta de Drive, para la creaci´on de las tablas en la base de datos. A continuaci´on, activar la conexi´on con xampp y con mysql. Luego se podr´a visualizar la p´agina web en el siguiente enlace: http://localhost:8080/biblioteko 11.1.2. Android Studio Utilizado para el desarrollo de la aplicaci´on m´ovil. Se puede descargar la versi´on 3.1.2 para Windows en este enlace https://developer.android.com/studio/?hl=es 11.1.3. Sublime Text Aunque no es necesario, se recomienda para poder leer los diferentes archivos HTML, CSS,PHP y Javascript un editor de texto. En este proyecto se ha programado utilizando dicho editor, muy recomendable. A continuaci´on se adjunta un link para la descarga: https://www.sublimetext. com/3 11.1.4. MySQL Para la base de datos, se tendr´a que descargar este gestor de base de datos. Se puede hacer la descarga en https://www.mysql.com/downloads/ 144 11.1.5. Aplicaci´on Android Una vez instalado Android Studio, y descargada la carpeta ’montevichomasters’, podremos abrir el proyecto seleccion´andolo. Tambi´en podremos ejecutar un emulador dentro de este framework. Tambi´en se puede hacer una prueba instalando el archivo .apk que se adjunta con el proyecto. 11.2. Ap´endice B: Manual de usuario En este manual se explicar´a detalladamente las funciones que puede realizar el usuario, para facilitar el uso de la aplicaci´on web y m´ovil. 11.2.1. Aplicaci´on web 11.2.1.1 Iniciar sesi´on Figura 115: Manual - Iniciar sesi´on Al ser esta p´agina exclusiva para los bibliotecarios, no podr´an iniciar sesi´on otra persona que no tengan este rol en la facultad. Para poder iniciar sesi´on, los administradores (que seremos nosotros) de la aplicaci´on deber´an ponerse en contacto con los bibliotecarios para proporcionar un usuario y contrase˜na. Este usuario y contrase˜na cambiar´a dependiendo de la biblioteca, por lo que no ser´a la misma. Para iniciar sesi´on correctamente se deber´a rellenar el usuario (campo 1) y la contrase˜na (campo 2) y darle a la opci´on de aceptar(campo 3). En caso de no haber cometido fallos, se pasar´a a la pantalla principal, el buz´on de sugerencias. 145