ESCUELA TÉCNICA SUPERIOR DE
INGENIERÍA Y SISTEMAS DE
TELECOMUNICACIÓN
PROYECTO FIN DE GRADO
TÍTULO: APLICACIÓN DE GESTIÓN DE RESERVAS Y
HUÉSPEDES DE HOTEL
AUTOR: IGNACIO ÁLVAREZ ÁLVAREZ
TITULACIÓN: TELEMÁTICA
TUTOR: JOSÉ FERNÁN MARTÍNEZ ORTEGA
DEPARTAMENTO: DTE
VºBº
Miembros del Tribunal Calificador:
PRESIDENTE: DANILO SIMÓN ZORITA
VOCAL: JOSÉ FERNÁN MARTÍNEZ ORTEGA
SECRETARIO: VICENTE HERNÁNDEZ DÍAZ
Fecha de lectura:
Calificación:
El Secretario,
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 1
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 2
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 3
Resumen Este proyecto final de grado tiene como objetivo desarrollar la primera versión o versión beta
de una aplicación móvil que permita a todo aquel que lo desee alojarse en un hotel sin tener
que pasar por la recepción del mismo. La aplicación móvil tiene como objetivo principal la
comodidad para el usuario, así como otros objetivos adicionales que se detallan en esta
memoria.
En la primera parte de la memoria se presenta a modo de introducción la aplicación, indicando
lo perseguido por este proyecto detallando las carencias que había en torno a las
funcionalidades que ofrece la aplicación. Una vez presentada la aplicación se explican las
tecnologías más relevantes utilizadas para su creación, así como las aplicaciones existentes
que podrían ser en un futuro su competencia.
El grueso de esta memoria se encuentra en la parte de explicación del diseño de la aplicación.
Esta parte se ha dividido en dos: la parte de servidor y la parte de aplicación Android. En la
parte del servidor se explica tanto la estructura del servidor creado como las tecnologías
utilizadas para su creación y puesta en marcha (Node.JS, Total.JS, Ngrok). En la parte de
explicación del diseño de la aplicación Android se detalla el modelo usado para su diseño y su
estructura. También se explican los métodos más importantes utilizados para el
funcionamiento de la aplicación.
Una vez explicado todo el diseño de la aplicación se encuentra la parte donde se explica el uso
de la aplicación con diversos diagramas UML donde se puede ver todas las cosas que puede
hacer el usuario con la aplicación.
Por último, en el soporte informático se encuentra todo el código, tanto de la aplicación como
del servidor así como una copia en formato digital de esta memoria.
El resultado obtenido en este proyecto es un prototipo de aplicación que cubre todas las
necesidades que se han planteado al inicio del proyecto. Como se indica al final de esta
memoria esta aplicación necesita varios desarrollos futuros para que sea totalmente funcional,
lo que no indica que no sea una aplicación con un gran potencial que pueda ser pionera y
puntera en este sector.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 4
Índice Resumen ........................................................................................................................................ 3
Índice ............................................................................................................................................. 4
Índice de figuras ............................................................................................................................ 5
1. Introducción .......................................................................................................................... 7
1.1 Objetivos ............................................................................................................................. 7
2. Estado del Arte ...................................................................................................................... 8
2.1 Android ................................................................................................................................ 8
2.2 NFC ...................................................................................................................................... 8
2.3 Aplicaciones existentes ....................................................................................................... 9
3. Diseño y desarrollo ................................................................................................................ 9
3.1 Servidor ......................................................................................................................... 9
3.2 Aplicación Android ...................................................................................................... 26
4. Uso de la aplicación ............................................................................................................. 43
4.1 Caso de Uso ................................................................................................................. 43
4.2 Diagrama de flujo ........................................................................................................ 44
4.3 Navegación .................................................................................................................. 44
5. Diseño final .......................................................................................................................... 46
6. Futuros desarrollos.............................................................................................................. 54
7. Bibliografía .......................................................................................................................... 55
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 5
Índice de figuras Figura 1: Archivo “package.json” ................................................................................................ 10
Figura 2 Archivo “index.js” .......................................................................................................... 10
Figura 3 Operaciones ‘npm install’ y ‘npm start’ ........................................................................ 11
Figura 4 Archivo “melia.json” ...................................................................................................... 12
Figura 5 Archivo “prepareSQL.js” (1) ........................................................................................... 14
Figura 6 Archivo “prepareSQL.js” (2) ........................................................................................... 15
Figura 7 Importación de modelos en “defaults.js” ..................................................................... 15
Figura 8 Operación ‘install’ y definición de enpoints .................................................................. 16
Figura 9 Función de registro en “defaults.js” .............................................................................. 17
Figura 10 Función de login en “defaults.js” ................................................................................ 18
Figura 11 Función de comprobación de usuario en “defaults.js” ............................................... 18
Figura 12 Función de listado de hoteles en “defaults.js” ............................................................ 19
Figura 13 Función de listado de habitaciones en “defaults.js” ................................................... 19
Figura 14 Función de listado de las reservas del usuario en “defaults.js” .................................. 20
Figura 15 Función de la transacción en el archivo “defaults.js” (1) ............................................ 22
Figura 16 Función de la transacción en el archivo “defaults.js” (2) ............................................ 23
Figura 17 Comprobación de la transacción (1) ........................................................................... 24
Figura 18 Comprobación de la transacción (2) ........................................................................... 25
Figura 19 Invocación a la herramienta ngrok .............................................................................. 25
Figura 20 Despliegue de la herramienta ngrok ........................................................................... 25
Figura 21 Patrón Model-View-ViewModel [8] ............................................................................. 26
Figura 22 Paquetes de la interfaz de usuario .............................................................................. 27
Figura 23 Clase utilizada como modelo del patrón MVVM ......................................................... 28
Figura 24 LoginViewModel .......................................................................................................... 29
Figura 25 Tratamiento del token en LoginActivity ...................................................................... 29
Figura 26 RegisterActivity............................................................................................................ 30
Figura 27 ProfileFragment ........................................................................................................... 31
Figura 28 RoomsFragment (1) ..................................................................................................... 32
Figura 29 RoomsFragment (2) ..................................................................................................... 33
Figura 30 ReaderNfcUseCase (1) ................................................................................................. 34
Figura 31 ReaderNfcUseCase (2) ................................................................................................. 35
Figura 32 VerifyNfcUseCase ........................................................................................................ 36
Figura 33 PaymentActivity (1) ..................................................................................................... 37
Figura 34 PaymentActivity (2) ..................................................................................................... 38
Figura 35 PaymentActivity (3) ..................................................................................................... 39
Figura 36 Ejemplo de ‘Adapter’ creado para la lista de reservas del cliente .............................. 40
Figura 37 Utils.java (1) ................................................................................................................. 41
Figura 38 Utils.java (2) ................................................................................................................. 42
Figura 39 Caso de uso de la aplicación ........................................................................................ 43
Figura 40 Diagrama de flujo de la aplicación .............................................................................. 44
Figura 41 Diagrama de navegación ............................................................................................. 45
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 6
Figura 42 Pantalla de Login/Registro .......................................................................................... 46
Figura 43 Pantalla de Registro ..................................................................................................... 48
Figura 44 Pantalla de Perfil ......................................................................................................... 48
Figura 45 Pantalla con la lista de hoteles .................................................................................... 49
Figura 46 Pantalla con la lista de habitaciones disponibles ........................................................ 50
Figura 47 Pantalla de la pasarela de pago ................................................................................... 51
Figura 48 Confirmación de pago realizado .................................................................................. 53
Figura 49 Pantalla de habitaciones reservadas por el usuario .................................................... 53
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 7
1. Introducción En un mundo cada vez más avanzado y más globalizado se puede observar cómo las
tecnologías evolucionan a pasos agigantados y los viajes crecen exponencialmente. En España
por ejemplo durante el año 2018 se superaron los 80 millones de turistas internacionales. Esto
sumado a los turistas residentes en España hace un total de más de 300 millones de
pernoctaciones hoteleras en el país. Si a estas cifras sumamos la cantidad de viajeros que
pernoctan en hoteles de España por motivos laborales podemos estar hablando de alrededor
de 400 millones de pernoctaciones anuales. [1][2]
Hoy en día podemos asumir que la inmensa mayoría de estos viajeros disponen de un teléfono
móvil Smartphone, por lo que es una herramienta que podemos explotar dada su rápida
evolución. Y es en eso en lo que va a consistir este proyecto, en usar las nuevas tecnologías
para facilitar a todos los millones de viajeros sus estancias hoteleras.
Los usuarios esperan y casi exigen de los desarrolladores tecnológicos que les proporcionemos
maneras de acceder a los últimos avances en sus dispositivos móviles, quieren tener en un solo
aparato todas las herramientas necesarias para su día a día. Por una parte, quieren tener
acceso a toda la información disponible, así como utilizarlo de forma lúdica y como
entretenimiento, pero también quieren poder usarlo para, desde cualquier lugar, realizar
cualquier tipo de gestión.
El teléfono móvil, y en este caso el smartphone, se ha convertido en mucho más que un medio
de comunicación, es un utensilio indispensable ya para cualquier persona y que pone en su
bolsillo unas posibilidades enormes. En este caso nuestros usuarios podrán utilizar la
aplicación aquí desarrollada para planificar sus viajes de una forma mucho más eficiente,
resuelta, sencilla y segura para ellos.
1.1 Objetivos Uno de los principales problemas que se pueden encontrar los viajeros son las esperas en
recepción, sobre todo a la hora de hacer el registro de entrada, que pueden incluso llegar a
hacerse realmente pesadas. Después de un largo trayecto que en ocasiones puede haber sido
muy cansado, lo que esperan es que esa gestión se realice cuanto antes y puedan acceder
cuanto antes a su habitación para descansar. El objetivo de este proyecto es básicamente el
uso de una aplicación móvil para que el viajero se dirija directamente a sus aposentos sin tener
que pasar por el lento y tedioso trámite de la recepción. La propia aplicación le indicará cuál es
el número de su habitación y con el propio teléfono móvil, usando la tecnología NFC, podrá
acceder a la habitación sin necesidad de esperar a que se realice el trámite de creación de la
llave.
Sin embargo, las funciones de la aplicación irán mucho más allá y comenzará a ser útil desde
mucho antes, pues servirá también, además de para hacer el check-in, para buscar
habitaciones y hacer las reservas pertinentes. Ya no será necesario sentarse delante del
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 8
ordenador, puesto que de una forma muy cómoda y desde cualquier lugar, nuestros usuarios
podrán planificar su viaje y buscar las mejores opciones.
Otro de los objetivos buscados con esta aplicación es la garantía de confidencialidad, enfocada
sobre todo a personajes públicos. El hotel únicamente sabrá que una habitación está ocupada,
pero no tendrá información de quiénes son los huéspedes. Únicamente podría acceder a esa
información en el caso de que hubiese algún desperfecto o de que así lo requirieran las
autoridades por cualquier motivo justificado.
El derecho a la privacidad es uno de los aspectos más demandados en estos tiempos en los que
es tan fácil seguir el rastro de una persona, tanto físicamente como por su huella digital. Con
nuestra aplicación buscamos también ese equilibrio entre ofrecer las máximas opciones y
servicios a nuestros usuarios y respetar su intimidad y sus informaciones más personales.
Por tanto, teniendo en cuenta todo lo expuesto en los párrafos anteriores, podemos resumir
los objetivos en la búsqueda de estos cinco principios:
1. Accesibilidad: se pueden realizar importantes gestiones desde cualquier lugar.
2. Amplitud de oferta: el usuario tiene a su disposición las mejores opciones del
mercado de viajes.
3. Rapidez: se evitan las esperas en las colas de recepción.
4. Comodidad: el huésped abrirá la habitación con el teléfono móvil.
5. Confidencialidad: el hotel no tendrá información de quién es el huésped.
2. Estado del Arte
2.1 Android Android es un sistema operativo móvil desarrollado por la empresa estadounidense Google
basado en kernel de Linux y en software de código abierto. Originalmente fue diseñado para su
uso en teléfonos móviles con pantalla táctil, o Smartphones, aunque en la actualidad es
utilizado también por tabletas, relojes inteligentes, televisores y hasta automóviles.
Actualmente es el sistema operativo móvil más utilizado, con una cuota de mercado que
supera el 70%. [3] Es por eso que se ha elegido este sistema operativo para este proyecto, ya
que otorgaría un número importante de usuarios potenciales.
Actualmente la última versión disponible del sistema operativo Android es la 10, aunque
podemos encontrar usuarios con versiones anteriores. Podemos encontrar desde la versión 4
(bastante residual) hasta la versión 9, que es la más común en estos momentos. [4]
2.2 NFC NFC son las siglas de Near Field Communication. Es una tecnología inalámbrica heredera de las
etiquetas RFID que está presente tanto en teléfonos móviles como en abonos de transporte o
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 9
sistemas de seguridad de tiendas físicas. Dada su baja tasa de transferencia, poco más de
400kbit/s, se utiliza para comunicación instantánea, es decir, identificación y validación de
equipos. Tiene un radio de acción muy bajo (unos 20cm máximo), pero los dispositivos con
esta tecnología pueden enviar y recibir datos al mismo tiempo.
2.3 Aplicaciones existentes En la actualidad existen algunas aplicaciones similares a la desarrollada en este proyecto,
aunque sí es cierto que no ofrecen la misma funcionalidad.
Es el ejemplo de la aplicación FASTPASS de la cadena NH. Con esta aplicación se puede hacer
un check-in online previo a la llegada, pudiendo elegir en qué habitación se desea pasar la
estancia. Pero este proceso de check-in online únicamente recude el tiempo de espera en la
recepción, ya que solo hay que pasar a recoger la llave, pero no elimina este paso, que es lo
que se persigue con este proyecto. Tampoco cubre el requisito de confidencialidad, ya que el
hotel sabe en todo momento quién está alojado en cada habitación.
Lo mismo pasa con la aplicación Wishbox. Es una aplicación dedicada a agilizar los trámites, al
igual que la mencionada de la cadena NH. Pero sigue habiendo el requisito de pasar por
recepción a recoger la llave. Además en este caso el hotel también dispone de todos los datos
del huésped.
Dado el vacío existente en el mercado actual es por ello que se ha decidido desarrollar la
aplicación sobre la que trata este proyecyto.
3. Diseño y desarrollo A continuación se va a detallar el proceso de creación de la aplicación. En primer lugar
empezaremos por la parte del servidor y posteriormente con la aplicación en sí.
3.1 Servidor Para la implementación de la aplicación se ha decidido crear un servidor básico que permitiese
hacer todas las operaciones de registro, reserva y hospedaje que necesita la aplicación. Para
ello se ha utilizado JavaScript para su codificación. Para su posterior ejecución se ha utilizado
Node.JS. Node.JS es un entorno de ejecución de JavaScript orientado a eventos asíncronos, es
decir, que mientras se están ejecutando se está esperando una respuesta. [5]
En vez de utilizar el código propio de Node.JS se ha decidido utilizar una librería,
concretamente Total.JS. Se ha seleccionado esta librería por varias razones:
- En primer lugar tiene muy bajo consumo de memoria (requiere únicamente 50MB de
memoria RAM.
- Por otro lado su tamaño es muy pequeño. Las dependencias de esta librería solamente
suman al proyecto 1.6MB.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 10
Ahora vamos a entrar a analizar el propio servidor desarrollado.
En primer lugar cabe destacar que todo proyecto de Node.JS tiene un archivo llamado
“package”. En ese archivo se pueden encontrar datos básicos del proyecto, como pueden ser
el nombre, la versión, una descripción del aplicativo, el programa principal, el autor, la licencia
que tiene y las dependencias.
Figura 1: Archivo “package.json”
Como podemos observar en la figura anterior el programa principal es “index.js” que podemos
ver a continuación:
Figura 2 Archivo “index.js”
Este proyecto se inicializa de la siguiente forma: se ejecuta una operación require, en modo
debug, con unas opciones que se pueden parametrizar.
Para arrancarlo únicamente debemos utilizar las invocaciones de Node.JS, a saber, ‘npm install‘
para instalar las dependencias y posteriormente ‘npm start’ para arrancar el servidor.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 11
Figura 3 Operaciones ‘npm install’ y ‘npm start’
El proyecto de Node.JS con la librería Total.JS funciona con una serie de directorios, que se
pueden crear en función de lo que se quiera. [6] Cada directorio tiene un uso concreto. Los
directorios creados en este proyecto son los siguientes:
- Directorio de configuración: utilizado para poder hacer distintos entornos.
- Directorio de controladores: en este caso serán los servicios que se han desplegado.
- Directorio de base de datos: este directorio se crea automáticamente. En él se pueden
ver todas las modificaciones.
- Directorio de definiciones: para definir módulos, en este caso la interfaz.
- Directorio de modelos: en este caso los proyectos nosql.
- Directorio de módulos: para añadir funcionalidad.
- Directorio privado: para datos customizados.
En este proyecto el directorio privado se ha utilizado para meter toda la información de los
hoteles. Se han implementado unos archivos json en los que se indica la cadena del hotel, el
nombre, la dirección, los servicios y las habitaciones.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 12
Figura 4 Archivo “melia.json”
En la figura anterior podemos observar todos los datos que se han introducido del hotel de la
cadena Meliá incluidas las habitaciones que se ofrecen en el hotel donde se pueden ver
también todos sus atributos como por ejemplo el precio y los números de habitación que se
corresponden con cada categoría.
En el directorio de módulos encontramos un archivo llamado “prepareSQL.js”, que se ejecuta
automáticamente en el arranque. Este archivo se encarga de convertir los dos archivos json
presentados anteriormente en información para poder leerla fácilmente en la base de datos.
Es decir, inicializa la base de datos de hoteles y habitaciones disponibles. Lo que hace este
archivo es leer los ficheros del directorio ‘private/hotels’ para meter la información de los
hoteles en la base de datos.
En primer lugar lo que se hace es poner un id de la cadena por cada fichero, ya que cada uno
corresponde a una cadena hotelera. Este id se va incrementando según se van leyendo los
ficheros json. En este caso habrá un id para AC y otra para Meliá. A continuación tras leer la
cadena y el hotel se procesa el archivo json. Lo que se hace es gestionar las habitaciones con la
información del hotel al que pertenece la habitación. Esto se hace para relacionar hoteles con
habitaciones en dos entidades distintas. Con esto se consigue no tener que llamar a más de un
archivo nosql. Una vez procesadas las habitaciones se procesan los proveedores. Por último se
incrementa el id del hotel, el cual se incrementa ‘n’ veces el último id de hotel asignado. Lo
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 13
mismo se hace con el id de habitaciones. Después se concatena toda la información y se
guarda en el documento.
A continuación se muestra un ejemplo de un registro del fichero ‘hotels.nosql’ donde se
guarda la información de los hoteles:
{"name":"AC Hotel Colon Valencia","starts":4,"address":"Colon 32,
Valencia","services":["Servicio de habitaciones","Lavandería","Aire
acondicionado","Ascensor","Restaurante","Hotelbar","Alquiler de
bicicletas","Terraza"],"image":"https://cache.marriott.com/marriottassets/marriott/VLCAP/vlc
ap-living-0050-hor-clsc.jpg?&interpolation=progressive-
bilinear&downsize=378px:*","id":1,"provider":{"id":1,"name":"AC
Hoteles","image":"https://cache.marriott.com/marriottassets/marriott/AR/Logo/ar_logo_L.pn
g"}}
A continuación se muestra un ejemplo de un registro del fichero ‘rooms.nosql’ donde se
guarda la información de todas las habitaciones:
{"name":"Habitación
Standard","image":["https://cache.marriott.com/marriottassets/marriott/VLCAP/vlcap-
guestroom-0034-hor-clsc.jpg?&interpolation=progressive-
bilinear&downsize=378px:*"],"price":80.99,"list":[101,102,103,104,105,106],"id":1,"provider":
{"id":1,"name":"AC Hotel Colon Valencia"}}
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 14
Figura 5 Archivo “prepareSQL.js” (1)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 15
Figura 6 Archivo “prepareSQL.js” (2)
En la Figura 5 podemos observar cómo se leen los hoteles y se guardan en la base de datos
nosql mientras que en la Figura 6 vemos la misma operación para el caso de las habitaciones
de cada hotel.
En el directorio de controladores nos encontramos con el archivo “defaults.js”. En este archivo
se encuentra el grueso de las operaciones del servidor. En primer lugar accedemos a los
modelos a través del nombre que le hayamos dado. En este caso en los modelos encontramos
tanto el nombre como la propiedad que se utiliza para sacar la información, en este caso
‘schema’.
Figura 7 Importación de modelos en “defaults.js”
A continuación la librería Total.JS lo que hace es ejecutar en todos los ficheros la variable
install para poder ser encontrados y definir los endpoints indicando el método del endpoint
(GET, POST, PUT o DELETE) y la ruta (en la que se pueden configurar parámetros de entrada.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 16
Figura 8 Operación ‘install’ y definición de enpoints
Podemos observar todos los endpoints definidos para las distintas funciones de la aplicación:
registro, login, obtención de perfil, listado de hoteles, listado de habitaciones, habitaciones del
usuario y transacción del pago con tarjeta.
En la función de registro lo primero que hacemos es comprobar si existe el email introducido.
En caso de no existir el email en la base de datos generamos un identificador de forma
automática. La base de datos que se utiliza como está metida en Total.JS no mete el índice
autoincremental y por eso se genera a mano. A continuación convertimos los datos del usuario
en un objeto json para meterlo en la base de datos.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 17
Figura 9 Función de registro en “defaults.js”
A continuación tenemos el servicio de login en el cual comprobamos si existe el usuario (la
cuenta de email). En caso de que exista el usuario comprobamos la contraseña que tiene que
coincidir con un SHA1 de la contraseña que se ha introducido. Si todo ha ido correctamente
cogemos el id y la contraseña y lo encriptamos de forma simétrica. Esto será usado para
autenticar el usuario y saber si puede o no hacer ciertas tareas como consultar sus
habitaciones y hacer transacciones. Esto se hace en la función ‘checkUser’ a la cual se le pasa
un string, el cual se debe parsear para sacar la información del id y la contraseña codificadas y
decodificarlo para ver si es correcto.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 18
La clave utilizada para la encriptación del id y la contraseña se encuentra en el archivo de
configuración.
Figura 10 Función de login en “defaults.js”
Figura 11 Función de comprobación de usuario en “defaults.js”
A continuación encontramos las funciones para listar los hoteles y el servicio de disposición del
hotel donde se muestran las habitaciones disponibles en las fechas seleccionadas. Para ello se
pasa la fecha por parámetros en la petición. Se buscan las habitaciones del hotel, el cual se ha
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 19
indicado por el id, se hace una lista con todas ellas y a continuación se contabilizan las
habitaciones ocupadas en esa franja de fechas. Después se recorre el array de las habitaciones
para eliminar las habitaciones ocupadas. Si no hay ninguna habitación disponible no se
mostraría ninguna habitación.
Figura 12 Función de listado de hoteles en “defaults.js”
Figura 13 Función de listado de habitaciones en “defaults.js”
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 20
Después tenemos las habitaciones del usuario. En primer lugar comprobamos si el usuario está
logueado. En caso afirmativo se buscan las habitaciones reservadas por el usuario. Esto se
encuentra en el archivo “checkins.nosql” de la base de datos. Se recorre el fichero y se
muestran los registros que pertenezcan al id del usuario.
Figura 14 Función de listado de las reservas del usuario en “defaults.js”
A continuación se muestra un registro de ejemplo del fichero “chenckins.nosql”:
{"check_in":1591696800000,"check_out":1591783200000,"hotel_id":1,"room_id":3,"user_id":
2,"hab":302}
En el registro de checkin podemos ver tanto la fecha de entrada como la de salida, el id del
hotel, el id de la habitación, el id del usuario y el número de habitación.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 21
Por último tenemos las funciones relacionadas con las transacciones de pago. Para ello se ha
utilizado una pasarela de pago llamada Stripe. Se ha elegido esta pasarela por ser
relativamente sencilla de implementar y porque además es una de las pasarelas de pago para
aplicaciones Android más usadas del mercado. Es usada por ejemplo por grandes empresas
como Glovo, El Corte Inglés, Uber, Booking.com y un sinfín de plataformas.
El funcionamiento de las funciones de transacción es el siguiente:
En primer lugar se hace una validación del precio, ya que el cálculo se hace en la propia
aplicación, pero hay que comprobarlo en backend para evitar crear un registro falso con
llamadas falsas. Se busca la habitación del hotel con su identificador y comprobamos que es
una habitación real. A continuación se saca el precio con las fechas introducidas y se pasa a
Stripe. En caso de que el precio introducido por el usuario sea erróneo no se continúa con el
flujo y no se cobra nada. Después en Stripe se guarda el id del hotel, el id de la habitación, la
entrada, la salida y el usuario. Stripe se encarga de hacer la transacción y nos devuelve un
identificador del pago. Ese identificador lo utilizaremos después para comprobar que el pago
ha sido realizado. Una vez el pago ha sido comprobado sacamos toda la información de la
reserva que irá dirigida al archivo “checkins.nosql” nombrado anteriormente. Después
comprobamos que hay disponibilidad en las habitaciones en la fecha en las que el usuario ha
pagado para asignarle una habitación, la cual será una aleatoria de todas las disponibles. Por
último guardamos la información. Al terminar todas las operaciones se considerará que el pago
y la reserva se han completado con éxito.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 22
Figura 15 Función de la transacción en el archivo “defaults.js” (1)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 23
Figura 16 Función de la transacción en el archivo “defaults.js” (2)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 24
Figura 17 Comprobación de la transacción (1)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 25
Figura 18 Comprobación de la transacción (2)
Por último para el acceso al servidor desde la aplicación se ha decidido utilizar la herramienta
ngrok. Esta herramienta permite desplegar un servicio web de forma temporal utilizando la
propia máquina como servidor. Al arrancar la herramienta únicamente hay que indicarle
dónde se encuentra el servicio a desplegar y el protocolo a usar y ésta automáticamente
asigna una dirección web pública a ese servicio durante unas horas. [7]
Figura 19 Invocación a la herramienta ngrok
Figura 20 Despliegue de la herramienta ngrok
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 26
3.2 Aplicación Android Para la implementación de la aplicación Android se ha utilizado la herramienta de desarrollo
Android Studio. Se ha elegido esta herramienta por su gran utilidad para el desarrollo de
aplicaciones y por su fácil manejo.
Para la realización de este proyecto Android se ha utilizado el patrón Model-View-ViewModel
(MVVM). MVVM es un patrón de arquitectura de software creado por Microsoft que consiste
en separar lo máximo posible la lógica de la aplicación de la interfaz de usuario. Esta
separación permite abordar con más facilidad problemas en el desarrollo de la aplicación y
permite que la aplicación sea más fácil de testear, mantener y desarrollar. [8]
Figura 21 Patrón Model-View-ViewModel [8]
Aplicado este patrón al proyecto quedaría estructurado de la siguiente forma_
- El bloque ‘view’ se corresponde con el ‘Fragment’ de la aplicación.
- El bloque ‘viewmodel’ está asociado a cada ‘Activity’
- El bloque ‘model’ son los distintos repositorios.
En el bloque ‘view’ se registran los cambios del bloque ‘viewmodel’ de tal forma que
cuando éste detecta un cambio se lo envía a la vista. El bloque ‘model’ se utiliza para
enviar y recibir datos como pueden ser una llamada a un servicio o a un repositorio de
datos que se tenga en local.
A continuación entramos a detallar la estructura y las características del proyecto Android.
En primer lugar hablaremos de las diferentes pantallas de la interfaz de usuario de la
aplicación organizadas en paquetes que quedan de la siguiente forma:
- Bookins: es la ventana de las reservas.
- Custom: consiste en una ventana auxiliar para la indicar al usuario si la puerta de la
habitación se ha abierto o no.
- Hotels: es la ventana donde se muestran los diferentes hoteles que se han descargado
del servidor. Dentro de este paquete encontramos también Rooms, que son las
ventanas que muestran las habitaciones.
- Login: muestra la ventana para iniciar sesión.
- Payments: es la pantalla para la realización del pago.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 27
- Profile: pantalla donde se muestra la información del usuario.
- Register: es la pantalla donde uno se da de alta en el servicio.
- Views: es una pantalla de vistas extra como por ejemplo el calendario de elección de
fecha de la reserva.
Figura 22 Paquetes de la interfaz de usuario
Por otro lado encontramos el paquete ‘domain’ que es donde están todos los repositorios y
algún caso de uso concreto que se concretará más adelante. En este paquete encontramos
también los modelos del patrón MVVM que se han utilizado en el proyecto. Para poder
controlar los distintos estados se ha creado un modelo que se susscribe en ‘MutableLiveData’.
Para ello se ha creado una clase que registra si ha ido todo bien o ha habido algún error.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 28
Figura 23 Clase utilizada como modelo del patrón MVVM
Esta clase es utilizada por los bloques ‘viewmodel’ de cada una de las diferentes pantallas.
Vamos a tomar como ejemplo la pantalla de login. En su bloque ‘viewmodel’ se hace un post
donde se recibe la información del email y la contraseña, se hace una llamada al repositorio y
se hace un callback que devolverá un token. Con esa token sabremos si el proceso ha ido bien
o por el contrario ha habido algún error. Después desde la ‘LoginActivity’, que sería la pantalla
que ve el usuario, se recoge ese error o éxito para actuar en consecuencia. Este proceso ayuda
a controlar lo que tiene que hacer la vista (‘view’) en un único sitio y no tener duplicidad en
variables y métodos. Esta token puede tener distintos estados: éxito, error o completado (para
informar únicamente de un proceso terminado sin esperar ningún tipo de información).
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 29
Figura 24 LoginViewModel
Figura 25 Tratamiento del token en LoginActivity
Como se podemos observar todos los fragments o activities tienen la misma estructura. Se
registra el ‘observable’ para la comunicación con el ‘viewmodel’. Ese observable se carga
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 30
mediante una invocación y el token que tenga que devolver se trata en el método ‘handle’ de
cada fragment o activity.
A continuación entramos a analizar el proceso de registro. En primer lugar se inicializan los
controles. A continuación se añade el evento del botón de registro y se lanzan los eventos que
se necesitan. En el registro se procesa que la información no se envíe vacía para evitar que se
envíen solicitudes incompletas o que por ejemplo las contraseñas no coincidan. Otra cosa que
se hace es que según se va pasando, cuando se termina de setear la contraseña, dando a enter
automáticamente ejecuta el evento del click. Se hace la llamada al postregister con la
información y se trata la token recibida. En caso de éxito finaliza la ‘activity’ y se va a la de
login. En caso de error se informa de que ha habido un error y se mantiene la ‘activity’.
Figura 26 RegisterActivity
En el fragment de ‘Perfil’ en primer lugar se ejecuta el handle donde se reciben los datos del
usuario y después se setea la vista y se inicializan los controles con la información que se
recoge mediante el tratamiento del token recibido del ‘viewmodel’.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 31
Figura 27 ProfileFragment
En el caso del fragment de las habitaciones al registrar el ‘observable’ cogeremos tanto el
listado de habitaciones como las fechas de check-in y check-out. Y dependiendo de las fechas
obtenidas se mostrarán las habitaciones del hotel que tengan disponibilidad.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 32
Figura 28 RoomsFragment (1)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 33
Figura 29 RoomsFragment (2)
Para el caso de abrir la habitación mediante la tecnología NFC lo que se ha hecho ha sido
introducirlo en el MainActivity como un caso de uso. Se utiliza el mismo patrón MVVM, hace
un observable para procesar la cerradura y se hace otro caso de uso para verificar NFC y otro
para iniciar el proceso de validación. Todo ello se hace a través de la clase ‘ReaderNfcUseCase’.
En primer lugar en MainActivity se comprueba que el dispositivo tiene tecnología NFC. En caso
de no estar disponible se muestra un mensaje de error indicando que algunas funciones de la
aplicación no podrán ser utilizadas. Es decir, se podría hacer uso de todos los servicios que
ofrece la aplicación excepto abrir la puerta de la habitación. En caso de que el dispositivo
disponga de la tecnología pero ésta se encuentre desactivada la aplicación invitará al usuario a
que la active.
Por otro lado, al leer una etiqueta NFC, Android permite poder elegir con qué aplicación leerlo.
Para evitar tener que estar seleccionando la propia aplicación Android permite poner la
aplicación como prioritaria mientras esté abierta.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 34
En este caso en el handle se trata la posibilidad de iniciar la aplicación por una lectura de una
cerradura o porque se arranque manualmente. Esta lógica de búsqueda de ejecución se debe
hacer en un hilo aparte para no bloquear la aplicación. Para ello se ha creado una utilidad
llamada ‘TaskRunner’ que hace que se ejecute el objeto que queremos. Esto nos permite
comprobar que lo que se lee es lo que se espera leer.
Por último leemos los datos por NFC. En este proyecto como no se ha podido contactar con
varios hoteles se ha implementado mediante unas etiquetas NFC programables en las que se
ha introducido un archivo de texto con el id del hotel y el número de habitación. Al leer la
etiqueta vemos primero que efectivamente estamos leyendo un texto, sacamos el texto y se
ve si es válido o inválido.
Figura 30 ReaderNfcUseCase (1)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 35
Figura 31 ReaderNfcUseCase (2)
Una vez leída la información de la etiqueta vamos a la validación. Primero se comprueba que
efectivamente haya una lectura no vacía y después se comprueba que esa información se
encuentra dentro de las habitaciones que puede ver ese usuario. En caso correcto se manda la
información de que la etiqueta es válida y se pasa también la información de que se ha
completado con éxito para luego en el MainActivity pase la información al ‘Dialog’ creado para
indicar al usuario si la puerta es correcta o no. Por último en función de si es válido o no el
‘Dialog’ mostrará una descripción de aprobación o un mensaje de fallo con
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 36
Figura 32 VerifyNfcUseCase
A continuación comenzaremos a detallar la actividad del pago. En primer lugar al igual que en
el resto de actividades se registran los ‘observables’. En este caso hay tres: uno de
inicialización, otro para el pago y otro para la confirmación del pago. Esto se hace porque para
la transacción se necesita tener un ‘customer’. Como la información puede no haber llegado o
no haberse procesado lo que se tiene que hacer es crear la transacción. Esta creación de la
transacción llama al servicio del servidor. Esto nos da un identificador de la transacción y una
clave de cliente. Con esta información se inicia el proceso en Stripe, que es quien trata la
información. Es decir, una vez seteada la información se envía a Stripe.
La llamada primera que se ha hecho para crear la transacción se utilizará para confirmar el
pago. En caso de hacer el envío sin tener la información lo que pasará es que no se va a poder
controlar el proceso. Es por ese motivo es necesario el ‘observable’ de inicialización del
proceso. Cuando Stripe termine su proceso en el que la aplicación no tiene ningún control se
va a ejecutar el onActivityResult para recoger el resultado de la transacción y confirmar que el
pago se ha realizado.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 37
Ahora falta comprobar que el pago es correcto. Para ello invocamos con el id de la transacción
y la clave de cliente mediante la llamada de postCompleteTransaction. Una vez confirmado el
pago hacemos en el handle el tratamiento del token y se vuelve a la ventana que estaba
abierta recargando la página con los nuevos datos.
Figura 33 PaymentActivity (1)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 38
Figura 34 PaymentActivity (2)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 39
Figura 35 PaymentActivity (3)
Una vez detallado el funcionamiento de la aplicación vamos a entrar a explicar los ‘Adapter’
que nos encontramos en la parte de reservas, hoteles y habitaciones. Los ‘Adapter’ se utilizan
para crear listas mediante ‘RecicleView’. Antiguamente en Android existían los ‘ListView’ que
fueron sustituidos por estos ‘RecicleView’. Esto lo que hace es permitir crear una lista que
tiene un diseño concreto. Una vez creada la lista se recupera su información mediante el
método ‘viewHolder’. Al mostrar los elementos se mostrarán los que caben en la pantalla. La
acción se ejecutará un número de veces igual al número de elementos de la lista que caben en
la pantalla. El ‘Adapter’ también se encarga de que al ir el usuario navegando por la lista las
imágenes se carguen correctamente según la necesidad.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 40
Figura 36 Ejemplo de ‘Adapter’ creado para la lista de reservas del cliente
Por último tenemos una clase con diversas utilidades como pueden ser mostrar los ‘Dialog’ y
toasts, mostrar errores, para setear, recuperar o eliminar la token, para convertir un string en
un errorCall o para formatear la fecha a un patrón que se defina.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 41
Figura 37 Utils.java (1)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 42
Figura 38 Utils.java (2)
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 43
4. Uso de la aplicación Una vez explicados todos los detalles del proyecto de la aplicación se va a proceder a detallar
con varios diagramas cómo es el funcionamiento de la aplicación para el usuario.
4.1 Caso de Uso
Figura 39 Caso de uso de la aplicación
El usuario podrá hacer uso de la aplicación para consultar hoteles, consultar habitaciones
disponibles, reservar una habitación en la fecha que desee y abrir la habitación.
Por otro lado nos encontramos al actor de Stripe que se encargará de procesar el pago
realizado a través de la aplicación.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 44
4.2 Diagrama de flujo
Figura 40 Diagrama de flujo de la aplicación
Una vez el usuario accede a la aplicación tiene varias opciones. La primera opción es consultar
la lista de hoteles donde poder alojarse. Dentro cada hotel de esa lista podrá ver las
habitaciones disponibles para la fecha que desea. En caso de que quiera hacer una reserva
deberá iniciar sesión si es que no lo ha hecho al entrar en la aplicación. Una vez que el usuario
inicie sesión podrá hacer uso de todas las funcionalidades de la aplicación. Podrá consultar los
hoteles al igual que cuando no estaba registrado, podrá reservar una habitación, consultar las
habitaciones que tiene reservadas y también podrá abrir la habitación.
4.3 Navegación Desde hace un tiempo la herramienta de Android Studio muestra un esquema de cómo queda
la navegación dentro de la aplicación.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 45
Figura 41 Diagrama de navegación
Como se puede ver la navegación del usuario en la aplicación queda de la siguiente forma:
- Hay tres pantallas principales: hoteles, reservas y perfil.
- De la ventana de hoteles sale otra ventana que es la de las habitaciones del hotel
seleccionado.
- La ventana de reservas mostrará las habitaciones reservadas por el usuario.
- Por último la ventana de perfil mostrará la información del usuario así como una
opción de cerrar sesión.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 46
5. Diseño final A continuación se muestran todas las ventanas diseñadas para la aplicación:
Figura 42 Pantalla de Login/Registro
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 47
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 48
Figura 43 Pantalla de Registro
Figura 44 Pantalla de Perfil
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 49
Figura 45 Pantalla con la lista de hoteles
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 50
Figura 46 Pantalla con la lista de habitaciones disponibles
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 51
Figura 47 Pantalla de la pasarela de pago
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 52
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 53
Figura 48 Confirmación de pago realizado
Figura 49 Pantalla de habitaciones reservadas por el usuario
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 54
6. Futuros desarrollos Esta aplicación tiene mucho potencial. Podría cambiar la forma en que los viajeros, tanto
turistas como gente de negocios, se hospedan en los hoteles alrededor de todo el mundo. Para
llegar a ese objetivo es necesario implementar funcionalidades que no se han implementado
en este proyecto.
En primer lugar implementar un webhook para consultar al hotel la disponibilidad de las
habitaciones, el precio, etc. Como para este proyecto no se puede hablar con los hoteles por
eso se ha creado el directorio privado. La solución sería que el endpoint donde se ven las
habitaciones disponibles se pudiese comunicar con un endpoint que tuviese el hotel con esa
información.
Otra funcionalidad a optimizar sería la apertura de la puerta. Al ser esto un proyecto
universitario la lectura de la cerradura por NFC se ha decidido implementar de forma sencilla.
Lo que se ha hecho es que cada etiqueta NFC se configuraba con el id del hotel y el número de
la habitación. Lo ideal sería que el hotel proporcionase a la aplicación, llegado el día de check-
in, la firma NFC con la que se puede abrir la habitación. En la actualidad hay muchos hoteles
que disponen de este servicio de apertura NFC mediante tarjetas configurables. Lo único que
habría que hacer sería que lo que se tuviese que configurar no fuese la tarjeta, sino que esa
configuración se transmitiese a la aplicación.
Otra funcionalidad no contemplada ha sido la de añadir varios huéspedes a la reserva. En
algunos países, como por ejemplo España, los hoteles tienen la obligación de registrar a todos
los huéspedes que se hospedan cada noche. Para asegurar la confidencialidad este registro no
lo haría el hotel, sino que sería la propia aplicación la que registrase los datos de cada
huésped.
Por último una funcionalidad que no se ha contemplado es el caso de que dos personas estén
reservando habitación y sólo haya una disponible. Lo que habría que hacer sería modificar el
servidor para que en cuanto una persona empiece el proceso de reserva esa habitación quede
bloqueada. Se asignaría esa habitación durante un tiempo al usuario. En caso de no seguir
durante un tiempo se cancela y la habitación pasa a estar libre.
Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación – Universidad Politécnica de Madrid -PFG Página 55
7. Bibliografía
[1] Miguel Figuerola. Evolución del turismo en España durante el año 2018
https://mesadelturismo.org/wp-content/uploads/2019/01/ANALISIS-DE-LA-COYUNTURA-
TUR%C3%8DSTICA-EN-ESPA%C3%91A-DURANTE-EL-A%C3%91O-2018.pdf
[2] A. Díaz. Número de pernoctaciones durante los viajes de negocios de los residentes en
España del primer trimestre de 2017 al segundo trimestre de 2019, según destino. Oct. 2019
[3] Alfonso Casas. iPhone vs Android: cuota de mercado. Feb. 2019
[4] https://androiddistribution.io/#/
[5] Herramienta Node.JS https://nodejs.org/es/
[6] Librería Total.JS
https://docs.totaljs.com/latest/en.html#pages~Directory%20structure~(directory~databases)
[7] https://ngrok.com/product
[8] https://docs.microsoft.com/es-es/xamarin/xamarin-forms/enterprise-application-
patterns/mvvm
* MomentJS: https://momentjs.com/ (Tratamiento de fechas)
* Stripe: https://stripe.com/docs/api (Implementación del pago)
* Lectura de NFC: https://code.tutsplus.com/es/tutorials/reading-nfc-tags-with-android--
mobile-17278
* Libreria Okhttp: https://square.github.io/okhttp/ (para las comunicaciones http)
* Libreria Glide: https://bumptech.github.io/glide/
* Libreria de Stripe: https://stripe.com/docs/libraries
* Uso de Stream (Java8): https://github.com/aNNiMON/Lightweight-Stream-API
Top Related