Aplicación de gestión de reservas y huéspedes de hotel

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


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.


Í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


Í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 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


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


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


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


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.


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.


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.


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


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"}}


Figura 5 Archivo “prepareSQL.js” (1)


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.


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.


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.


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


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”


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.


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.


Figura 15 Función de la transacción en el archivo “defaults.js” (1)


Figura 16 Función de la transacción en el archivo “defaults.js” (2)


Figura 17 Comprobación de la transacción (1)


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


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.


- 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.


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).


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


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’.


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.


Figura 28 RoomsFragment (1)


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.


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)


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


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.


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)



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.


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.


Figura 37 Utils.java (1)


Figura 38 Utils.java (2)


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.


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.


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.


5. Diseño final A continuación se muestran todas las ventanas diseñadas para la aplicación:

Figura 42 Pantalla de Login/Registro


Figura 43 Pantalla de Registro

Figura 44 Pantalla de Perfil


Figura 45 Pantalla con la lista de hoteles


Figura 46 Pantalla con la lista de habitaciones disponibles


Figura 47 Pantalla de la pasarela de pago


Figura 48 Confirmación de pago realizado

Figura 49 Pantalla de habitaciones reservadas por el usuario


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.


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

Aplicación de gestión de reservas y huéspedes de hotel

Documents

Transcript of Aplicación de gestión de reservas y huéspedes de hotel