Embed Size (px)
Citation preview
Exploratu
Grado en Ingeniería Multimedia
Trabajo Fin de Grado
Autor: Izadi Egizabal Alkorta
Tutor/es: José Vicente Berná Martínez
Junio 2019
App para la conversión de
divisas usando OCR y AR
1
2
Aplicación móvil para la conversión
de divisas usando OCR y AR
Autor
Izadi Egizabal Alkorta
Tutor
José Vicente Berná Martínez Departamento de Tecnología Informática y Computación
GRADO EN INGENIERÍA MULTIMEDIA
3
4
Resumen
El mundo se está haciendo cada vez más pequeño gracias al creciente número de viajes
que la gente realiza, entre otros factores. Esto se debe en gran parte por la disminución
de los costes, así como el incremento de las facilidades de las que se dispone.
Similarmente, la gran adopción de los smartphones permite tener toda la información
que se pueda querer o necesitar en la palma de las manos. Por lo tanto, es esperable
que el número de soluciones para ayudar a este sector cada vez sean más.
Una de las cosas que más se suele necesitar en un país extranjero es un conversor de
divisas, es esencial saber cuánto cuesta cada cosa en la moneda que más se esté
acostumbrado. Por tanto, es normal que las tiendas de aplicaciones estén inundadas de
soluciones para esto.
Desafortunadamente, todas esas aplicaciones son casi idénticas y su experiencia de
usuario no ha cambiado desde sus primeras versiones de hace años. Están basadas en
la entrada manual de la información y no aprovechan las características que estos
dispositivos ofrecen.
Por lo tanto, el objetivo principal que plantea este proyecto es poder automatizar todo
este proceso mediante una aplicación móvil que use los sensores y funciones de los que
estos smartphones disponen para que la experiencia de usuario sea lo más simple y fácil
posible.
En concreto la cámara para la extracción de los precios y la ubicación del dispositivo, así
como su configuración, para la obtención de las divisas entre las cuales se quiere realizar
la conversión.
De esta manera, poder realizar dicha conversión y mostrar el resultado en Realidad
Aumentada para que no se pierda el contexto y se pueda comparar entre diferentes
conversiones simultáneamente.
5
Abstract
The world is getting smaller and smaller thanks to the increasing number of trips abroad
that people make, among other factors. To a large extent, this is due to the decline in
travelling costs, along with the increasing easiness of doing so.
Similarly, the mass adoption of smartphones allows people to have all the information
that they may want or need in the palm of their hands. Hence, it is expected that the
number of solutions for this sector is ever so increasing.
One of the things that are mostly required when visiting a foreign country is a currency
converter. It is crucial to know how much things cost in the money that one is familiar
with. As such, it is foreseen that the app stores are filled with solutions for this.
Unfortunately, all these apps are almost identical, and their user experience has not
changed from their first iterations, a long time ago. They are based on the manual input
from the user and do not take advantage of the features that these devices offer.
Therefore, the main objective that this project has is to automatise all the process via a
phone app that uses the sensors and features that these smartphones have, to make the
user experience as frictionless as possible.
Specifically, the camera for extracting the prices and the location of the device, along
with their configuration, to obtain the currencies among which the conversion wants to
be performed.
Consequently, the exchange can be determined, and the result displayed in Augmented
Reality. Thus, the original context is not lost, and the outcomes of the different exchanges
can be compared among each other.
6
Laburpena
Gendeak egiten dituen bidaiak handitzen einean, besteak beste, mundua gero eta
txikiagoa antzematen da. Hau, neurri handi batean, kostuen gutxitzeak eta erraztasunak
handitzeak ahalbidetu du.
Bestalde, smartphoneen zabaltze handiak, behar edo nahi den informazio guztia denon
eskuetan edukitzea posible egin du. Horregatik, ez da harritzekoa sektore honi
laguntzeko soluzioak gero eta gehiago izatea.
Kanpoko herrialde batean gehien behar izaten den gauzetako bat diru aldaketa nola den
ezagutzea da, beharrezkoa izan ohi da zenbat balio duen gauza bakoitzak jakiteak
norberak ezagutzen duen dibisa batean. Beraz, normala da aplikazio dendak honetarako
soluzioz beteta egotera.
Zoritxarrez, aplikazio hauek guztiak oso antzekoak dira, eta beraien erabiltzaile
esperientziak ez ditu aldaketarik eduki lehen bertsioetatik, hau dela, orain dela urte
askotatik. Eskuz informazioa sartzean daude oinarrituta eta ez dituzte gailu hauek
dituzten ezaugarriak aprobetxatzen.
Ondorioz, proiektu honek planteatzen duen helburu nagusia prozesu hau guztia
sakelakoarentzako aplikazio baten bidez automatizatzea da. Smartphoneen sentsore eta
ahalbideen bidez erabiltzaileen esperientzia ahal bezain sinple eta errazena izan dadin.
Zehazki, kamara prezioak ateratzeko eta gailuaren kokapena, sakelakoaren
konfigurazioarekin erabiliko diren dibisak lortzeko.
Modu honetara, aldaketa egin eta emaitza zuzenean Errealitate Areagotuan (AR)
erakusteko. Horrela testuingurua ez da galtzen eta aldaketa desberdinen artean
konparatu litezke aldi berean.
7
8
Motivación, justificación y objetivo general
La idea de este Trabajo Final de Grado surgió a finales de mi año de movilidad; mientras
viajaba en metro en la ciudad de Shenzhen1, China Continental2, por mi cuenta, como
escapada que hice desde la ciudad adyacente de Hong Kong, lugar donde estaba
realizando el segundo semestre del curso 2017/18 dentro del programa de movilidad
global de la Universidad de Alicante.
Me di cuenta de algo que había estado viviendo todo ese curso que pasé fuera la
península, tenía instaladas diferentes utilidades de cambio de divisas que no me
acababan de convencer y además a veces terminaba consultando en Google muchas
veces porque terminaba antes.
Además, una de las cosas más engorrosas es tener que estar metiendo datos
constantemente en la app para cada cosa que veas. Por ejemplo, en un supermercado
con el tema de precios o el peso de diferentes ítems. Cosa que se podría automatizar
mediante la captura y procesado de la imagen vía la cámara de los móviles.
Igualmente, sé que otros compañeros de movilidad se encontraban en la misma
situación, a veces incluso peor, ya que desconocían la existencia de apps para esta tarea
o simplemente les parecía demasiado complicado/les daba pereza y terminaban
funcionando con aproximaciones, muchas veces erróneas, que los llevó a un par de
sustos. Todo esto me ha animado para llevar a cabo este proyecto y apostar por esta
idea.
En lo personal, me encanta dar la vuelta a algo existente y buscarle una mejor solución,
usando nuevas tecnologías y soluciones para ello. Me considero una persona inquieta,
que tiene que estar en constante evolución y no me puedo resistir a hacer pequeños
proyectos solucionando pequeñas cosas que veo que se podría mejorar. Esto me llevó
hace tiempo a interesarme al desarrollo móvil y pensar en cómo explotar estos
dispositivos que hoy en día todos llevamos con nosotros.
1 Shenzhen ( ): ciudad-subprovincia de 12 millones de habitantes localizada en la costa sur
de la provincia de Cantón, en la República Popular China. 2 China Continental ( ): zona de China bajo la soberanía efectiva de la República Popular
China, sin incluir regiones administrativas especiales de Hong Kong, Macao y Taiwán.
9
Otra de las razones por la que me dispongo a desarrollar este proyecto se debe a la
realización de un curso de introducción al desarrollo Android3 el año pasado, gracias a
una beca entre Google4 y Udacity5, y este año otro más avanzado gracias al mismo tipo
de beca.
Estaba convencido de que quería hacer una aplicación nativa de Android como mi
Trabajo Final de Grado, y así asentar mis conocimientos en este tipo de desarrollos;
realizando un proyecto completo más complejo que las demos que he estado elaborando
hasta ahora. Este sector de la industria me interesa mucho, y es en algo que me vería
trabajando después de graduarme como Ingeniero Multimedio.
Finalmente, gracias a la experiencia de movilidad, primero en Finlandia y después en
Hong Kong, he podido conocer a gente de todo el mundo y me motiva bastante hacer
algo que “nos una” de alguna forma y facilitar la experiencia de viajar a un lugar distinto
mediante la app6.
3 Android: sistema operativo basado en el núcleo Linux orientado especialmente para dispositivos
móviles. 4 Google: compañía principal subsidiaria de la multinacional estadounidense Alphabet Inc., cuya
especialización son los productos y servicios relacionados con Internet. 5 Udacity: organización educativa que ofrece cursos online masivos y abiertos (MOOCs). 6 App: aplicación.
10
Agradecimientos
Quería aprovechar esta oportunidad para agradecer a todo el mundo que ha compartido
conmigo, cada uno de forma diferente, esta larga aventura de cuatro años que ha durado
mi paso por el grado de Ingeniería Multimedia.
En primer lugar, a mis padres y familia, por haberme dejado la libertad total de elegir la
carrera que más me gustase, aunque esto supusiera salir del pequeño pueblo donde
había vivido hasta el momento e irme al lado opuesto de la península, donde no conocía
nada ni a nadie. Milesker por la confianza, apoyo y ánimos que me han dado siempre, por
inculcarme desde pequeño que cada uno tiene que buscar lo que más le haga feliz y
apostar con todo que se tiene por ello.
En segundo lugar, a todos mis compañeros de la carrera, a todos los amigos que he
hecho durante el camino y a la Universidad de Alicante por haber habilitado todo esto.
Nunca pensé que en cuatro años podía crecer tanto como persona, así como conocer
tanta gente y tanto mundo, no podría estar más agradecido de cada momento
compartido con ellos, han hecho que estos cuatro años hayan sido una experiencia
inolvidable.
Finalmente, agradecer al profesorado de la carrera y en especial a mi tutor Jose Vicente
por su paciencia y dedicación; no sólo para guiarme en este trabajo y resolver todas las
dudas que tuviera, sino también por apostar por esta carrera y hacer el cuarto año, con
la metodología ABP, algo único que siempre llevaremos con nosotros.
11
12
Travel is fatal to prejudice, bigotry, and narrow-mindedness.
Viajar es letal para los prejuicios, intolerancia, y mentes cerrados.
Mark Twain
No tengas miedo de crecer lentamente, ten miedo de quedarte quieto.
Proverbio Chino
13
14
Índice de contenidos
1. Introducción ................................................................................................................. 22
2. Estudio de viabilidad ................................................................................................... 24
2.1. Análisis DAFO ....................................................................................................... 24
2.2. Lean Canvas.......................................................................................................... 26
2.2.1. Segmento de Clientes .................................................................................. 27
2.2.2. Problemas ..................................................................................................... 28
2.2.3. Proposición única de valor ........................................................................... 28
2.2.4. Solución ......................................................................................................... 29
2.2.5. Canales .......................................................................................................... 29
2.2.6. Flujos de ingreso .......................................................................................... 29
2.2.7. Estructura de costes..................................................................................... 29
2.2.8. Métricas clave ............................................................................................... 30
2.2.9. Ventaja especial ........................................................................................... 30
2.3. Análisis de riesgos ............................................................................................... 30
3. Planificación ................................................................................................................. 35
4. Estado del arte ............................................................................................................. 38
4.1. Análisis del mercado ............................................................................................ 38
4.2. Tecnologías para crear aplicaciones .................................................................. 42
4.2.1. Desarrollo Nativo .......................................................................................... 42
4.2.2. React Native .................................................................................................. 43
4.2.3. Ionic............................................................................................................... 43
4.2.4. NativeScript .................................................................................................. 44
4.2.5. Xamarin ......................................................................................................... 44
15
4.2.6. Flutter ............................................................................................................ 45
4.3. Fuentes de datos .................................................................................................. 46
4.4. Software para OCR ............................................................................................... 48
5. Objetivos ....................................................................................................................... 50
6. Metodología.................................................................................................................. 52
7. Análisis y especificación .............................................................................................. 54
7.1. Definiciones .......................................................................................................... 54
7.2. Características de los usuarios ........................................................................... 54
7.3. Requisitos ............................................................................................................. 55
7.3.1. Requisitos funcionales ................................................................................. 55
7.3.2. Requisitos no funcionales ............................................................................ 57
8. Diseño ........................................................................................................................... 60
8.1. Diseño de la arquitectura conceptual ................................................................. 60
8.2. Diseño de la arquitectura tecnológica ................................................................ 61
8.3. Diseño de la persistencia ..................................................................................... 63
8.4. Guía de estilos ...................................................................................................... 65
8.4.1. Filosofía de diseño ........................................................................................ 65
8.4.2. Logo e iconografía ........................................................................................ 66
8.4.3. Colores .......................................................................................................... 67
8.4.4. Tipografía ...................................................................................................... 67
8.5. Diseño Interacción ............................................................................................... 68
8.6. Diseño Interfaces ................................................................................................. 70
8.7. Diseño de pruebas y validación........................................................................... 73
9. Implementación .......................................................................................................... 76
9.1. Sprint 1: Preproducción ....................................................................................... 76
9.2. Sprint 2: Creación de la estructura base de la app ............................................ 77
16
9.3. Sprint 3: Conversión manual en local ................................................................. 79
9.4. Sprint 4: Selector de divisas ................................................................................ 82
9.5. Sprint 5: Obteniendo las ratios desde internet .................................................. 84
9.6. Sprint 6: Funcionalidad base del modo AR ........................................................ 86
9.7. Sprint 7: Automatización de la selección de divisas y detalles ......................... 88
10. Pruebas y validación ................................................................................................ 92
11. Resultados ................................................................................................................ 98
11.1. Producto Final ...................................................................................................... 98
11.2. Recepción ........................................................................................................... 101
11.3. Coste temporal ................................................................................................... 103
12. Conclusiones y trabajo futuro ............................................................................... 106
12.1. Estado actual ...................................................................................................... 106
12.2. Mejoras y ampliaciones ..................................................................................... 107
12.3. Nociones aprendidas ......................................................................................... 109
Referencias ........................................................................................................................ 110
Apéndice I – Publicación en la Google Play Store .......................................................... 114
17
18
Índice de figuras
Figura 1. Esquema de un análisis DAFO. ........................................................................... 24
Figura 2. Cuadro Lean Canvas de Exploratu. ..................................................................... 26
Figura 3: Llegadas internacionales por regiones del mundo ........................................... 38
Figura 4: Evolución del valor de los servicios y productos exportados ........................... 39
Figura 5: Estado del tablero Kanban en el tercer Sprint. .................................................. 53
Figura 6: Esquema conceptual de Exploratu. .................................................................... 60
Figura 7: Diagrama de la arquitectura de Room ............................................................... 64
Figura 8: Tabla de cambio de divisas ................................................................................. 64
Figura 9: Logo de Exploratu ................................................................................................ 66
Figura 10: Ejemplos de iconos Dual Tone de Google ....................................................... 66
Figura 11: User Journey Map de las apps alternativas ..................................................... 69
Figura 12: Wireframe del modo AR .................................................................................... 70
Figura 13: Wireframe de la selección de divisas ............................................................... 71
Figura 14: Wireframe de la pantalla de conversión manual............................................. 72
Figura 15. Mapa de interacciones ...................................................................................... 73
Figura 16: Activities base de Exploratu ............................................................................. 77
Figura 17: Esquema del funcionamiento del OCR ............................................................ 78
Figura 18: Diseño de las banderas de las divisas ............................................................. 80
Figura 19: Interfaz implementado del modo manual ....................................................... 81
Figura 20: Diagrama comparativo entre el ListView y RecyclerView ............................... 83
Figura 21: Sistema de selección y búsqueda de divisas .................................................. 83
Figura 22: Ejemplo de uso del modo AR ........................................................................... 87
Figura 23: Ejemplo de Tooltip ............................................................................................ 89
Figura 24: Interfaz final del modo AR ................................................................................ 90
19
Figura 25: Realización de pruebas en dispositivos físicos ............................................... 92
Figura 26: Tests Robo en Firebase Test Lab ..................................................................... 93
Figura 27: Resultados de rendimiento en el Google Pixel (API level 26) ....................... 93
Figura 28: Captura de los cuadros de mando de Firebase Crashlytics ........................... 94
Figura 29: Captura de los cuadros de mando de Firebase Performance Monitoring ..... 95
Figura 30: Ejemplo de casos en los que no se ha conseguido un resultado óptimo ...... 95
Figura 31: Aviso pidiendo permiso para usar la cámara .................................................. 98
Figura 32: Posibilidad de darle permiso a la cámara a posteriori .................................... 99
Figura 33: Exploratu avisando de tener cuidado al usar AR ............................................. 99
Figura 34: Modo AR de Exploratu..................................................................................... 100
Figura 35: Algunas opiniones en el Google Play Store ................................................... 102
Figura 36: Resultados del lanzamiento de Exploratu en Product Hunt ......................... 102
Figura 37: Comentarios del lanzamiento de Exploratu en Product Hunt ...................... 103
Figura 38: Capturas del correcto funcionamiento de Exploratu .................................... 106
Figura 39: Modal de alerta avisando de haber entrado en el modo de AR ................... 116
20
Índice de tablas
Tabla 1. Listado de Riesgos. ............................................................................................... 31
Tabla 2. Planificación temporal TFG .................................................................................. 36
Tabla 3: Comparativa de apps de conversión más populares ......................................... 39
Tabla 4: Comparativa de APIs para la obtención de los cambios .................................... 46
Tabla 5: Tipos de usuarios .................................................................................................. 54
Tabla 6: Requisitos funcionales ......................................................................................... 56
Tabla 7: Requisitos no funcionales .................................................................................... 57
21
22
1. Introducción
Hoy en día tenemos toda nuestra vida en nuestros bolsillos; es difícil imaginarse cómo
sería el día a día sin estos pequeños instrumentos que parecen tan indispensables,
cuando la realidad es que hace pocos años sólo unos pocos los tenían.
Cuando viajamos esto no es una excepción, y no es de extrañar que confiemos en los
smartphones7 para que tengan todas nuestras reservas, billetes de autobús, tren o avión
para ser usados de la manera más rápida posible, sin tener que marearnos en una lista
infinita de documentos de papel.
De la misma manera, aprovechando la capacidad de éstos, los cargamos con muchas
utilidades que nos sirven para el viaje, como podría ser una aplicación de mapas, del
metro de la ciudad a donde vamos, diccionarios de frases básicas de otros idiomas;
creamos listas de lugares a visitar, platos que probar, así como números que nos podrían
servir de emergencia entre otras muchas cosas como pueden ser conversores de
unidades, divisas y tallas.
Mi idea original para el Trabajo Fin de Grado era crear una aplicación multifuncional que
pudiera unificar todas estas cosas y simplificar la vida al viajante. Sin embargo, después
de pensarlo mejor y escuchar a las recomendaciones y opiniones de mi tutor, me di
cuenta de que intentar hacer eso era demasiado complejo. Lo más probable es que
terminase juntando muchos problemas sin solucionar ninguno de ellos y más teniendo
en cuenta las características temporales y técnicas de un Trabajo de Fin de Grado.
Intentar hacer una app que sea muy buena en una cosa es suficientemente complicado
para intentar hacerlo para muchas. Además, hacer lo que tenía en mente implicaría
incluir mucho contenido, ya fueran recomendaciones o simplemente datos, lo cual sería
complicado por no decir imposible, ya que además de recogerlo habría que valorar qué
resulta útil y qué no cuando las preferencias de los usuarios cambian enormemente
entre ellos.
Por ello, me centraré en intentar reflexionar y darle una vuelta al funcionamiento de las
apps de conversión de divisas, que se han quedado en las mismas interfaces de siempre
y se podrían mejorar enormemente explotando las características que los dispositivos
7 Smartphone (teléfono inteligente): tipo de ordenador de bolsillo con mayor capacidad de realizar
actividades semejantes a la de una computadora.
23
móviles tienen hoy en día. No hay ninguna razón por la que seguir usando el mismo
sistema de texto cuando estos dispositivos nos ofrecen muchísimo más.
El proyecto se llamará Exploratu, una app que mediante la toma de información de los
sensores de los smartphones facilitará la experiencia de usuario de las apps de
conversión de divisas, haciendo todo el proceso mucho más rápido e intuitivo.
Como eje central e innovador se encontrará el poder hacer dichas conversiones
mediante la captura, procesado y presentación en Realidad Aumentada (AR) usando la
cámara de los smartphones, así como información obtenida mediante el GPS 8 del
dispositivo, facilitando y agilizando toda la tarea.
De esta forma, se abren nuevas posibilidades en todos los aspectos. El usuario
simplemente tendrá abrir la app, apuntar al precio en la moneda extranjera y la app le
mostrará la conversión directamente allí; pudiendo repetir constantemente la operación
sin tener que pararse a introducir datos repetidamente.
Además del mencionado beneficio de eficiencia y rapidez, también nos evitamos la
introducción de cantidades erróneas, obteniendo los datos mediante la cámara en vez
de la acción manual, y la selección de la divisa incorrecta, sabiendo el país, y por tanto la
moneda del lugar en el que el usuario se encuentra mediante el GPS.
Igualmente, se podrá presentar el resultado de una forma mucho más atractiva y fácil
de entender, mostrándolo dentro del mismo contexto de donde se capturado la
información, usando la Realidad Aumentada.
Exploratu significa explorar en euskera y me parece un nombre muy apropiado ya que
ese es su objetivo principal, permitir a la gente conocer nuevos lugares sin sentirse
agobiados por una forma diferente de cuantificarlo.
Es una aplicación que me gustaría haber tenido mientras realizaba mis dos semestres
de movilidad. Del mismo modo, después de hablar con compañeros y amigos de
movilidad nos dimos cuenta de que todos pasamos por situaciones parecidas, por lo que
creo que es un producto que podría tener bastante futuro.
8 GPS: del inglés Global Positioning System, se trata de un sistema de posicionamiento global
basado en satélites.
24
2. Estudio de viabilidad
Antes de continuar con el resto del proyecto, es importante realizar un estudio de
viabilidad de este para poder así analizar el proyecto en sí, y sentar las bases de tomas
de decisiones una vez sabiendo si los objetivos son viables, pertinentes, necesaria.
De la misma forma, es muy interesante elaborar un análisis de riesgos con el objetivo de
poder identificar, analizar y finalmente crear un plan de respuestas a cualquier riesgo o
amenaza que podría surgir durante todo el ciclo de desarrollo, para así mantener en el
plan previsto y alcanzar la meta.
2.1. Análisis DAFO
El DAFO (de las iniciales de Debilidades, Amenazas, Fortalezas y Oportunidades) es una
metodología de estudio de la situación de un proyecto, analizando sus características
internas (Debilidades y Fortalezas) y su situación externa (Amenazas y Oportunidades)
en una matriz cuadrada como muestra la Figura 1.
Figura 1. Esquema de un análisis DAFO.
(Expósito, 2015)
En cuanto al proyecto de Exploratu los cuadrantes serían los siguientes:
25
▪ Debilidades:
- Falta de experiencia en proyectos tan grandes.
- Nuevas tecnologías que no controlo.
- Tiempo limitado de 300 horas para desarrollar el proyecto.
- Incertidumbre en el tamaño del proyecto, y cuánto se podrá realizar como
parte del TFG9.
- Proyecto poco guiado.
- No ser el mejor en cuanto a la organización y distribución del tiempo.
- Presupuesto monetario nulo para el marketing una vez el proyecto esté
desarrollado.
▪ Amenazas:
- Mercado de apps de conversiones saturado.
- Reticencia de los usuarios a la hora de probar nuevas aplicaciones (Comscore
Inc., 2017).
- Circunstancias personales que podrían perjudicar al tiempo que pudiera
dedicar al TFG.
- Realizar una app que no sea suficientemente completa y robusta.
▪ Fortalezas:
- Experiencia mínima desarrollando para Android.
- Facilidad de adaptarse a nuevas tecnologías.
- Interés personal en el desarrollo del proyecto.
- Ser una persona dedicada y cumplidora de objetivos.
- Ser muy autoexigente y detallista.
- Capacidad de hacer frente a adversidades.
▪ Oportunidades:
- Crecimiento rápido en caso de ser una app medianamente exitoso.
- Llegar a mucha gente.
- Desarrollar mis habilidades para desarrollo de apps.
- Poder demonstrar de lo que soy capaz.
- Darme a conocer.
- Proyecto importante para añadir a mi CV10.
9 TFG: Trabajo de Fin de Grado. 10 CV: Curriculum Vitae, currículum.
26
Como conclusión, y teniendo en cuenta la naturaleza del TFG de ser un proyecto nuevo
que llega al mercado, deberíamos optar por una estrategia ofensiva siguiendo el análisis
CAME11.
Con buenas medidas de contención de riesgos que se describen en el punto 2.3 del
trabajo, se pueden corregir y afrontar las debilidades y las amenazas de una manera
bastante efectiva para así potenciar al máximo las fortalezas y poder explotar las
mencionadas oportunidades al máximo.
2.2. Lean Canvas
El Lean Canvas es una de las herramientas idóneas al comienzo de cualquier producto
de carácter innovador. Esto se debe a que permite formular posibles modelos de negocio
de una manera muy visual que permite, no sólo ayudarte a ver cómo será el proyecto de
diferentes ángulos, sino que permite compartir tu visión con otros.
Si usamos el Lean Canvas para analizar el proyecto Exploratu podemos llegar a la
siguiente figura:
Figura 2. Cuadro Lean Canvas de Exploratu.
(Fuente propia)
11 CAME: partiendo del análisis DAFO, CAME (Corregir, Afrontar, Mantener y Explotar) se trata de
un análisis que se realiza para identificar diferentes estrategias para optimizar el modelo de
negocio.
27
De esta manera podemos tener una idea más clara de lo que el proyecto pueda ofrecer,
lo que soluciona y cómo lo hará de una manera muy visual y fácil de ver.
De todas formas, siempre es conveniente analizar en más detalle cada uno de los
aspectos vistos en el Lean Canvas para poder profundizar en la idea en cuestión:
2.2.1. Segmento de Clientes
Clientes
- Viajeros, turistas y expatriados
Serían el grueso de clientes ya que son los que necesitan este tipo de utilidades al
viajar fuera de su casa. Los viajeros, turistas y expatriados se encuentran en
ambientes ajenos a los que suelen estar habituados y por tanto necesitan
conversores para adaptarse a su nuevo entorno y entender lo que equivalen las
cosas.
Es importante que la app desarrollada sea lo más simple posible y fácil de usar ya
que estos usuarios no suelen disponer de altos niveles de conocimientos
tecnológicos.
Visionarios
- Estudiantes de intercambio
Se tratan de unos clientes similares a los viajeros y turistas y muy cercanos a los
expatriados. La diferencia es que al tratarse de personas más jóvenes usan más el
smartphone y están más interesados en encontrar y descargar apps nuevas; un 70%
de jóvenes entre 18 y 34 años están “siempre buscando apps nuevas e interesantes”
frente el 37% de personas entre 35 y 54 años (Comscore Inc., 2017).
Por tanto, serían los que probablemente descubran la app y sean menos reticentes
a probarlos. Además, al estar más tiempo en el país extranjero, que un viajero, por
ejemplo, usarían más características de la app y de una manera más exhaustiva.
- Mochileros
Al estar constantemente cambiando de país necesitan estar al tanto de lo que cuesta
cada cosa y al mismo tiempo de lo que puede equivaler el peso de una comida o ropa
que vayan a comprar. Por tanto y teniendo en cuenta de que su edad media es de
unos 32 años (Holidaysafe, 2017) entran dentro de la horquilla de joven visto en el
punto anterior, serían también de los primeros usuarios en probar la app.
28
Arquetipos
- Gorka, mochilero de 30 años que después de estar unos años trabajando como
asesor legal necesitaba cambiar de aires y replantearse su vida. Por ello se encuentra
actualmente en un año sabático donde ha decidido recorrer Asia para conocer
nuevas culturas y reencontrarse. Lo que más valora es la facilidad de uso de las cosas
y su disponibilidad total.
- Ashley, 24 años. Acaba de terminar su máster en Logística y Cadena de Suministro y
acaba de empezar en su primer trabajo. En él, tiene que con interactuar con
productos de muchos países diferentes y organizar cantidades basándose en la
demanda y el precio. Ashley valora la exactitud y la confiabilidad de los productos y
servicios que usa antes de cualquier cosa. Tampoco dispone de mucho tiempo por
lo que tienen que ser ágiles y familiares.
2.2.2. Problemas
La problemática se puede dividir en tres aspectos:
1. Las alternativas, analizadas en el punto 4.1 de la memoria, son especialmente
engorrosas a la hora de la introducción de datos. La mayoría se han limitado a la
entrada basado en texto, lo cual obliga al usuario estar insertando manualmente
datos constantemente.
2. Este tipo de entrada, además, hace que el usuario pueda cometer algún error al
marcar la cifra que se quiere convertir.
3. Similarmente, el usuario puede no saber o confundirse a la hora de seleccionar
la moneda del que quiere convertir, siendo otro factor de errores y un paso más
que el usuario tiene que realizar.
2.2.3. Proposición única de valor
Crear una app conversor de divisas que ofrezca una nueva experiencia de usuario;
optimizando las interfaces para que sean amigables, intuitivas, su uso requiera el mínimo
esfuerzo y ofreciendo nuevas formas de visualizado. Para ello explotando los sensores
de cámara y GPS además de su gran capacidad de cómputo.
29
2.2.4. Solución
Buscando solución a los tres problemas comentados en el apartado 2.2.2 se ha llegado
a la siguiente solución. Tener una interfaz amigable y usable, actualizado a los últimos
tiempos, adaptado para que sea óptimo en una gran cantidad de dispositivos y que
facilite todas las tareas que se realicen en la app, especialmente los más habituales
como la introducción de datos. Para ello se incorporará sistemas de introducción de
datos dinámicos que harán uso de la cámara y GPS del dispositivo como se explica en el
punto 2.2.9 Ventaja diferencial.
2.2.5. Canales
Al ser un proyecto que nace junto a un TFG no se dispone ningún presupuesto monetario
de marketing, por lo que los canales de distribución se limitarán a aquellos que se tiene
acceso sin tener que invertir dinero. Estos incluyen principalmente las redes sociales
(Twitter, Instagram, Telegram…), el boca a boca y más importante aún, tiendas de
aplicaciones como el Google Play Store. Será importante también hacer una buena
optimización del ASO para poder posicionar bien Exploratu en este último y que la gente
pueda encontrarlo.
2.2.6. Flujos de ingreso
La descarga de la app va a ser totalmente gratuita y en un principio no constará ni de
publicidad ni de compras in-app para sacarle rentabilidad. Esto se debe a que la
monetización no forma parte de los objetivos de este TFG. De todas formas, no se
descarta que, en un futuro, si se quiere continuar con el proyecto, se añadan estas
características.
2.2.7. Estructura de costes
Teniendo en cuenta que la app funciona totalmente en el dispositivo del usuario, no
accede a ninguna API o servicio propio, y los servicios externos que se van a utilizar van
a ser gratuitas, el coste se limitará a los recursos humanos, que sería yo. De todas formas,
no se descarta que en un futuro se pueda hacer uso de algún API de tercero con coste,
así como desarrollar uno propio; que en tal caso se tendría que añadir el coste del
hosting, dominio y demás gastos que acarrearía.
30
2.2.8. Métricas clave
Las métricas claves estarán en constante evolución dependiendo de la maduración del
proyecto, así como necesidades se vayan detectando. De todas formas, unas buenas
métricas para el inicio del proyecto podrían ser las siguientes:
- Instalaciones totales e instalaciones activas.
- Retención del usuario.
- Puntuaciones de las tiendas de aplicaciones como el Google Play Store.
- Número y frecuencia de cierres inesperados y ANR12s.
2.2.9. Ventaja especial
Finalmente, la ventaja especial o diferencial se trataría de explotar las características de
los móviles inteligentes, con la incorporación de elementos de Realidad Aumentada
(AR), Visión por Computador junto con reconocimiento de texto (OCR) y el uso del GPS.
La idea es que se pueda utilizar la cámara y GPS de los dispositivos para acelerar la
introducción de datos en la app y agilizar todo el proceso.
Un uso claro podría ser entrar en un supermercado, de un país que use una divisa
diferente a la tuya, y poder apuntar a etiquetas de precio en la divisa local y que la
aplicación te muestre directamente cuánto sería en tu divisa de origen, en el mismo
feed13 de la cámara mediante AR.
2.3. Análisis de riesgos
A lo largo de un proyecto de estas características (12 créditos que equivalen a unas 300
horas), suele ser adecuado que antes de iniciar nada tengamos en consideración los
riesgos que pueda suceder durante el transcurso de esta, y por ello crear un pequeño
12 ANR: de sus siglas en inglés Application Not Responing se trata de un mensaje de Android que
indica que el hilo de la interfaz (UI Thread) del sistema se encuentra bloqueado durante
demasiado tiempo y que por tanto la aplicación no está respondiendo. 13 Feed: la continua imagen que devuelve el sensor de la cámara. La vista previa de lo que va a
capturar el sensor si se realizase una foto.
31
análisis de riesgos para poder prevenir a lo que podría pasar y poder actuar de manera
efectiva en caso de que sucedieran.
Se ha realizado una simple tabla listando estos riesgos junto con un plan de contingencia
para poder lidiar con la misma.
Tabla 1. Listado de Riesgos.
Posible Riesgo Proba
bilidad
Efectos Plan de Contingencia
Tecnologías y herramientas
Desconocimiento de
las tecnologías a
usar
Muy
Alta
Tolerable Empezar a estudiar las tecnologías
necesarias antes de empezar la fase
de desarrollo para no perder tiempo
en el período crítico.
Perdida de los datos
del servidor
Baja Serio Tener copias de seguridad del
servidor para en caso de que algo
pase con éste poder restaurar los
datos y poner todo en
funcionamiento lo más pronto
posible.
Corrupción de la
última versión del
backup14
Baja Serio Volver a la última versión que no
esté corrupta.
Corrupción de todos
backup
Muy
Baja
Catastrófico Reinstalar la última versión del
código y volver a empezar a
introducir los datos. En caso de falta
de tiempo habría que introducir los
datos mínimos para poder mostrar
el MVP15.
Caída de servicios
externos de los que
Muy
Baja
Serio Desactivar la funcionalidad afectada
e informar a los usuarios de lo que
14 Backup: termino que se usa en inglés para las copias de seguridad. 15 MVP: del inglés Minimum Viable Product o Producto viable mínimo en castellano, se trata de un
producto con las funciones mínimas para satisfacer a los primeros usuarios y conseguir
retroalimentación para el desarrollo futuro.
32
dependa la
aplicación.
está sucediendo. Si el problema se
alarga o persiste, buscar servicios
alternativos para restablecer dicha
funcionalidad.
Restricción de uso
en las APIs16
Alta Tolerable Mirar si las restricciones son
aceptables para el MVP que
estamos realizando. Si lo son seguir
adelante con esa API, si no, buscar
alternativas.
En el proceso de
desarrollo romper
una funcionalidad
mientras se
implementa otra
Muy
Alta
Seria Usar un sistema de control de
versiones como Git, donde poder ir
a cualquier versión anterior donde
ese problema no era presente, y
poder probar que diferentes
funciones funcionan bien entre sí
antes de pasar el código a
desarrollo.
Realizar pruebas de unit testing17 así
como end-to-end testing18.
Conflictos por
archivos temporales
en el gestor de
versiones
Muy
Alta
Tolerable Crear un .gitignore completo y
bien configurado para poder seguir
los archivos necesarios y poder
ignorar los que no. Actualizarlo las
veces que sean necesaria.
No tener suficiente
documentación o
que no esté
actualizado
Alta Seria Para evitar una documentación
desfasada, mantener el presente
documento actualizado con la
mayor frecuencia posible; como
mínimo, cada semana.
Personales
16 API: del inglés Application Programming Interface o Interfaz de programación de aplicaciones
en castellano, se tratan de un conjunto de subrutinas, funciones y métodos que ofrece cierta
entidad para ser utilizados por una aplicación como una capa de abstracción. 17 Unit Testing: realizar pruebas a unidades del código fuente, ya sean métodos, módulos etc. 18 End-to-End (e2e) Testing: pruebas para validar que el flujo completo de una aplicación funciona
como se espera.
33
Enfermedad o lesión
leve
Alta Tolerable Realizar las tareas que se puedan en
el estado en el que me encuentre y
aplazar las otras para cuando me
haya recuperado.
Enfermedad o lesión
grave
Baja Catastrófico Recortar tareas o incluso
funcionalidades de la aplicación
hasta poder adaptarse a la situación
en la que me encuentre. Si estos
recortes harán que el TFG no se
termine como me gustaría aplazarlo
al siguiente curso académico.
Desmotivación Alta Tolerable Crear un equipo de apoyo de
familiares y amigos para en estos
casos hablar con ellos.
En caso de que persista, hacer un
breve inciso en el desarrollo del
proyecto para poder pensar en las
razones que me han hecho
desarrollarlo.
Organizacionales y de estimaciones
Falta de tiempo Muy
Alta
Serio Comprometerme a trabajar cada
semana en el TFG como si otra
asignatura se tratara. Asignarle un
día de trabajo para que ese día
todas las semanas pueda dedicarle
tiempo.
No tener una
planificación
adecuada
Alta Catastrófico Dedicarle el tiempo necesario
creando la planificación del
proyecto; dividir los bloques de la
memoria en tareas más pequeñas
para poder hacer seguimiento y
distribución de las mismas de una
forma acertada.
Variaciones de
carga de trabajo
Muy
Alta
Tolerable Si en una semana por alguna tarea
en otra asignatura no le puedo
dedicar tanto tiempo como lo había
34
debido a
asignaturas
planeado, distribuir lo que tocaba en
las próximas semanas para no ir
retrasado frente a la planificación.
Duda sobre algún
apartado de la
memoria
Muy
Alta
Tolerable Darle un par de vueltas, pero en
caso de que no llegue a una
conclusión preguntarle al tutor al
respecto.
Atasco en alguna
parte del TFG
Alta Serio En caso de que no lo consiga
solucionar pronto, o vea necesario
una opinión externa, preguntar a
algún profesor de cursos anteriores
al respecto.
Sobreestimación de
tareas
Baja Tolerable En caso de sobreestimar las horas,
dedicar las horas restantes a otras
tareas.
Infraestimación de
tareas
Alta Tolerable Subdividir las tareas y aplazar lo
necesario para la siguiente semana.
En caso de no ser posible, se
eliminará dicha tarea.
Requerimientos
Cambio de los
requerimientos
básicos
Baja Catastrófica Cambio en la estructuración parcial
o total de la aplicación. Con los
cambios y/o recortes de
funcionalidades que esto pueda
ocasionar.
Cambio de los
requerimientos
avanzados
Modera
da
Serio Modificar la documentación y añadir
las tareas necesarias. Comprobar y
modificar los requerimientos que se
verían afectados.
35
36
3. Planificación
Para poder llevar a cabo el proyecto y la memoria bajo el tiempo previsto, procederemos
a realizar una pequeña planificación de las diferentes secciones del trabajo para así
ponernos unas fechas límite de cuándo cada tarea o sección tiene que estar finalizada.
Dividiendo el trabajo en las secciones indicadas en la siguiente Tabla 2 tendré más
posibilidades de éxito. Tendré que estar trabajando con constancia y recibiendo
feedback19 del tutor, sin tener que dejar todo para una entrega final, cuando ya sea
demasiado tarde de corregir si hay algún gran error.
Tabla 2. Planificación temporal TFG
Contenidos Tiempo Total Fecha Límite
Motivación, justificación y objetivo
general
Citas
Introducción
Estudio de viabilidad
Planificación
1 semana 7 de junio
Estado del arte
Objetivos
Metodología
Análisis y especificación
1 semana 14 de junio
Diseño 2 semana 28 de junio
Implementación 2 semanas 12 de julio
Pruebas y validación
Resultados
Conclusiones y trabajo futuro
Referencias, bibliografía y apéndices
Agradecimientos
Índices
Resumen
1 semana 19 de julio
19 Feedback: retroalimentación.
37
Teniendo en cuenta que ya he terminado el resto de las asignaturas del curso, me puedo
dedicar completamente a la realización del TFG y de esta manera poder terminarlo a
tiempo para presentarlo en la convocatoria de septiembre.
Para lograr esto, me he tenido que marcar un ritmo bastante frenético de trabajar unas
6h al día, todos los días de la semana, durante casi dos meses. Así alcanzando las 300
horas requeridas para este trabajo.
Cogiendo como unidad base la semana, me puedo dividir el trabajo en pequeñas
iteraciones de una semana, con objetivos claros que completar para el fin de cada una
de ellas. De esta forma, siempre estoy en control del progreso que llevo, si tengo que
ajustar tiempos por posibles retrasos/adelantos y feedback del tutor.
38
4. Estado del arte
A la hora de proceder al desarrollo de cualquier proyecto o resolver cualquier problema
es necesario primero analizar la situación actual del mismo, las soluciones ya existentes
o tendencias del mercado.
Por ello, a continuación, se detallarán varias secciones donde se analizan la situación
actual de la problemática, antecedentes, así como las tecnologías y fuentes de
información que se podrían usar para el desarrollo.
4.1. Análisis del mercado
El turismo sigue en auge, sobre todo el internacional, y no parece que esto vaya a parar
según todo tipo de estadísticas; incluyendo los de la Organización Mundial del Turismo
(UNWTO), que estima que en 2018 hubo 1.400 millones de llegadas internacionales en
todo el mundo (Word Tourism Organization, 2019), adelantándose a las estimaciones
por dos años.
Figura 3: Llegadas internacionales por regiones del mundo
(Our World in Data, 2019)
39
Similarmente, el valor de los servicios y productos exportados no para de crecer en este
mundo en constante globalización.
Figura 4: Evolución del valor de los servicios y productos exportados
(Ortiz-Ospina, Beltekian, & Roser, 2018)
Con toda esta internacionalización, cada vez es más habitual que se interactúe con
divisas de diferentes países, y junto al gran auge de los dispositivos móviles (Ritchie &
Roser, 2018), es normal que soluciones para convertir distintas monedas surgieran tanto
en web, como para estos dispositivos móviles.
Teniendo en cuenta el número de descargas en la tienda de aplicaciones de Android, a
día de hoy (20/06/2019), estas apps de conversión de divisas son los más populares:
Tabla 3: Comparativa de apps de conversión más populares
Nombre Desc
argas
Valor
ación
Entrada de
datos
Características
Xe
Currency
Converter
10M 4.3⭐
Manual con
calculadora
sin vista
previa.
- Soporta las +180 divisas, metales y
alguna criptomoneda.
40
- Enorme cantidad de funcionalidad:
alertas, evolución histórica
(interactiva), análisis del mercado,
enviar dinero, widgets…
- Gran confiabilidad por la gran
experiencia de la compañía (Xe
Corporation).
Easy
Currency
Converter
10M 4.3⭐
Manual con
calculadora
sin vista
previa.
- Soporta las +180 divisas más muchas
criptomonedas y metales.
- Funcionalidad: modo offline, gráfica
histórica (no interactiva), favoritos,
noticias.
- Interfaz anticuada y se siente tosca por
la gran cantidad de pasos que hay que
hacer para las cosas, no tiene
búsqueda de divisas.
Exchange
Rates –
Currency
Converter
5M 4.5⭐
Manual con
calculadora
sin vista
previa.
- Soporta +150 divisas más muchas
criptomonedas, metales incluso
divisas obsoletas.
- Funcionalidad completa con añadidos:
modo offline, evolución histórica
(interactiva), favoritos, explorador y
visualizador de billetes.
- Sencilla interfaz, fácil de usar, con
búsqueda, categorías de divisas /
criptomonedas / metales / obsoletas,
diferentes sistemas de ordenación, de
mostrar la lista…
Currency
Converter
Plus
1M 4.8⭐
Manual con
vista previa,
opción de
usar una
calculadora.
- Soporta 161/32/35 divisas gracias al
selector de API a usar.
- Funcionalidad: modo offline, gráfica
histórica (interactiva pero limitada al
último año), favoritos, búsqueda.
41
Selección de
moneda
mediante
GPS.
- Interfaz que simula una calculadora,
muy sencilla y fácil de usar pero que
ha quedado anticuada, no muestra de
cuándo es el cambio e incluye mucha
publicidad.
xCurrency
– Smart
Currency
1M 4.6⭐
Manual con
calculadora
y vista
previa en
todo
momento.
Selección de
moneda
mediante
GPS.
- Soporta +170 divisas, varios metales y
+130 criptomonedas.
- Enorme funcionalidad y
personalización: ver el cambio que
diferentes APIs dan simultáneamente
(incluyendo emisores de tarjetas como
VISA, Master, Unionpay) y
dependiendo del caso (compra, venta,
media…), grafica histórica (interactiva
y con información del cambio),
favoritos, cambiar unidad base, divisa
base, ver el cambio a todas las
monedas de golpe, búsqueda,
calculadora con grandes funciones…
- Interfaz limpia, sencilla, moderna y
fácil de usar. Tiene muchos gestos, que
si el usuario no entiende pueden
dificultar el acceso a ciertas funciones.
Como podemos observar todos son muy similares, todas las apps tienen más monedas
de los que podríamos querer, algunos incluyendo las criptomonedas o metales. Lo que
cambia son funcionalidades adicionales que pueden ofrecer como las alertas de Xe
Currency Converter, mostrar billetes de las diferentes divisas de Exchange Rate –
Currency Converter o tener una interfaz más moderna basada con gestos de xCurrency.
En cuanto a la entrada de datos, se puede apreciar que todos usan un sistema manual
basado en un teclado, que muchas veces funciona como calculadora a su vez. La única
automatización y facilidad que se le da al usuario se encuentra en Currency Converter
Plus y xCurrency, las cuales tienen la posibilidad de usar el GPS del dispositivo para
detectar en qué lugar se encuentra y seleccionar la divisa de origen a esa, ahorrándole
tiempo al usuario.
42
Por lo tanto, podemos concluir que a efectos prácticos todas las aplicaciones son iguales;
lo que las diferencia son sus interfaces y algunas funcionalidades menores para atraer
más público. No hay realmente ningún elemento innovador o diferenciador que los
separe.
4.2. Tecnologías para crear aplicaciones
Una de las primeras cosas que hay que tener en cuenta es qué tipo de desarrollo se
quiere hacer para la parte final que utilizará el usuario. Se puede tomar la vía natural de
un desarrollo nativo, o probar con una de las muchas herramientas que nos permiten
crear apps más o menos multiplataforma.
En un principio, como se adelantaba en la Introducción, la idea era desarrollar en nativo,
pero sería útil explorar las diferentes opciones antes de tomar una decisión final.
4.2.1. Desarrollo Nativo
El desarrollo nativo de las apps permite conseguir el máximo provecho de la arquitectura
de cada sistema operativo, con acceso directo a todas las APIs que ofrecen en cada
plataforma consiguiendo normalmente una mejor experiencia de usuario.
La gran desventaja es que hay que desarrollar todo el código para cada plataforma
independientemente. Hoy en día, aunque mucho se delegue en servicios web, sigue
estando mucho de la lógica directamente en la app en sí, por lo que supone casi el doble
de trabajo; alargando todo el proceso de desarrollo, haciéndolo más caro y necesitando
aprender diferentes tecnologías propias de cada plataforma: Swift (antiguamente se
usaba Objective-C) para iOS y Kotlin (o Java) para Android.
43
4.2.2. React Native
React Native20 se trata de la respuesta de Facebook a la creación multiplataforma de
aplicaciones para iOS y Android. La idea es usar los mismos conceptos que se usan en
React habitual, biblioteca de JavaScript para la creación de interfaces web, para
trasladarlos a una aplicación móvil.
Al tener el soporte de un gigante como Facebook no es de extrañar que se use en grandes
proyectos como en las propias apps de Facebook, Instagram, Pinterest, Skype o Uber, ya
que si tu aplicación web ya está creado con React o si tu equipo ya conoce la tecnología
no es muy difícil trasladar la experiencia al móvil.
La gran desventaja es que el rendimiento suele deja bastante que desear y nos podemos
encontrar con una navegación poco suave, es bastante más complicado de aprender
(además con poca documentación) y muchas veces se necesita acceder a APIs que no
están disponibles desde JavaScript, por lo que se sigue necesitando experiencia en
desarrollo nativo de iOS y Android.
4.2.3. Ionic
Similar al anterior, Ionic21 sería su “equivalente” para el framework de Angular, el cual
nos permite trasladar la experiencia web a móvil. La diferencia, que en vez de hacer apps
casi nativas, simplemente nos muestra elementos HTML que emulan el funcionamiento
de widgets22 nativos.
Entre las ventajas nos encontramos que comparte una sola base de código para todas
las plataformas compatibles (iOS, Android, Windows UWP, Web, Electron o PWA entre
otros), poder usar tecnologías web que son conocidas para su desarrollo, mediante los
componentes ya creados acelerar el proceso de desarrollo y ofrecernos una curva de
aprendizaje bastante asequible.
20 https://facebook.github.io/react-native/ 21 https://ionicframework.com/ 22 Widget: elemento de una interfaz de usuario gráfico que muestra información o permite una
forma específica de interactuar con el sistema.
44
Como gran desventaja sería otra vez el rendimiento, ya que al fin y al cabo abre una vista
web (WebView) para ejecutarse. Esto se ve agravado por las limitaciones de funciones
específicas de cada sistema operativo que se enfrenta Ionic.
4.2.4. NativeScript
NativeScript 23 es la alternativa de Ionic para la creación de aplicaciones móviles
mediante el uso del framework de Angular, aunque ahora también es compatible con el
creciente en popularidad framework Vue.js.
La principal diferencia es que en este caso sí que se consigue acercarse a un rendimiento
nativo gracias al uso de componentes propios de los sistemas de despliegue, Android y
iOS. Además, aunque la comunidad no sea tan grande como la de React Native, gracias
a su buena documentación lo hacen una opción muy a considerar.
Entre las desventajas, la principal es que al tener que seguir usando un motor de
JavaScript para correr la lógica de la aplicación, JavaScriptCore en iOS y V8 en Android,
no consigue el rendimiento y la estabilidad que se puede conseguir con un desarrollo
completamente nativo. Por otra parte, al no tener una comunidad tan grande se pueden
encontrar menos ejemplos de proyectos hechos con NativeScript y por eso se nos podría
hacer más complicado salir de un atasco.
4.2.5. Xamarin
Xamarin24, a diferencia de los tres anteriores, no se trata de un framework o SDK25 que
permite usar tecnologías de la web en formato de app, sino que permite compartir la
gran lógica detrás de las apps entre las tres plataformas más importantes, iOS, Android
y Windows UWP, desarrollándolo en C# y .NET.
23 https://www.nativescript.org/ 24 https://visualstudio.microsoft.com/xamarin/ 25 SDK: del inglés Software Development Kit se tratan de sets de programas, herramientas y APIs
que permite desarrollar soluciones para cierta plataforma.
45
De esta manera, más del 75% del código es común para todas las plataformas y sólo hay
que implementar ese 25% específico de cada uno, incluyendo las llamadas a las APIs
propias o alguna característica no común con el resto. Además, si se usa el módulo de
Xamarin.Forms para crear las interfaces de usuarios, se puede ampliar hasta un 96% la
compartición de código.
Entre las ventajas destacamos que los proyectos Xamarin se compilan a código nativo
de cada plataforma y usa widgets específicos de cada, consiguiendo un rendimiento muy
bueno que se asemeja a una solución totalmente nativa. Como añadido, cuenta con el
apoyo de Microsoft por lo que se integra con sus IDEs26 como Visual Studio y otros de sus
servicios los cuales son muy familiares para muchos desarrolladores.
Como puntos negativos encontramos que hay que programar en C# y .NET, lo cual
supone una curva de aprendizaje para los que no estén familiarizados con los mismos, y
que, aunque el rendimiento sea casi nativo, aún corre sobre el entorno de ejecución, o
runtime, de Xamarin, alargando los tiempos de carga y engordando el tamaño final de la
app.
4.2.6. Flutter
Flutter27 es la respuesta de Google a la creación de una única app multiplataforma, en
este caso para iOS y Android de momento. Respecto a su funcionamiento, utiliza el
lenguaje de programación Dart para conseguir ese cometido, y gracias a su motor de
renderización propio de alto rendimiento (basado en C++) y sus widgets, consigue un
rendimiento similar al nativo. Utiliza una filosofía de diseño similar a React, y por lo tanto
React Native; que pese a que todavía se encuentre en fase beta28 ya se está convirtiendo
un competidor serio para éste.
Entre sus ventajas se incluye la función de recarga en caliente (hot reload en inglés) lo
cual permite ver el resultado del código en tiempo (casi) real, widgets ya creados que
permite agilizar todo el proceso de desarrollo, acceso a funciones nativas e incluso
reutilización de código ya nativo, lo cual permite crear partes de la app en Flutter y no
26 IDE: del inglés Integrated Development Environment es una aplicación de software que
proporciona herramientas y facilidades para la creación y desarrollo de software. 27 https://flutter.dev/ 28 Beta: segunda fase de desarrollo que sigue a la fase Alpha. Normalmente el software cuenta
con las funciones requeridas, pero suele contener bastantes fallos y problemas de optimización.
46
tener que implementar todo de cero; soporte oficial por parte de Google asegurando su
suporte y un equipo de desarrollo dedicado, fácil instalación y comienzo de desarrollo
etc.
La primera y gran desventaja es que el framework es relativamente nuevo, de hecho,
justo acaba de entrar en la fase beta, por lo que todavía necesita tiempo para madurar y
eso se nota. Para empezar, sólo se puede desplegar en dos plataformas, si se quiere
portar a la web u otra plataforma que no sea iOS o Android ya no nos valdría.
Lo segundo es que al ser un framework nuevo no cuenta con demasiadas bibliotecas de
terceros, aunque tenga un montón desarrolladas por Google, lo cual hace que el propio
desarrollador tenga que implementar por sí mismo muchas de las funciones que en otras
plataformas podría estar utilizando las ya creadas y mantenidas por otras personas.
4.3. Fuentes de datos
Para que cualquier aplicación de conversión de monedas sea confiable es esencial
asegurarse de que el cambio se hace de una manera precisa y con datos confiables.
La manera de asegurarse de ello es conectándose a alguna fuente de datos externo que
nos pueda proveer estas ratios de conversión. Entre las más usadas y conocidas nos
encontramos con las siguientes:
Tabla 4: Comparativa de APIs para la obtención de los cambios
Nombre Divi
sas
Fuente(s) Actualiz
aciones
Precio
Exchange
Rates API 32
Banco Central
Europeo (ECB)
Días
laborales
Gratuito sin límite de llamadas.
Fixer +170 Agregación de
diversas fuentes
Cada:
- 1 hora
- 1 hora
- 10 min
- 60s
Precio por mes:
- 0$ - 1.000 llamadas/mes.
- 10$ - 10.000 llamadas/mes
- 40$ - 100.000 llamadas/mes
- 80$ - 500.000 llamadas/mes
Currency
Layer 168
Agregación de
diversas fuentes
Cada:
- Día
Precio por mes:
47
- Hora
- 10 min
- 60s
- 0$ - 250 llamadas/mes
- 10$ - 10.000 llamadas/mes
- 40$ - 100.000 llamadas/mes
- 80$ - 500.000 llamadas/mes
Open
Exchange
Rates
+200 Agregación de
diversas fuentes
Cada:
- Hora
- Hora
- 30 min
- 5 min
Precio por mes:
- 0$ - 1.000 llamadas/mes
- 12$ - 10.000 llamadas/mes
- 47$ - 100.000 llamadas/mes
- 97$ - ilimitadas llamadas/mes
Xe
Currency
Data API
+170
Agregación de
+100 fuentes y
corrección de
errores en
tiempo real
Cada día /
60s
Precio por año:
- 799$ / 1.199$ - 10.000
llamadas/mes
- 1.199$ / 1.799$ - 30.000
llamadas/mes
- 3.999$ / 5.999$ - 100.000
llamadas/mes
- 7.999$ / 11.999$ - ilimitadas
llamadas/mes
VISA API +180 Su cambio
propio Cada día
Gratuito sin límite de llamadas.
No muestra lista con todos, hay
que realizar llamadas
individuales.
Mastercard
API +150
Su cambio
propio Cada día
Gratuito sin límite de llamadas.
No muestra lista con todos, hay
que realizar llamadas
individuales.
Teniendo en cuenta que el 98.95% (Bank For International Settlements, 2016) de todos
los cambios de divisas se realizan entre sólo 35 monedas, frente a las 180 divisas totales,
y dado su naturaleza gratuita, ilimitada y fiable gracias a estar basado en datos del Banco
Central Europeo, para este proyecto, vamos a usar como fuente de datos el Exchange
Rate API.
48
De todas formas, todas las fuentes mencionadas ofrecen una interfaz muy parecida por
lo que cambiar de API debería resultar ser tarea sencilla en caso de avería o deprecación
del servicio elegido.
4.4. Software para OCR
Como se ha adelantado en los apartados de Introducción y Estudio de viabilidad, el
apartado diferenciador del conversor de Exploratu se trata de poder automatizar el
proceso de introducción de datos mediante Visión por computador, en concreto
mediante el Reconocimiento Óptico de Caracteres (OCR).
Hay bastantes soluciones en el mercado que realizan estas tareas en la nube, como
Microsoft con su Azure Cognitive Services Computer Vision API o Google con el Google
Cloud Vision API, que detectan una gran variedad de idiomas y caracteres con gran
acierto, gracias a completos y robustos modelos de ML que tienen en sus servidores.
Pero partiendo de la idea de que Exploratu sea una app que se pueda usar en viajes,
implica que debemos limitar el uso de internet a lo esencial, y poder ofrecer un modo
offline. Por ello, debemos restringirnos a servicios que procesen la información en local
y nos puedan dar una respuesta sin mandar la información a sus servidores.
De esta forma hay dos librerías que se pueden implementar con relativa facilidad en
Android. La librería de Tesseract y Google ML Kit Text Recognition (OCR), esta última
sucesora de la librería Google Mobile Vision.
Tesseract29 se trata de una librería de código abierto que ofrece una solución muy abierta
para los usuarios. Aunque existan varios modelos preentrenados hechos para reconocer
más de 100 idioma, se puede entrenar para que se ajuste a las necesidades de cada uno.
Hay varias implementaciones para Android, siendo la más usada Tess-Two, que añade
varias facilidades encima de lo que Tesseract ofrece nativamente, adaptándolo para su
uso en dispositivos móviles.
Google ML Kit Text Recognition30, disponible para funcionar de manera tanto local como
en la nube, se trata de la evolución de la clásica librería Google Mobile Vision. Forma parte
29 https://github.com/tesseract-ocr/tesseract/wiki 30 https://developers.google.com/ml-kit/vision/text-recognition/
49
de la nueva familia de herramienta de ML Kit de Google, que ponen a mano de
desarrolladores muchas funcionalidades de Machine Learning sin deber tener grandes
conocimientos de este. Permite gran exactitud en sus resultados, su tamaño es bastante
reducido y al estar pensado para dispositivos móviles es relativamente fácil su
implementación.
Teniendo en cuenta que la API de Google es más exacta (Sajjad, 2018) (Leung, 2017),
ocupa menos y es más sencillo de integrar en una app de Android, no hay ninguna ventaja
aparente para usar la API de Tesseract, aparte de que sea de código libre.
50
5. Objetivos
En este apartado se detallan los objetivos que se han marcado como metas en este TFG.
Para ello se ha intentado que cumplan el principio SMART31 asegurándonos que sean
objetivos que nos aporten valor y ayuden a definir el proyecto.
El objetivo es la creación de una herramienta que permita a cualquier usuario realizar
una conversión de divisas, de forma ágil, con la mínima posibilidad de error y una gran
experiencia de usuario. Como subobjetivos se plantea:
- Que la herramienta ofrezca una interfaz de introducción de datos alternativa a las
tradicionales basadas en texto por teclado, para en primer lugar impedir la
equivocación al introducir cantidades, y en segundo lugar agilizar la conversión de
múltiples cantidades. Para ello se basará en tecnologías como OCR.
- Que haga uso de la sensorización y conectividad inteligente de los teléfonos móviles
para automatizar en lo posibles las tareas de selección de moneda y tipo de cambio,
haciendo uso de la geolocalización (GPS) y fuentes de datos confiables en Internet.
- Ofrezca al usuario una experiencia enriquecida haciendo uso de nuevos paradigmas
de interfaz como es la Realidad Aumentada.
Durante el camino para conseguir éste, también se han marcado otros subobjetivos que
me gustaría cumplir con este proyecto. El primero, poner en práctica todo lo aprendido
durante el grado, desde el análisis de una problemática y su posterior idea de solución,
a la realización de ésta pasando por todas las fases de diseño, implementación, testeo y
validación.
De esta manera terminando el grado con un proyecto creado íntegramente por mí y
demostrando de una forma tangible lo que soy capaz de hacer como Ingeniero
Multimedia. Sería junto al proyecto ABP32 el segundo producto grande para añadir a mi
portafolio para que las empresas puedan verme como un buen candidato.
31 Principio SMART: del inglés Specific, Measurable, Assignable, Realistic, Time-related, son
características que un objetivo debería tener para cumplir este principio. (Doran, 1981). 32 ABP: siglas de Aprendizaje Basado en Proyectos que hace referencia al método de aprendizaje
usado en el último año del grado de Ingeniería Multimedia en la Universidad de Alicante, donde
se evalúa exclusivamente por trabajos realizados.
51
Siguiendo con el anterior, para poder hacer un desarrollo completo de una app, también
pretendo que la aplicación sea finalmente publicada en la Google Play Store, la tienda de
aplicaciones por excelencia de la plataforma Android, para que todo el mundo pueda
descargar y probar por sí misma el resultado de este proyecto.
Para eso, otro de los objetivos que se han marcado es que Exploratu sea una aplicación
totalmente funcional y que la gente realmente lo pueda usar, que no sea una simple
demo. Por ello, me he propuesto integrarlo con servicios externos para poder analizar el
comportamiento de los usuarios y así poder seguir mejorando el servicio una vez
terminado el TFG. Todo esto con la idea de que esto sea la base de un proyecto más
grande y que lo pudiera seguir mejorando y ampliando funcionalidades.
52
6. Metodología
La manera de trabajar que se seguirá para desarrollar el trabajo será una metodología
ágil33 basado en Scrum34. No será Scrum completamente ya que no se van a aplicar todas
las restricciones que éste cuenta, principalmente porque yo seré el único miembro del
equipo, junto a los consejos y direcciones del tutor.
De esta manera, se establecerán iteraciones o sprints que cogerán tareas de la pila de
tareas por hacer o producto backlog para realizarlos durante dicha iteración. A
continuación, usando un tablero del estilo de Kanban35, se irá marcando cuáles quedan
pendientes, están en marcha y cuáles están ya terminadas. Importante para este último
definir cuándo una tarea esté terminada; en nuestro caso cuando esté implementada /
realizada y testeada / revisada.
Al final de cada iteración se verá cómo ha ido dicho sprint, los problemas que ha habido
y cómo mejorar el proceso para ser más eficientes, pilar de cualquier proyecto ágil (Beck,
et al., 2001). Estos sprints serán los definidos en la sección de Planificación de esta
misma memoria, aunque se subdividirán en diferentes subtareas.
Entre las cosas que no se seguirán de la estricta metodología Scrum están la separación
de los tres roles que suele haber, el Product Owner (el cliente o el que tiene la visión del
proyecto), el Scrum Master (el facilitador del proceso de Scrum) y el equipo. Al ser el
único que desarrollará el proyecto asumiré estos tres roles.
De la misma forma, al tratarse de un proyecto individual y de no de gran tamaño, para
optimizar el tiempo no se crearán gráficas de burndown (gráficas de tareas terminadas
durante la iteración).
Similarmente, para no tener tantas restricciones como en un Scrum puro, se cogerán
algunas características de la filosofía Lean36. De esta forma, se podrán añadir ítems a un
sprint ya en curso si se ve que hay tiempo para hacer más entre otras cosas. Por lo tanto,
aunque haya sprints definidos habrá una tabla en constante movimiento como en la
33Ágil: filosofía de desarrollo basado en iteraciones de ciclos completos de desarrollo. 34Scrum: metodología ágil basado en historias de usuarios, o cosas que los usuarios quieren tener. 35 Kanban (看板): metodología de desarrollo basado en la filosofía Lean. 36Lean: filosofía de desarrollo basado en el valor percibido del cliente donde se enfocan los
procesos principales a que este valor vaya incrementando continuamente sin tener ningún
residuo. La filosofía ágil nace a partir de esta filosofía (RealtimeBlog).
53
metodología Kanban con sus fases de por hacer, en desarrollo, y hechos (pero sin sus
limitaciones de WIP, o trabajo en marcha).
De todas formas, para ayudar a eliminar la incertidumbre que puede traer un proyecto
ágil, antes de comenzar a implementar nada, se especificarán las características básicas
que se quiere que el producto mínimo viable tenga, siguiendo un poco la metodología de
desarrollo en cascada37.
En cuanto a las herramientas que se usarán, para el tablero Scrum/Kanban se va a
apostar por no usar ninguna herramienta online, sino que usar el método tradicional de
pared y post-its. Experiencia pasada indica que el tenerlo siempre presente en la
habitación y mover las notas de columna a columna ayuda a visualizar el trabajo
realizado y lo que hay por delante, optimizando así el rendimiento frente a un tablero
online como Trello.
Figura 5: Estado del tablero Kanban en el tercer Sprint.
(Fuente propia)
Adicionalmente, para la organización diaria personal, se integrarán las tareas del TFG en
la app de tareas, Microsoft To-Do. Ésta nos permite marcar objetivos/tarea a muy poco
tiempo (un día) y ayudarán a estructurar el trabajo que se debe realizar cada día para así
no terminar con retraso.
Finalmente, para saber la constancia del trabajo, rendimiento y las horas dedicadas, se
controlará el tiempo empleado a la realización de este Trabajo de Fin de Grado mediante
la herramienta Toggl.
37 Metodología en cascada: metodología de desarrollo lineal donde se realiza por completo una
fase del proyecto antes de proceder a la siguiente.
54
7. Análisis y especificación
Para poder concretar nuestra solución del problema analizado hasta el momento es
esencial analizar, definir y detallar los requerimientos y especificaciones que habrá que
diseñar e implementar en las fases siguientes.
De esta manera quedará claro las funciones y restricciones que contará el proyecto y nos
dará una mejor idea de cómo diseñar la solución adecuada.
Para la realización de esta parte de la memoria se seguirá, de una forma simplificada, el
sistema IEE830; diseñado para asegurar que se recoge siguiendo buenas prácticas estos
requerimientos.
7.1. Definiciones
- Divisa base o destino: divisa que se usará como referencia para el resto de las
conversiones. Se trata de la divisa del usuario al que se quiere convertir. Si queremos
convertir 100 yenes a euros, euro será la divisa base.
- Divisa a convertir o de origen: divisa que se quiere convertir a la divisa base o destino.
En el ejemplo anterior los yenes serían esta divisa.
7.2. Características de los usuarios
Los usuarios serán los que hagan uso de nuestra solución. En nuestro caso el sistema
tendrá dos roles muy separados:
Tabla 5: Tipos de usuarios
Tipo de usuario Administrador
Descripción Propietarios de la plataforma y de mayor nivel de acceso.
Responsable de que el sistema funcione correctamente.
55
Habilidades Alto grado educativo y técnico, experto en el sistema desarrollado
y capaz entender diferentes KPI38s y saber analizar el estado del
sistema en base a éstos.
Actividades Acceso y manejo de cuadros de mando que reportan el estado de
la aplicación para supervisar que todo funciona como esperado.
Tipo de usuario Usuario
Descripción Gran masa de usuarios que usan la plataforma.
Habilidades Conocimientos informáticos básicos. Saben usar un teléfono móvil
y están familiarizados con las aplicaciones.
Actividades Usar la app para convertir los precios que ven mediante la cámara
a la divisa que prefieran.
7.3. Requisitos
En esta sección se detallan todos los requerimientos del sistema propuesto. Se
distinguen dos tipos de requisitos: los requisitos funcionales y los no funcionales.
Como todos los requisitos han de ser identificados con diferentes IDs, se seguirá el
formato de “tipo-usuario-número”. El tipo hará referencia a si es un requisito funcional
RF o requisito no funcional RNF, el usuario al principal usuario para el cual se establece
el requisito, ADM para administrador, USR para un requisito de usuarios finales y
finalmente SYS si son inherentes al sistema como los requisitos no funcionales.
Finalmente, el número permitirá enumerar todos los requisitos para una fácil
identificación.
7.3.1. Requisitos funcionales
Son los requisitos que hacen referencia a funcionalidades del sistema. Definen un
sistema o algún componente. En definitiva, son el conjunto de entrada, comportamiento
y salida que el sistema tiene que realizar.
38 KPI: del inglés Key Performance Indicator o Indicador Clave de Rendimiento son medidas
cuantificables que se usan para evaluar el nivel de éxito de algo concreto.
56
Tabla 6: Requisitos funcionales
Identificador RF-ADM-001
Usuario Administrador
Descripción Integrar un completo sistema de estadísticas y logs39 para el análisis y
monitorización del sistema.
Identificador RF-USR-002
Usuario Usuario
Descripción Poder seleccionar moneda de origen y destino.
Identificador RF-USR-003
Usuario Usuario
Descripción Automatizar la selección de monedas de origen y destino.
Identificador RF-USR-004
Usuario Usuario
Descripción Utilizar el reconocimiento de texto como alternativa al teclado para la
introducción de la cantidad a convertir.
Identificador RF-USR-005
Usuario Usuario
Descripción Ofrecer una salida por pantalla intuitiva basado, cuando sea posible,
mediante AR.
39 Log: se trata del almacenamiento de eventos que ocurren en un sistema.
57
7.3.2. Requisitos no funcionales
También conocidos como “atributos de calidad” son los requisitos inherentes del
sistema. Definen el comportamiento del producto y permiten imponer restricciones en
el diseño del sistema para asegurar que se cumplen con ciertas características
deseadas.
Tabla 7: Requisitos no funcionales
Identificador RNF-SYS-006
Usuario Sistema
Tipo Disponibilidad
Descripción La aplicación deberá estar publicado en la Google Play Store.
La aplicación deberá estar funcionando las 24h del día por lo que tendrá
que limitar su dependencia a terceros y siempre ofrecer una alternativa,
incluso para funcionar sin conexión, aunque sea de una manera
subóptima.
Identificador RNF-SYS-007
Usuario Sistema
Tipo Usabilidad y Accesibilidad
Descripción Diseño de tamaño adaptable. La aplicación deberá estar adaptado para
una gran cantidad de dispositivos con pantallas de tamaño y relación de
aspecto diferentes.
La aplicación contará con dos temas (claro y oscuro), para facilitar su uso
en diferentes ambientes y siguiendo las preferencias de los usuarios.
Identificador RNF-SYS-008
Usuario Sistema
Tipo Rendimiento / Escalabilidad
Descripción La aplicación deberá funcionar de una forma fluida, a 60FPS el máximo
tiempo posible, y con menos de un 0.5% de ANR y 1% cierres
58
inesperados (FC) siguiendo la recomendación de Google (Android
Developers) (Android Developers).
Minimizar el tamaño máximo de la aplicación para asegurar que se pueda
descargar en un tiempo razonable bajo conexiones lentas y no perder
tasa de conversión (Tolomei, 2017).
Minimizar el uso de internet al mínimo debido a su uso en el extranjero.
Identificador RNF-SYS-009
Usuario Sistema
Tipo Legalidad
Descripción Todo material usado, tanto software como recursos, deberán tener una
licencia válida para poder ser usados en un proyecto de esta índole.
Se deberá asegurar el cumplimiento de la Reglamento General de
Protección de Datos (GDPR) y facilitar a los usuarios sus derechos.
Identificador RNF-SYS-010
Usuario Sistema
Tipo Mantenimiento
Descripción El código tendrá que ser lo más modular posible para facilitar modificar
partes de la misma sin implicar cambios en el resto, así como la
expansión de futuras funcionalidades.
Se deberá usar un sistema de control de versiones en todo momento para
poder iterar y avanzar en el desarrollo del proyecto.
59
60
8. Diseño
En el apartado de Diseño se les dará solución a los requisitos vistos en la sección anterior,
especificando cómo serán resueltos, de manera de que entre los diferentes apartados
formen la “guía” que se seguirá en la siguiente fase del proyecto, la implementación.
Exploratu se tratará de una app que residirá en el dispositivo móvil y no requerirá ningún
servidor propio. Se nutrirá de otros servicios para mantener la información actualizada y
la información necesaria estará siempre guardado en local para que se pueda usar sin
conexión online activa; incluyendo información sobre las diversas divisas, preferencias
del usuario como las últimas ratios de cambio.
8.1. Diseño de la arquitectura conceptual
Al no contar con una API propia, toda la lógica estará centrado en la aplicación en sí e
interactuará con diferentes elementos externos, incluyendo tanto sensores del móvil
como servicios externos como se puede observar en la Figura 6.
Figura 6: Esquema conceptual de Exploratu.
(Fuente propia)
61
De tal manera, los elementos principales serán los siguientes:
- Cámara / Teclado como entrada de información para que pueda ser procesado
mediante la aplicación.
- AR / Texto la salida que se le ofrecerá al usuario después de que la entrada haya sido
procesada.
- Fuente de ratios / GPS serían las entradas adicionales de información que la
aplicación necesita para poder calcular la salida.
- Base de datos / Información base / Preferencias del usuario formarían la parte de la
persistencia de la aplicación, donde se almacenaría la información para su posterior
consulta y uso.
- Back Office servicio externo que se hará cargo de monitorizar el estado de la
aplicación, sus logs, cuadros de mando, para poder optimizar y mejorar la app.
- Lógica de la Aplicación la base de todo el sistema, se encargará de organizar el resto
de los elementos para que funcionen de la forma esperada.
8.2. Diseño de la arquitectura tecnológica
Para llevar a cabo la mencionada arquitectura conceptual se ha decidido a utilizar el
siguiente stack o pila tecnológica.
Empezando por la tecnología base de la aplicación, se va a desarrollar de manera nativa
para poder utilizar APIs propias del sistema y tener un mejor rendimiento. Teniendo en
cuenta que se va a realizar para Android se utilizará principalmente el lenguaje de
programación de Kotlin 40 , desarrollado y mantenido por JetBrains junto con
colaboraciones de Google entre otros, con Java, desarrollado por Oracle, como lenguaje
secundario.
Para la realización del OCR y así poder extraer de las cantidades a convertir, se usará la
API de Google ML Kit Text Recognition41 por su facilidad de uso e implementación además
de su gran exactitud de los resultados y que permite que todo el procesado se haga en
local permitiendo así el uso sin conexión.
40 https://kotlinlang.org/ 41 https://developers.google.com/ml-kit/vision/text-recognition/
62
En cuanto a mostrar los resultados mediante AR, simplemente se usarán las
coordenadas que proporciona el Google ML Kit Text Recognition API para pintar encima
la cantidad convertida.
La persistencia de la información, al tratarse de datos muy simples, se gestionará
mediante el uso del propio sistema de Android de preferencias (SharedPreferences) así
como Room42 como nivel de abstracción sobre el SQLite que usa internamente.
Las ratios de cambio de moneda se obtendrán desde Exchange Rates API 43 por la
adecuación de sus características a nuestro proyecto, como se vió en el estado del arte.
Para facilitar la interacción con el API REST de Exchange Rates API se usarán las librerías
de Retrofit44 de Square para hacer la llamada en cuestión y GSON45 de Google para la
serialización/deserialización de la información que la API proporciona en formato JSON
y así poder usarla en el resto de la aplicación.
Finalmente, para el back office (RF-ADM-001), se hará uso de la suite de Firebase46 de
Google, incluyendo Crashlytics para el seguimiento y análisis de errores, Performance
Monitoring para monitorizar y optimizar el rendimiento de Exploratu, Test Lab para
realizar pruebas en dispositivos reales y comprobar que todo funciona como esperado
en una gran variedad de diferentes dispositivos, así como Google Analytics, para explorar
y analizar la cantidad y el comportamiento de los usuarios en la app.
Se ha decidido hacer uso de esta suite por su gran facilidad de integración y su
funcionamiento semiautomático, el cual permite obtener un montón de información que
será muy útil para seguir mejorando la app y no tener que desarrollar un back office
propio con todo el coste temporal que eso supondría.
Además, clarificar que este back office no va a condicionar el funcionamiento
independiente de la aplicación, en caso de que no hubiera conexión o incluso si se
decidiera prescindir del mismo en un futuro, Exploratu seguiría funcionando. Esta parte
sólo es para la monitorización y mantenimiento del proyecto.
42 https://developer.android.com/training/data-storage/room 43 https://exchangeratesapi.io/ 44 https://square.github.io/retrofit/ 45 https://github.com/google/gson 46 https://firebase.google.com/
63
8.3. Diseño de la persistencia
Aunque la persistencia de datos en Exploratu no sea un aspecto crítico, sigue siendo
importante definir lo que se almacenará y cómo, sobre todo teniendo en cuenta que uno
de los requisitos es que funcione sin conexión.
Para almacenar los ajustes y preferencias del usuario se usarán las APIs nativas de
SharedPreferences de Android. Éstas permiten guardar pares de valores llave-valor (key-
value pairs) de una manera simple, efectiva, y con fácil acceso. Aquí se podrá guardar el
tema que el usuario prefiere usar o su moneda de destino entre otras cosas.
Por otra parte, uno de los requerimientos de la aplicación es que pueda funcionar en
modo offline (RNF-SYS-006), es decir, que pueda ofrecer un resultado de conversión,
aunque en ese momento no se disponga de conexión a la fuente de consulta de divisas
que se esté utilizando. Es por ello por lo que la aplicación va a mantener una copia
temporal de las últimas divisas y cambios entre ellas, de forma que, aunque pueda no
ser exacta se pueda producir una conversión.
Para la información fija sobre las divisas, como su nombre, código (en el formato ISO
421747), símbolo y países donde se usa, se utilizará un archivo de JSON local por su gran
facilidad de integración y fácil acceso.
Aun así, es interesante usar una base de datos más tradicional para poder almacenar y
acceder a los cambios de divisas para no tener que estar haciendo llamadas constantes
a la API externa. Para ello se usará la librería ORM48 de Room de Android.
Mediante la definición de tres componentes: Database (base de datos), Entity (entidad
que se refleja en una tabla) y DAO (operaciones de acceso o consultas a la información)
permite abstraer la base de datos relacional de SQLite que genera y gestiona
internamente, como se muestra en la Figura 7.
47 https://www.iso.org/iso-4217-currency-codes.html 48ORM: del inglés Object-Relational Mapping es una forma de utilizar datos de una base de datos
usando el paradigma de programación orientado a objetos.
64
Figura 7: Diagrama de la arquitectura de Room
(Android Developers)
En nuestro caso necesitaremos una única tabla que contenga los cambios de divisas, la
indicada en la Figura 8. Por lo que los campos de la tabla serán un id que hará de clave
primaria, un timestamp49 para poder saber de cuándo es la conversión, y finalmente una
columna para cada divisa diferente que se quiere usar; en nuestro caso 32, que son el
número de monedas que devuelve el Exchange Rates API. Aquí se guardará el cambio
frente al Euro, que será la divisa que se usará como base para hacer el cálculo del resto
de cambios: moneda origen → Euro → moneda destino.
Figura 8: Tabla de cambio de divisas
(Fuente propia)
A la hora de implementar esto en la app, su funcionamiento será el siguiente. Cuando se
vaya a hacer alguna conversión, al tener el timestamp podremos comprobar de cuándo
son los cambios, y en caso de que sea de un día anterior, la frecuencia de actualización
49Timestamp: secuencia de caracteres que identifican cuándo sucedió un cierto evento.
65
de la fuente que se usará, se intentará llamar a la API si se dispone de conexión a internet
para conseguir los últimos cambios y actualizar la base de datos.
Adicionalmente, la app vendrá directamente con unos valores por defecto de conversión
especificados; para que en caso de que nunca se llegue a abrir la app al descargarse y la
primera vez sea sin conexión pueda seguir convirtiendo, aunque no sean unas
conversiones muy actuales.
8.4. Guía de estilos
Para acelerar el proceso de desarrollo y asegurarse un estilo mucho más coherente se
ha definido una pequeña guía de estilos que se seguirá durante el desarrollo de todo el
proyecto.
8.4.1. Filosofía de diseño
Exploratu se basa en la idea de simpleza máxima e interfaces con interacciones que
ayudan al flujo de navegación del usuario. Para ello se apuesta por interfaces limpias y
simples con animaciones y pequeños toques que hagan la experiencia del usuario más
atractiva y elegante.
Para ello, se ha optado por seguir el sistema Material Design de Google, incluyendo su
última revisión e inclusión de Material Theming50.
Esto significa que se tratará de incorporar todo su sistema de lenguaje visual que
sintetiza los principios clásicos del buen diseño con la innovación de la tecnología y
ciencia. Y para ello nos basaremos en su principio de que Material es la metáfora.
Material Design se inspira en el mundo físico y sus texturas, incluyendo cómo reflejan la
luz y crean sombras. Las superficies de Material reimaginan el medio del papel y tinta.
Para ello se hará uso de un diseño atrevido, gráfico e intencional, usar el movimiento
para dar significado y usar su base flexible para transmitir nuestra marca.
50 https://material.io/design/material-theming/
66
8.4.2. Logo e iconografía
El logo de Exploratu es la representación de dos flechas “><” sobrepuestas formando
una “X” entre ambas. De esta manera se representa tanto el cambio de divisas, las
flechas, como el nombre de Exploratu con la “X”.
Además, las flechas han sido diseñados mediante un degradado entre dos colores,
representando así la fluidez y reforzando la idea del cambio y conversión; idea principal
de la app.
Figura 9: Logo de Exploratu
(Fuente propia)
Por otro lado, para las funciones generales y para destacar o sintetizar algún elemento
se harán uso de los iconos Dual Tone de Google, creados para poder expresar diferentes
identidades de marca sin salir del sistema de Material Design.
Figura 10: Ejemplos de iconos Dual Tone de Google
(Fuente propia)
67
8.4.3. Colores
Siguiendo un poco la guía marcada por Material Design se han establecido los siguientes
dos colores principales. Siendo Almost Black el principal y el Not That Green el color de
acento o accent colour.
Esta combinación de colores es muy contrastada y nos permitirá crear interfaces de alto
contraste que mejorarán la legibilidad y la facilidad de uso por todo tipo de usuarios.
Además, los colores se han elegido de tal manera que queden bien junto a colores claros
y oscuros para poder así tener los dos temas (RNF-SYS-007), con los mismos colores,
manteniendo así la consistencia.
8.4.4. Tipografía
La tipografía que se usará como representante de la marca será la familia de fuentes IBM
Plex™ en sus variantes de Sans, Sans Condensed, Serif y Mono, ya que lo distribuyen con
una licencia libre SIL OFL-1.1.
Estas fuentes fueron creadas por IBM para su cambio de imagen corporativa a finales de
2017. Se crearon para transmitir el puente entre la humanidad y las máquinas que IBM
siempre ha sido.
En nuestro caso también se quiere juntar la realidad con la tecnología, interactuando con
la realidad mediante la cámara, por lo que su estilo grotesco y moderno, pero al mismo
tiempo clásico se adecua a lo que se busca.
# 131313 RGB(019,019,019)
Black 6 C
Almost
Black
#00BFA5 RGB(000,191,165)
3265 C
Not That
Green
68
La jerarquía que se seguirá será el siguiente. Aunque esto se tomará como referencia y
se adecuará dependiendo del contexto en el que nos encontramos, ya que los tamaños,
por ejemplo, no son aplicables a las interfaces de las apps.
Mono@72 Mono @60 Serif @30 Sans Condensed @18
Sans @ 11
Sans @11, Mono @11 y Mono @11
8.5. Diseño Interacción
La idea en torno a todo este proyecto es poder mejorar la experiencia del usuario al usar
estos conversores, por lo tanto, diseñar una buena interacción entre usuario – máquina
va a ser el elemento clave de Exploratu. Al fin y al cabo, es lo que va a percibir el usuario
y es lo que hace que se genere una genial sensación de uso o un rechazo directo de la
app que hará desinstalarla.
Para ello, podemos realizar un User Journey Map de las alternativas vistas en el Estado
del arte y ver cuáles son las experiencias positivas y negativas al usar un conversor de
este tipo.
Título Principal
Título 1
Título 2
Subtítulo
Cuerpo
Énfasis
69
Figura 11: User Journey Map de las apps alternativas
(Fuente propia)
Como se puede ver en la Figura 11, con estos conversores nos encontramos con una
serie de experiencias negativas —con la excepción de abrir la app, que da al usuario una
sensación de que la solución a su problema está cerca— hasta llegar al final de todo y
obtenemos el resultado deseado.
Por lo tanto, lo que más mejorará la sensación del usuario al usar una app de este estilo
es que tenga que realizar el mínimo posible de pasos al principio y así obtener el
resultado más rápido.
Justamente esto es lo que se quiere automatizar al máximo con Exploratu, usando el
GPS para obtener la moneda de destino, teniendo la moneda de origen guardado y
usando OCR y AR para obtener y mostrar el resultado directamente al usuario, sin que
éste tenga que introducir ningún dato; mejorando así la experiencia enormemente.
70
8.6. Diseño Interfaces
A continuación, se muestran los diseños de las interfaces mediante wireframes51, donde
se ha bocetado la solución ideada para materializar los requisitos recogidos en el punto
7.3 de la memoria y se seguirán en la parte de implementación.
La aplicación se abrirá directamente en el modo de realidad aumentada, puesto que es
lo más diferenciador de la app y se utilizará en su contexto de uso principal, ir
convirtiendo varios precios de la manera más rápida posible.
Figura 12: Wireframe del modo AR
(Fuente propia)
Este modo, que se caracteriza por la automatización el proceso de entrada de datos que
permite, contará con una disposición o layout basado en una barra de acción superior y
otra inferior. En ésta última se podrán cambiar las divisas de origen y destino de forma
manual usando el selector con búsqueda de la Figura 13. Además, se podrá invertirlas
pulsando en la flecha.
51Wireframe: guía visual básica que representa el esqueleto de la web/app/programa. Se suelen
usar elementos simples como cajas y líneas para ello.
71
Figura 13: Wireframe de la selección de divisas
(Fuente propia)
En cuanto al FAB52 del interfaz del modo AR, su propósito será pausar el feed de la
cámara para que el usuario tenga más flexibilidad de uso y no tenga que estar
constantemente apuntando al precio. Adicionalmente, cuando se tengan muchos
precios en pantalla simultáneamente podría resultar difícil de seguir las conversiones y
esta función podría paliar con este problema. Esta función no nace de ningún
requerimiento, sino que es una necesidad observada.
Como se puede observar en la imagen, el precio convertido se mostrará al lado del
original, para poder tenerlo de referencia en todo momento y poder compararlos por si
hubiese duda de la conversión y se quiera hacer manualmente usando el interfaz
anterior.
Otra de las características, si se ha permitido en los ajustes, es que se podrá determinar
la moneda destino mediante el GPS, automatizando así el proceso de conversión por
completo. Adicionalmente, para asegurar que el usuario está en control de esto,
adicionalmente, se podrá localizar manualmente pulsando en el icono de ubicación de
la barra superior.
52 FAB: del inglés Floating Action Button se trata de un botón flotante que activa o lanza la acción
principal de la interfaz.
72
Por otra parte, para ayudar el uso de la app en condiciones de poca luminosidad se podrá
activar/desactivar el flash pulsando en su icono en esa misma barra.
Finalmente, se podrá ir al modo de entrada tradicional de cantidades pulsando sobre el
icono de lista.
Figura 14: Wireframe de la pantalla de conversión manual
(Fuente propia)
Como se puede ver en la Figura 14, este modo tendrá un layout tradicional de app de
conversión. Con tres divisas simultaneas que se pueden convertir en la moneda de origen
al pulsar en la cantidad y cambiar de divisa pulsando en el código de éste (Figura 13).
Justo en la parte inferior de éstos, se encontrará la forma de introducción de la cantidad
a convertir, mediante un teclado que además tendrá los botones de borrar el último
dígito introducido, resetear el número completo, así como la posibilidad de añadir cifras
decimales.
Finalmente, en la parte inferior se encuentra la barra de acción. El símbolo central y el
que más atención llama, al ser un FAB, volverá al usuario al modo inmersivo de AR (Figura
12) mientras que el botón derecho, con icono de engranaje, servirá para entrar en los
ajustes.
73
De esta manera, nos quedaríamos con el mapa de interacciones ilustrada en la siguiente
Figura 15.
Figura 15. Mapa de interacciones
(Fuente propia)
8.7. Diseño de pruebas y validación
Para validar el correcto funcionamiento de la app, además de la realización manual de
pruebas y comprobación de que se hayan cumplido todos los requisitos funcionales y
74
no-funcionales, se hará uso de la herramienta Firebase Test Lab 53 ; en concreto su
funcionalidad de Robo.
Esta suite de tests de Google, permite subir nuestra aplicación a su servidor y que ellos
lo prueben directamente, en una gran variedad de dispositivos físicos, para comprobar
el correcto funcionamiento de la app. Se puede elegir qué tipo de dispositivos queremos
probar, así como su versión de Sistema Operativo u orientación. Además, se puede
automatizar su uso mediante la integración con diferentes servicios, como el IDE54 que
vamos a usar en el desarrollo, Android Studio.
Además, gracias a la mencionada función de Robo no tendremos que diseñar las pruebas
individuales. Gracias a su funcionamiento similar a las arañas de los buscadores, Robo
analiza el interfaz y navega automáticamente entre sus diferentes funcionalidades.
De esta manera, al finalizar el test, nos devolverá un reporte que incluye logs, capturas
de pantalla y vídeos que nos permitirán detectar errores y solucionarlos antes de que
usuarios reales se encuentren con dichos problemas.
Similarmente, para cuando se esté en producción, se usarán los servicios de Firebase
Crashlytics55 para el seguimiento y análisis de errores, así como Firebase Performance
Monitoring 56 para comprobar el rendimiento de la aplicación entre los diferentes
usuarios para detectar errores y/o posibles mejoras a tiempo y poder arreglar u
optimizarlos.
53 https://firebase.google.com/products/test-lab 54 IDE: del inglés Integrated Development Environment se trata de un programa que incorpora
facilidades y utilidades para el desarrollo de software. 55 https://firebase.google.com/products/crashlytics 56 https://firebase.google.com/products/performance
75
76
9. Implementación
En este apartado se documenta el proceso de desarrollo, siguiendo la metodología
especificada. Por lo tanto, se detallan los sprints que se han realizado durante el proceso
de implementación y el avance que han supuesto en el proyecto.
Hay que mencionar que se tratan “subsprints” dentro del cuarto sprint general. Se tratan
de srpints muy corta duración, de uno o dos días, donde se marca un objetivo inicial y se
miran los pasos que hay que seguir para conseguirlo.
9.1. Sprint 1: Preproducción
El entorno de desarrollo se ha montado en un ordenador de sobremesa con Windows 10
donde se han instalado y configurado los diferentes programas y utilidades para poder
llevar a cabo la implementación de Exploratu.
Como IDE se ha decantado por Android Studio57, adaptación por parte de Google del
IntelliJ IDEA de JetBrains para el desarrollo de Android. Es la herramienta por excelencia
en el mundo del desarrollo Android y gracias a su gran cantidad de utilidades para el
desarrollo, testeo y debugging58; así como su comunidad nos facilitará enormemente
todo el proceso de desarrollo.
Similarmente, para llevar a cabo el control de versiones, se usará Git junto a GitHub
además de la interfaz gráfica de GitKraken59 para gestionarlo de manera más eficiente e
intuitiva.
Finalmente, se configura Android Studio y el dispositivo que se usará para pruebas
durante el desarrollo, el Xiaomi Mi MIX 2 bajo la versión de Android 9.0, para que se
puedan comunicar mediante el sistema de ADB. Debido a la capa de personalización
sobre Android que lleva el teléfono (MIUI), se han desactivado las “Optimizaciones de
57 https://developer.android.com/studio 58 Debugging: proceso de búsqueda y solución de fallos o bugs. 59 https://www.gitkraken.com/
77
MIUI” para que esta comunicación con Android Studio se pueda realizar de manera
efectiva.
Se ha marcado como nivel mínimo de Android necesario para usar la app Android 5.0
(API level 21), teniendo en cuenta que el 89.3% (Android Developers, 2019) de
dispositivos activos están en esa o una versión superior, y que se introdujeron un montón
de nuevas funciones con esa API que se usarán durante el desarrollo; por lo que elegir
una versión mínima anterior nos limitaría a la hora de la implementación.
9.2. Sprint 2: Creación de la estructura base de la app
Lo primero que se ha realizado una vez tenido el entorno de trabajo configurado ha sido
crear la estructura base de la app. Esto se ha hecho mediante dos Activities, clases
especiales que usa Android para referirse a las “pantallas” de las apps.
De esta manera, contamos con el Activity principal que será el modo inmersivo donde se
realizará el OCR y se mostrará mediante AR las conversiones; y un segundo Activity
donde se encuentra el teclado para la entrada de datos y conversión manual.
Figura 16: Activities base de Exploratu
(Fuente propia)
78
Como se puede apreciar en la Figura 16 en la pantalla de OCR ya se ha incorporado el
procesado mediante el Google ML Kit Text Recognition y ya nos detecta el texto de la
cámara.
Esto se ha conseguido siguiendo el siguiente esquema de la Figura 17 y siguiendo como
base el guía60 ofrecido por Google. De tal manera que el fotograma del feed de la cámara
pasa por la clase de procesado donde se analiza y se extraen los bloques de texto
detectados.
Luego se usa la información que estos bloques tienen, como su ubicación dentro de la
preview, para poder pintarlos encima de la CameraSourcePreview que es lo que el
usuario ve de vuelta.
Figura 17: Esquema del funcionamiento del OCR
(Fuente propia)
Como se puede ver, ahora mismo el detector detecta todo el texto que ve y no hace nada
más que mostrarlo de vuelta en la preview. Por ello, en los siguientes sprints se
clasificarán lo bloques de texto detectados para ver cuales contienen cifras numéricas
que podrían ser los precios que buscamos.
60 https://codelabs.developers.google.com/codelabs/mobile-vision-ocr/
79
Una vez se localicen los precios, se tendrá que calcular el cambio y mostrar eso en la
preview de alguna forma clara y entendible.
Finalmente, también se ha implementado la pequeña función de pausar el feed de la
cámara. Como se adelantaba en la fase de diseño, esto resulta útil al tener muchas
cantidades en pantalla, ya que la aplicación tiende a “parpadear” ya que no siempre
detecta todas las cifras. Por tanto, poder pausarlo elimina el efecto, pudiendo ver las
conversiones claramente, sin distracciones.
9.3. Sprint 3: Conversión manual en local
Una vez con la estructura base de la app, y antes de seguir con la detección de elementos
adecuados, se define como el objetivo de este sprint la implementación de la conversión
manual en local.
Para ello se debe, por una parte, conseguir que el usuario pueda introducir la cantidad
que quiera convertir, y por otra, diseñar y cargar el fichero JSON que contará con la
información sobre las divisas (incluyendo el valor por defecto de conversión), para así
poder realizar el cambio entre ellas.
Dicho JSON se ha generado manualmente teniendo en cuenta la información que es
necesario para el funcionamiento de la app, siguiendo lo mencionado en el apartado de
diseño, así como las divisas con los que cuenta la API que se utilizará posteriormente.
En caso de que hubiera que cambiar de API o se ampliase las divisas que soporta éste,
simplemente se tendría que ampliar / reducir este fichero a las divisas con los que
trabajase.
Adicionalmente, para seguir con el diseño de interfaces marcado, se han adaptado las
banderas del país/región principal donde se usa cada divisa para que tengan una forma
cuadrada; almacenándose bajo la carpeta de assets o recursos de la app, junto al anterior
JSON. Se ha aprovechado el código único de cada divisa para no tener que almacenar la
ruta de cada imagen.
80
Figura 18: Diseño de las banderas de las divisas
(Fuente propia)
Para la introducción de las cantidades, se ha incluido un teclado propio con botones para
cada dígito y acción como borrar el último dígito o resetear. Internamente los
escuchamos para poder añadir dicho dígito al número actual y poder mostrarlo después
de un reformateo.
En el reformateo se controlan cosas como que no supere el número de caracteres
máximo establecido (15 en este caso), que sólo pueda haber un decimal, que no haya
más de 4 números decimales, que no haya ceros iniciales, se añaden comas para dividir
los números grandes para que se puedan leer fácilmente entre otras cosas.
Para probar el funcionamiento de lo realizado hasta ahora, el listado, búsqueda y
selección de país se ha dejado para el siguiente sprint, por lo que para las pruebas se
eligen y definen las divisas de USD, CNY y JPY.
De esta manera, al iniciar la aplicación, se cargan las divisas desde el fichero JSON
usando la librería de ORM de GSON en un objeto de Currencies. De ésta se extraen los
datos de las divisas seleccionadas y se muestran en la interfaz; incluyendo su código,
nombre y signo. A continuación, se buscan y cargan las fotos de los países mediante la
librería de Picasso61.
Por ahora, al sólo tener la información por defecto de las conversiones del JSON se extrae
dicha información a un objeto de Rates que además de contener los cambios, dentro de
un objeto Exchanges, cuenta con una función de convertir que nos permitirá a
continuación realizar las conversiones iniciales.
61 https://square.github.io/picasso/
81
Con todo esto, ya se pueden realizar las conversiones mientras el usuario va
introduciendo los datos y mostrarlos en pantalla. El resultado de esto se puede ver en la
siguiente Figura 19.
Figura 19: Interfaz implementado del modo manual
(Fuente propia)
Como se puede ver en la figura anterior para cambiar la divisa base (activa) sólo hay que
tocar en la cantidad de dicha divisa y este número se cambiará de color para indicar que
está seleccionado. A continuación, simplemente hay que ir introduciendo las cantidades
deseadas y la app irá convirtiendo simultáneamente a las otras dos divisas.
Finalmente, hay que mencionar que todo esto se ha hecho siguiendo las
recomendaciones de programación de Android para asegurar un alto nivel de
modularidad y limitar el código duplicado, facilitando así la mantenibilidad y expansión
de Exploratu. Por ejemplo, para la estructura de las interfaces se ha hecho uso de
diferentes archivos de “configuración” o parametrización que ofrece Android, como
styles.xml, color.xml, strings.xml entre otros.
El beneficio de esto ha sido inmediato, ya que sin esto no habría sido tan sencillo crear
el tema oscuro. Para ello sólo se ha tenido que crear los archivos de configuración que
sobrescriban los valores guardados en los archivos por defecto, destinados para el tema
claro. De esta manera, por ejemplo, si en el tema claro el color del fondo es blanco,
82
podemos sobrescribir el código hexadecimal del color para el fondo, haciendo que en el
tema oscuro sea negro.
9.4. Sprint 4: Selector de divisas
El objetivo de este sprint ha sido terminar la parte de conversión manual en local, para
así tener todo listo para crear la estructura necesaria para las llamadas a la API externa
que se harán en el próximo sprint; siendo así la parte más importante la realización del
selector de divisas.
Para ello se ha usado el BottomSheetDialogFragment que nos ofrece la API de Android.
Los fragment o fragmentos en Android se tratan de pequeñas Activities que se pueden
lanzar sobre o junto a un Activity principal. De esta manera, este tipo de fragment nos
permite tener un elemento similar a un cuadro de diálogo tradicional, pero que es
emergente desde la parte inferior de la pantalla y es visualmente más agradable y
moderno gracias a su animación y deslizamiento fluido. Además, resulta más versátil ya
que se puede expandir para cubrir toda la pantalla y así facilitar la selección de la divisa
que se quiere.
El listado de las divisas se ha implementado usando el componente RecyclerView de
Android. El RecyclerView es una versión optimizada de la ListView para la representación
de largas listas de elementos en Android. Mediante un LayoutManager y un Adapter al
que se le pasa la información necesaria para la representación de los ítems de la lista,
permite reducir el número de elementos cargados en la vista en todo momento,
pudiendo reusar elementos que no están a la vista del usuario para cargar los siguientes
ítems; mejorando así enormemente el rendimiento y reduciendo los recursos
necesarios.
83
Figura 20: Diagrama comparativo entre el ListView y RecyclerView
(Fuente propia)
Adicionalmente, se ha añadido el componente SearchView para la realización de
búsquedas entre las diferentes divisas y así facilitar y agilizar el proceso de elegir las
divisas deseadas. Con todo esto el interfaz quedaría como muestra la siguiente Figura
21.
Figura 21: Sistema de selección y búsqueda de divisas
(Fuente propia)
Como se puede observar en las capturas, al hacer clic en algún nombre o bandera de una
divisa se abre el selector de las mismas. Además de poder seleccionar manualmente
desplazándose verticalmente, se puede realizar una búsqueda para filtrar las divisas por
su nombre, país/es donde se use, su código o incluso símbolo.
84
Para cada cambio de carácter en la consulta del SearchView se realiza un filtrado de los
elementos cargados en el RecyclerView siguiendo los mencionados campos. A
continuación, se vuelven a cargar las divisas al Adapter, pero sólo las que incluyan
campos con dicha consulta.
Algunas de las optimizaciones que se han hecho para mejorar la experiencia del usuario
incluyen: el expandir el cuadro de diálogo a pantalla completa al realizar la búsqueda y
ocultar el teclado al empezar el desplazamiento vertical; para poder ver mejor los
resultados en ambos casos.
Una vez encontrado y seleccionado la moneda que se quiera usar para las conversiones,
el cuadro de diálogo se cierra, la información de la divisa se carga en la interfaz, las
conversiones se recalculan para reflejar el cambio de moneda y finalmente, se guarda la
nueva selección en las preferencias del usuario, mediante la API de SharedPreferences
de Android. De esta manera, al cerrar y volver a lanzar la aplicación se pueden restaurar
las divisas que se usaron la última vez para que el usuario no tenga que volver a
seleccionarlas.
9.5. Sprint 5: Obteniendo las ratios desde internet
Para este sprint se ha propuesto terminar ya con la conversión manual y añadir la última
funcionalidad que le faltaba: conectarse a la fuente de información externa para obtener
los últimos cambios.
Para ello lo primero que se ha realizado es construir la base de datos usando la librería
de Room. Por lo tanto, se han definido los objetos @Entity para la definición de las tablas,
en nuestro caso una única como se definió en la Figura 8 llamado Rates.
Al contar con un campo de fecha y querer guardarlo en la base de datos como timestamp,
pero, sin embargo, en el resto del programa querer usarlo como un objeto de tipo Date,
se ha creado lo que se denomina como @TypeConverter. Esto no son más que dos
métodos que le permiten a Room pasar un objeto de un tipo a otro.
A continuación, se han definido los métodos que se usarán para acceder a los datos
mediante un @Dao, especificando qué llamadas se harán a la base de datos para
insertar, actualizar, borrar y obtener la información.
85
Finalmente, con los @Entity, @Dao y @TypeConverter-s definidos se ha creado la base
de datos (@Database). De esta manera, la clase de RatesDatabase nos devolverá la
referencia a una instancia de la base de datos en caso de que exista y de otra forma lo
instanciará.
Con la base de datos definida y lista para usar, sólo queda realizar las llamadas a la
Exchange Rates API para obtener y guardar las últimas ratios de conversión. Esto se ha
realizado con la librería de Retrofit, que nos facilita dicha tarea. Además, permite
mantener el código muy modularizado para que en caso de que la API cambie poder
adaptarse fácilmente.
Retrofit necesita dos componentes para su uso. Por una parte, la factoría que se usa para
configurar e instanciar la librería. Por otra, un interfaz especificando las rutas a las que
atacará para obtener la información y el tipo de llamadas que hará.
En nuestro caso tenemos una única ruta62 a la que realizaremos peticiones GET. También
configuramos para que Retrofit use la librería de GSON para la deserialización del JSON
obtenido y cree los objetos de Rates que usaremos.
Finalmente, teniendo en cuenta que GSON necesita que los nombres de los campos
concuerden con lo que devuelva la API, se han renombrado los campos de timestamp a
date y exchanges a rates en el objeto Rates.
Con todo esto preparado, ya podemos realizar las llamadas y obtener los últimos
cambios. Al iniciar la app se realizan las siguientes comprobaciones para ver qué ratios
usar:
1. Obtener la entrada más reciente de la base de datos. Si es de hoy usar ese.
2. En caso contrario, ver si tenemos conexión a internet, en caso de que así sea se
obtienen los cambios. Estos se guardan en la base de datos y se empieza a
usarlos.
3. Si hay algún error durante la petición o no hay conexión a internet, se usa la última
entrada disponible de la base de datos.
4. En caso de que la base de datos estuviera vacía se obtienen las ratios “por
defecto” del JSON que tiene información sobre las divisas. A continuación, se
guardan en la base de datos como la entrada más antigua.
62 https://api.exchangeratesapi.io/latest/
86
De esta manera siempre tendremos las ratios más actualizados que podemos obtener
en dicho momento. Para aumentar la transparencia, se informa al usuario de cuándo son
los cambios que se están usando mediante un pequeño texto en la parte superior del
teclado numérico.
Adicionalmente, se ha añadido un monitor del estado de la red, así, cuando el usuario
pase a tener conexión a internet se comprobará que no haya actualizaciones además de
hacerlo al iniciar la app.
9.6. Sprint 6: Funcionalidad base del modo AR
Con la parte de conversión manual realizado, podemos seguir con el aspecto principal
de la app, la conversión en AR. El objetivo original de este sprint era seguir con lo ya
conseguido en el segundo sprint, detectar todo tipo de textos mediante la cámara, pero
con la diferencia de ahora sólo detectar los números. Pero como esto se ha realizado
antes de lo esperado, y la metodología elegida permite añadir nuevas tareas a un sprint
en curso, se ha terminado también haciendo toda la parte de conversión y mostrar los
resultados, además de añadir los selectores de divisas de origen y destino.
Para sólo obtener los números de lo que percibe la cámara, siguiendo el diagrama de la
figura Figura 17, se han filtrado los ítems o palabras que la librería de OCR detecta. Esto
se ha realizado usando diferentes expresiones regulares, regex, de la siguiente manera:
1. Se eliminan todos los caracteres no numéricos y separadores, punto y coma, de
la palabra detectada. Regex: ([^0-9.,]+[.,]).
2. Se busca si existe algún número con decimal o mayor de 1.000 separado
mediante coma o punto. Regex: (\d+([.,])\d{1,4}).
3. Si existe, se comprueba cuántos números están después del separador. Si son
menos que tres se califican como decimal y no se cambian. Por el contrario, si
son más que tres se estima que son separadores visuales por ser dígitos mayores
que 1.000 y por tanto se extrae dicho separador para que, al convertir la cadena
de texto en número, no se piense que son tres o más números decimales.
4. En todo caso la cadena de texto final se intenta convertir en un número. Si esto
se pueda realizar correctamente nos encontraríamos con un número y en caso
contrario se estima que dicha cadena no es un número.
Una vez extraído el número sólo queda convertirlo y mostrárselo al usuario.
87
Para conseguir lo primero, el usuario cuenta con dos selectores de divisas, los vistos en
el Sprint 4, que podrá usar para elegir las monedas que le interesan. A continuación, se
obtiene la ratio de conversión de la unidad entre dichas divisas, una unidad de la moneda
de origen a cuántas unidades de la moneda destino equivalen, siguiendo lo visto en el
anterior Sprint 5. Posteriormente, se guarda dicha ratio en los SharedPreferences para
que a la hora de pintar la conversión se pueda acceder a la cantidad y hacer la
multiplicación.
Para lo segundo, el detector le pasa a la clase OrcGraphic —el encargado de dibujar el
overlay63 en la vista previa de la cámara— la palabra detectada, su valor numérico, la
imagen que se quiere pintar como base y una referencia a las SharedPreferences para
poder acceder a la ratio de conversión.
De esta manera, finalmente, usando las coordenadas que la palabra tiene al ser tipo Text
del detector, podemos dibujar la imagen que actuará como contenedor de la conversión
para facilitar su lectura, así como la conversión en sí después de acceder a las
preferencias, obtener la ratio y realizar la multiplicación.
Figura 22: Ejemplo de uso del modo AR
(Fuente propia)
63 Overlay: del inglés “capa” o “cubierta” son los elementos que se sitúan encima de otros.
88
9.7. Sprint 7: Automatización de la selección de divisas y detalles
Para facilitar el uso de la app se ha marcado como objetivo de este sprint automatizar en
la medida de lo posible la selección de divisas.
Para ello se han seguido dos estrategias dependiendo de si se quería obtener la moneda
de origen o desino. Para conseguir la moneda de destino, se ha asumido que el usuario
usa el dispositivo en la región que corresponde con su región habitual. De esta manera,
se puede acceder a dicha región y de ahí extraer la divisa usando el objeto Currency de
Android.
Para la moneda de origen, la idea original era usar el GPS para conseguir la ubicación del
usuario, de ahí obtener el país y finalmente la moneda que se usa en dicho territorio. Sin
embargo, esta idea ha sido descartada teniendo en cuenta que no necesitamos la
ubicación precisa del usuario, el tiempo que tarda el GPS en localizar y el permiso extra
de localización que se tendría que pedir.
En su lugar, se ha optado por usar la información de la red en la que el usuario se
encuentra conectado para obtener el país. Primero de la red móvil y en caso de que no
estuviera disponible, de la red de internet. Una vez teniendo el país se obtiene la divisa
como en la estrategia anterior. Este método resulta muy rápido y funcionará
correctamente a no ser que el usuario se encuentre sin tarjeta SIM64, sin cobertura o
usando un VPN65 de otro país.
Al iniciar la aplicación por primera vez, se obtiene la información mediante estos dos
métodos para las divisas de origen y destino. Al ir guardando las divisas que usan los
usuarios en las preferencias, no se calcularán cada vez que se inicie la app, evitando así
que los usuarios tengan sensación de que la app se reestablece cada vez. En su lugar, se
ha añadido una opción en la barra superior para la localización de la divisa de origen
cuando el usuario determine oportuno.
64 Tarjeta SIM: del inglés Subscriber Identity Module se tratan de las tarjetas que las operadoras
usan para identificar a sus usuarios y poder ofrecerles conectividad. 65 VPN: del inglés Virtual Private Network dícese de las redes que emulan estar conectados a otra
red diferente.
89
Similar al sprint anterior, al cumplir los objetivos marcados todavía había tiempo
restante. Por ello, se ha decidido continuar añadiendo algunos detalles más para mejorar
la experiencia de usuario.
Uno de esos detalles ha sido una opción superior para encender y apagar el flash. De
esta manera, aunque no haya apenas iluminación el usuario podrá activar el flash y seguir
realizando conversiones.
Otra de las cosas que se han realizado es la inclusión de tooltips, mensajes de ayuda, al
hacer una pulsación larga en los elementos más importantes de la interfaz, como los
botones y opciones; mejorando así la accesibilidad de la herramienta. Un ejemplo de ello
se puede encontrar en la siguiente Figura 23.
Figura 23: Ejemplo de Tooltip
(Fuente propia)
Para seguir con los interfaces definidos en el apartado 8.6 de la memoria, y
especialmente el mapa de interacciones, se ha cambiado la ejecución de la app para que
el modo AR sea el principal; el modo que se abre al ejecutar la app desde cero. Para
acceder al modo manual se ha añadido una opción en la parte izquierda de la barra
superior de opciones de este modo de AR.
90
Figura 24: Interfaz final del modo AR
(Fuente propia)
Adicionalmente, también se ha implementado una pequeña función de invertir las
divisas activas pulsando en la flecha entre las mismas. Esto podría resultar útil en
ocasiones donde se estuviera cambiando de uno a otro y viceversa continuamente.
Por otra parte, se ha aprovechado el tiempo para incluir las librerías de Firebase
Crashlytics y Performance Monitoring para poder analizar posteriormente los problemas
que los usuarios se encuentran con Exploratu, además de poder monitorizar el
rendimiento.
Finalmente, mencionar que se ha intentado, sin éxito, implementar la fuente definida en
la guía de estilos, IBM Plex, usando la función de fuentes descargables66 de Android. Esto
permite que la fuente se descargue fuera de la descarga inicial de la app, y en caso de
que ya se esté usando por otra app instalada, la reutilizaría y no haría falta volver a
descargarla; ahorrando espacio y la misma descarga en cuestión. Desafortunadamente,
por razones desconocidas, la fuente elegida, a pesar de formar parte de la colección de
fuentes abiertas de Google Fonts67, no está disponible bajo este servicio de fuentes
descargables.
66 https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts 67 https://fonts.google.com/?query=ibm+plex
91
Por esta razón y para no incrementar el tamaño de la aplicación innecesariamente,
perjudicando así a los usuarios que podrían estar descargándoselo bajo condiciones
poco optimas al estar de viaje, se ha decidido prescindir de esta familia de fuentes y
apostar por la similar Roboto, incluida en todo dispositivo Android.
92
10. Pruebas y validación
Durante el periodo del desarrollo se ha ido probando su funcionamiento en el dispositivo
de desarrollo, Xiaomi Mi MIX 2 sobre Android 9 (API level 28), viendo que los nuevos
cambios funcionasen correctamente y no interferían con funcionalidades anteriormente
implementadas.
Al finalizar la implementación, las pruebas se han expandido a otros dispositivos que se
encontraban al alcance, como el Xiaomi Mi Note 2 / Mi 8, incluyendo dispositivo de gama
baja como el Redmi 3. En ninguno de los dispositivos se ha notado apenas ralentización,
asegurando un correcto y fluido funcionamiento.
Figura 25: Realización de pruebas en dispositivos físicos
(Fuente propia)
De esta manera se ha testeado Exploratu en varios dispositivos que reflejarían los
diversos usuarios de la misma; tanto usuarios con dispositivos de gama alta como baja,
nuevos y antiguos.
A continuación, antes de dejar en manos de usuarios externos, se han realizado pruebas
automáticas en el mencionado Firebase Test Lab; usando el test automático mediante la
herramienta Robo, probando diferentes configuraciones a los que no teníamos acceso
directo.
93
Figura 26: Tests Robo en Firebase Test Lab
(Fuente propia)
Todos los tests se han pasado con éxito y sin ningún fallo de funcionamiento. En cuanto
al rendimiento, se han podido ver los beneficios de programar nativamente. Aun
teniendo varios elementos de alto coste como la cámara, procesado de la imagen o
acceso al disco entre otros; el procesador, la memoria o los gráficos se han mantenido
en niveles razonables, como indica la próxima Figura 27.
Figura 27: Resultados de rendimiento en el Google Pixel (API level 26)
(Fuente propia)
94
Una vez con una mínima certeza de la estabilidad de la app y de que los usuarios no se
encontarán con constantes cierres inesperados, se ha decidido probarla con los primeros
usuarios externos. El objetivo principal: evaluar la precisión de las detecciones de texto
y ver si se encuentran con algún problema durante su uso. Además de su feedback
directo, también se han recogido reportes mediante la herramienta de Firebase
Crashlytics y Performance Monitoring.
Como ejemplo de la efectividad de Firebase Crashlytics se encuentra el siguiente caso.
A uno de los usuarios de los que se animaron a probar la aplicación no se le llegaba a
iniciar, su ejecución se terminaba inesperadamente antes. De otra manera, teniendo en
cuenta la distancia al usuario y su disponibilidad, hubiera sido difícil encontrar el
problema y solucionarlo. Pero, gracias a la integración de Crashlytics se pudo saber
inmediatamente qué era lo que fallaba, incluyendo la línea que había causado el
problema, y solucionarlo rápidamente.
Figura 28: Captura de los cuadros de mando de Firebase Crashlytics
(Fuente propia)
Similarmente, los cuadros de mandos de Performance Monitoring nos permiten observar
si hay algún problema de rendimiento, ya sea de la aplicación/dispositivo en sí, la
conexión a la API o de red. De esta manera podremos saber cuándo se encuentra la API
caída o si hay alguna parte de la aplicación que genere demasiada lentitud.
95
Figura 29: Captura de los cuadros de mando de Firebase Performance Monitoring
(Fuente propia)
Como se puede observar en la siguiente Figura 29, todo parece que está dentro de los
valores adecuados.
Finalmente, pasando a validar la capacidad de detección de precios de Exploratu, gracias
al feedback directo de los primeros usuarios se ha podido saber dicha efectividad. De los
20 diferentes tests que se han realizado, se han podido obtener resultados positivos,
mediante la cámara, en un 80% de las ocasiones (16 veces). Las otras veces se ha tenido
que recurrir a la introducción manual de cifras.
Figura 30: Ejemplo de casos en los que no se ha conseguido un resultado óptimo
(Fuente propia)
96
Analizando las situaciones donde no se ha podido obtener un resultado favorable del
reconocimiento de texto nos encontramos más problemas cuando:
- Hay poco contraste entre cifras/fondo.
- Se usan fuentes de texto fuera de los habituales y más simples.
- Se utiliza una coma para separar cifras decimales. Se observa una peor tasa de
detección frente al punto.
Adicionalmente, el feedback ha incluido otras frentes que pulir para futuras iteraciones:
- Solapamiento entre las cantidades convertidas.
- Gran parpadeo de cifras al estar en constante detección.
- Conversión de cifras que no son precios.
Muchas de estas cosas se podrían ir solucionando con mayor o menor facilidad en
próximas versiones. La mayoría de éstos surgen por la inexactitud del sistema de
detección y OCR empleado, la API de Google ML Kit Vision. Por lo tanto, como se detalla
en el apartado de trabajo futuro, se tendría que centrar la mayor parte del esfuerzo en
mejorar esto.
La creación de un modelo propio de detección de precios usando Machine Learning que
mejore la detección obtenida por el sistema genérico de OCR de Google podría ser una
opción.
Con la validación, además de las pruebas, realizada y habiendo podido detectar y
solucionar los errores más graves a tiempo, se ha pasado a la publicación de Exploratu
en la Google Play Store, siguiendo el plan de publicación del Apéndice I.
97
98
11. Resultados
En esta sección pasamos a analizar el producto final y mostrar los resultados del
proyecto de Exploratu.
11.1. Producto Final
Para ello, primero se hará un recorrido de sus interfaces, mostrando en la mayoría de las
capturas la versión del tema oscuro junto al claro.
Figura 31: Aviso pidiendo permiso para usar la cámara
(Fuente propia)
Lo primero que los usuarios ven al abrir la aplicación es este aviso pidiendo el acceso a
la cámara. Si se acepta, se pasaría a la Figura 33; en caso de rechazarlo no dejaría usar
el modo AR, aunque sí las funciones manuales de la Figura 19.
99
Figura 32: Posibilidad de darle permiso a la cámara a posteriori
(Fuente propia)
De todas formas, en caso de que se rechazase, Exploratu muestra un aviso permanente
para que el usuario pueda darle permisos a la cámara a posteriori, como se muestra en
la Figura 32.
Figura 33: Exploratu avisando de tener cuidado al usar AR
(Fuente propia)
100
A continuación, aparece un segundo aviso, requerido por las políticas del Google Play
Store como visto en el Apéndice I. En éste se alerta al usuario de que extreme la atención
al usar el modo de realidad aumentada, así como que esté supervisado si así se requiere,
por ejemplo, si se trata de un niño.
Si se presiona “I understand” no nos volverá a salir el aviso, pero si se presiona “Remind
me next time” o fuera del aviso, se volverá a advertir de tomar las precauciones
adecuadas la próxima vez que se lance la aplicación.
Figura 34: Modo AR de Exploratu
(Fuente propia)
Ahora sí entramos en la interfaz principal del modo de AR de Exploratu. Al iniciar por
primera vez, la aplicación intentará detectar automáticamente las divisas de origen y
destino.
Para determinar la moneda de destino usará la configuración del dispositivo, mientras
que para la moneda de origen la ubicación de la red en la que se encuentra el dispositivo.
De esta manera, en el ejemplo de la Figura 34, al estar conectado en una red española,
ha detectado el Euro como la divisa de origen, y al tener configurado el móvil en inglés
de Estados Unidos, el Dólar Estadounidense como divisa destino.
101
Simultáneamente, al estar conectado a internet, se obtienen las últimas ratios de
conversión desde el Banco Central Europeo; ya que al ser la primera vez que abrimos la
app, las incluidas están desactualizadas.
Con esta información Exploratu comienza a detectar el texto que ve la cámara y extraer
los posibles precios que se ven para convertirlos, como se muestra en la Figura 34.
Adicionalmente, desde esta pantalla podemos acceder al modo manual, Figura 19, con
el botón izquierdo de la barra superior. También podremos activar/desactivar el flash con
el botón que se encuentra a su derecha, en el otro extremo de la barra, así como volver
a auto detectar la moneda de origen, en caso de que nos hubiéramos cambiado de país
o hubiésemos cambiado la divisa para probar otra.
Similarmente, en la parte inferior, podremos cambiar las monedas de origen y destino
usando el selector de la Figura 21, pulsando en la divisa que se quiere reemplazar.
También se pueden invertir dichas divisas haciendo clic en la fecha que los separa, y
pausar/restaurar el feed de la cámara pulsando en el botón de pausa/play.
En el modo manual, Figura 19, se puede convertir entre tres divisas en tiempo real, se
marca uno, pulsándolo, y simplemente usando el teclado propio se puede ir convirtiendo
las cantidades deseadas. También se muestra de cuándo es el cambio que se está
usando en la app, permite cambiar las divisas usando el mismo selector que en el modo
AR, el de la Figura 21. Finalmente, permite volver al modo de AR pulsando el fab central.
11.2. Recepción
Todavía es pronto para saber cómo será recibido, pero en los primeros tres días de
publicación ha tenido más de 50 descargas en la Google Play Store y las opiniones han
sido muy positivas: las 21 valoraciones recibidas han sido de cinco estrellas, puntuación
máxima.
102
Figura 35: Algunas opiniones en el Google Play Store
(Fuente propia)
Los resultados en Product Hunt, web que muestra nuevas aplicaciones que van saliendo
cada día y donde también se ha publicado Exploratu, han sido similarmente positivas.
Figura 36: Resultados del lanzamiento de Exploratu en Product Hunt
(Fuente propia)
103
Como muestra la Figura 36, Exploratu logró estar destacado en la página principal, el día
30 de Julio de 2019, y terminó en el puesto veintidós de ese día, con cuarenta y tres
votos y seis comentarios.
Figura 37: Comentarios del lanzamiento de Exploratu en Product Hunt
(Fuente propia)
Además, cabe destacar que la gente pareció interesada en la idea y propuso mejoras
que podrían implementarse en un futuro para seguir mejorando el producto.
11.3. Coste temporal
Gracias a la detallada fase de análisis y especificación además del diseño, el tiempo de
implementación ha sido algo menos a la estimada, 65h frente a las 84h que se
esperaban. Además, por cuestiones personales, no se han podido disponer de los 14
días estimadas, y se ha realizado jornadas más intensas durante 8 días.
En cuanto al TFG en general, el retraso se tratará de algo más de dos semanas de lo
originalmente planificado, principalmente debido a cuestiones personales que han
impedido dedicarle el tiempo originalmente previsto.
104
Adicionalmente, no se había planificado tiempo para el despliegue o publicación de la
app, el cual ha llevado casi 10h en total. Gracias a haber podido terminar la
implementación antes de lo previsto, el proyecto no se ha retrasado más.
105
106
12. Conclusiones y trabajo futuro
En este apartado se recogen las conclusiones extraídas a lo largo de todo el desarrollo
del trabajo y proyecto.
12.1. Estado actual
Actualmente Exploratu se puede considerar como MPV o mínimo producto viable
completado. Se han cumplido al completo los objetivos y funcionalidades requeridas,
aunque algunos requisitos no funcionales, como el de estabilidad (RNF-SYS-008),
requerirán más tiempo para poder observar y asegurar que se cumplen.
La aplicación es capaz de realizar con éxito su función principal, ofrecer la conversión de
divisas directamente en AR automatizando todo el proceso de introducción de datos.
Figura 38: Capturas del correcto funcionamiento de Exploratu
(Fuente propia)
Además, el diseño de la aplicación se ha hecho de forma modular, tanto la base de datos
como la aplicación en sí. De esta manera, en un futuro se podrá ampliar de la forma más
fácil y sencilla posible; ya sean diferentes funcionalidades, localización a distintos
idiomas o lo que se estipule oportuno.
107
Por otra parte, mencionar que la aplicación se encuentra disponible en la tienda de
Google Play Store para que todo el mundo lo pueda probar, además de poder distribuir
actualizaciones para añadiendo correcciones y funcionalidades de una manera sencilla
y controlada.
Finalmente, gracias a la parte de back-office implementado usando la suite de Firebase
se puede monitorizar el comportamiento de los usuarios, así como los problemas de
rendimiento y errores que vayan teniendo para solucionar las cosas a tiempo y ofrecer la
mejor experiencia de usuario posible.
12.2. Mejoras y ampliaciones
En cuanto a las posibles mejoras y ampliaciones de cara a trabajo futuro, durante el
desarrollo del proyecto se han encontrado con varias características que podrían ser
mejorados:
- La detección: aunque funcione mejor de lo que originalmente se esperaba, todavía
tiene margen de mejora. Además de ajustar la extracción de precios de todo el texto
detectado, habría que probar con modelos propios de detección de precios, para así
mejorar la detección en general, detectar únicamente precios y despreciar el resto
de los números.
- Solapamiento: al tener dos cifras muy cercanas la conversión de una tapa la otra.
Habría que controlar dónde se está mostrando cada conversión y mostrar los otros
resultados de forma que no solapen entre ellos.
Otra solución podría ser ofrecer la posibilidad de mostrar los resultados encima de la
cifra original en vez de a su lado, de esta manera dos cifras no se solaparían, aunque
se podrían encontrar situaciones donde la conversión tuviese problemas para
mostrarse, por ejemplo, al no tener suficiente espacio y por tanto no entrar.
- Mostrar las conversiones: la forma en la que Exploratu muestra actualmente las
conversiones no es la más atractiva. Queda un poco tosca y podría ser mejorada en
futuras versiones para llamar más la atención. Además, se podría mostrar el símbolo
de la moneda de destino para que quedase más claro lo que se está haciendo, así
como ajustar el tamaño del recuadro que muestra la conversión teniendo en cuenta
la longitud del número resultante de la conversión.
108
- Fuentes de datos para las conversiones: si bien es cierto que la API empleada incluye
las divisas más habituales, es verdad que todavía hay divisas bastante comunes
como la libra egipcia o el dólar taiwanés que no están en Exploratu. Por lo tanto,
incluir otras fuentes, así como dejar al usuario que elija su preferida, podría resultar
útil. De esta manera incluso se podría usar el cambio que usa la tarjeta de crédito de
cada uno, como VISA o MasterCard, en vez del cambio del mercado real que luego
no se aplica en los pagos.
- Acabado: por cuestiones de tiempo no se han podido incluir apenas animaciones ni
otros aspectos que redondean este tipo de aplicaciones. Ayudan a transmitir lo que
se está haciendo en cada momento y en general mejoran la experiencia de usuario.
Se podrían añadir animaciones, por ejemplo, al encender/apagar el flash, localizar
la divisa origen automáticamente, invertir las divisas seleccionadas, pasar del modo
AR al manual y viceversa…
Similarmente, hay otras funciones que han surgido durante la ideación, desarrollo o la
publicación del proyecto y que podrían resultar interesantes incorporarlas en futuras
versiones de Exploratu:
- Poder importar una imagen de la galería y que la app realice las conversiones de los
precios detectados.
- Detectar la divisa de origen basándose en el símbolo de la moneda que se detectaría
mediante la cámara al acompañar al precio.
- Similarmente, detectar el idioma del texto que rodea el precio para sugerir un posible
cambio de divisa de origen.
- Añadir la función de “deslizamiento rápido” en el selector de divisas. Es decir, poner
un índice lateral para poder ir saltando de grupo en grupo de divisas basándose en la
letra del que empiezan.
- Añadir opción de porcentaje de sobrepago. Se podrían añadir diferentes porcentajes
de cobros extra como comisión por el cambio de divisas, impuestos o propinas para
realmente saber lo que nos costaría en total.
- Añadir la posibilidad de guardar conversiones realizadas para disponer de un historial
de precios convertidos, así como poder tener una idea general del gasto total del
viaje.
- Añadir publicidad, por ejemplo, publicidad intercalada después de una cantidad de
conversiones o tiempo, o un banner inferior permanente en la sección de conversión
manual. Adicionalmente, añadir la posibilidad de eliminar dicha publicidad con
alguna compra in-app o incluso subscripción.
109
- Expandir la conversión de divisas a otro tipo de divisas que podrían resultar útiles en
un viaje. Por ejemplo, de zonas horarias o de tallas de ropa y zapatos.
12.3. Nociones aprendidas
Nunca me había enfrentado a un trabajo de estas características y sobre todo
dimensiones; pasar de observar una problemática a diseñar una solución e
implementarla no se trata de una tarea sencilla y requieren de mucho tiempo y
dedicación.
Los mayores problemas con los que se han enfrentado han sido debido a la poca
definición o no haber centrado suficiente la idea, y han llevado a la casi completa
reescritura de la primera mitad de esta memoria en dos ocasiones. Gracias a esto se ha
podido entender la importancia que tienen las primeras fases y como todo el trabajo
previo a la implementación se acaba agradeciendo mientras se va construyendo la
solución.
Una vez con la idea clara y definida es infinitamente más sencillo seguir con el resto de
las fases de desarrollo: han asegurado que se haya podido llevar a cabo de una manera
exitosa.
Gracias a la utilización de fuentes externas y librerías existentes para realizar la mayor
parte del trabajo interno de la aplicación, se ha podido centrar en la creación de una
interfaz usable, así como funcionalidades y características que beneficien y mejoren la
experiencia del usuario.
Esto ha permitido aprender paradigmas, técnicas, metodologías, tecnologías, lenguajes
y librerías, entre muchas otras cosas, que se están usando actualmente en el mercado y
así facilitar la entrada a esta industria de desarrollo móvil que cada vez está más en alza.
Además, el resultado ha gustado mucho más de lo que se anticipaba al comienzo,
ofreciendo una buena base donde seguir construyendo una aplicación que pueda ayudar
a una gran cantidad de usuarios facilitando sus próximos viajes.
110
Referencias
Android Developer. (22 de 07 de 2019). Launch checklist. Obtenido de Android
Developers: https://developer.android.com/distribute/best-
practices/launch/launch-checklist
Android Developers. (07 de 05 de 2019). Distribution dashboard. Obtenido de Android
Developers: https://developer.android.com/about/dashboards
Android Developers. (s.f.). ANRs. Obtenido de Android Developers:
https://developer.android.com/topic/performance/vitals/anr#android_vitals
Android Developers. (s.f.). Crashes. Obtenido de Android Developers:
https://developer.android.com/topic/performance/vitals/crash#android_vitals
Android Developers. (s.f.). Save data in a local database using Room. Obtenido de
Android Developers: https://developer.android.com/training/data-storage/room
Apple Inc. (s.f.). Swift - Apple Developer. Obtenido de Apple Developer:
https://developer.apple.com/swift/
Bank For International Settlements. (11 de 12 de 2016). Triennial Central Bank Survey -
Foreign exchange turnover in April 2016. pág. 10. Obtenido de
https://www.bis.org/publ/rpfx16fx.pdf
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . .
Thomas, D. (2001). Principles behind the Agile Manifesto. Obtenido de Manifesto
for Agile Software Development: https://agilemanifesto.org/principles.html
Berná Martínez, J. (20 de 11 de 2017). Guía para el desarrollo de TFG Multimedia.
Obtenido de Repositorio Institucional de la Universidad de Alicante:
http://rua.ua.es/dspace/handle/10045/73967
111
Comscore Inc. (2017, 08 24). The 2017 U.S. Mobile App Report. Retrieved from
Techcrunch: https://techcrunch.com/2017/08/25/majority-of-u-s-consumers-
still-download-zero-apps-per-month-says-comscore/
Doran, G. T. (1981). En There's a S.M.A.R.T Way to Write Managemetn's Goals and
Objectives (págs. 35-36).
Expósito, S. (11 de Agosto de 2015). El análisis DAFO. Obtenido de Comunicae Blog:
https://blog.comunicae.es/el-analisis-dafo/
Facebook. (s.f.). React Native · A framework for building native apps using React.
Obtenido de Github: https://facebook.github.io/react-native/
Google. (s.f.). Announcing Flutter beta 1: Build beautiful native apps. Obtenido de Google
Developers: https://developers.googleblog.com/2018/02/announcing-flutter-
beta-1.html
Google LLC. (s.f.). Google Translate. Obtenido de Google Play Store:
https://play.google.com/store/apps/details?id=com.google.android.apps.transla
te
Holidaysafe. (24 de 01 de 2017). Evolution of the Backpacker. Obtenido de Holidaysafe:
https://www.holidaysafe.co.uk/blog/evolution-backpacker-infographic/
Ionic. (s.f.). Build Amazing Native Apps and Progressive Web Apps with Ionic Framework
and Angular. Obtenido de Ionic Framework: https://ionicframework.com/
JetBrains. (s.f.). Kotlin on Android. Now official. Obtenido de Kotlin Blog:
https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-now-official/
Leung, H. (24 de 07 de 2017). Tesseract vs Google Vision, Round 1, Fight! The Text
extraction Wars! Obtenido de Linkedin:
112
https://www.linkedin.com/pulse/tesseract-vs-google-vision-round-1-fight-text-
extraction-hanley-leung/
Ortiz-Ospina, E., Beltekian, D., & Roser, M. (October de 2018). Trade and Globalization.
Obtenido de Our World in Data: https://ourworldindata.org/trade-and-
globalization
Our World in Data. (2019). Tourism. Obtenido de Our World in Data:
https://ourworldindata.org/tourism
Progress Software Corporation. (s.f.). NativeScript: Native mobile apps with Angular,
Vue.js, TypeScript, JavaScript. Obtenido de https://www.nativescript.org/
RealtimeBlog. (s.f.). How to choose between Agile and Lean, Scrum and Kanban — which
methodology is the best? Obtenido de RealtimeBlog:
https://realtimeboard.com/blog/choose-between-agile-lean-scrum-kanban/
Ritchie, H., & Roser, M. (2018). Technology Adoption. Obtenido de Our World in Data:
https://ourworldindata.org/technology-adoption
Sajjad, Z. (24 de 10 de 2018). Choose the Right On-Device Text Recognition (OCR) SDK on
Android Using DeltaML. Obtenido de Heartbeat: https://heartbeat.fritz.ai/choose-
the-right-on-device-text-recognition-sdk-on-android-using-deltaml-
9b4b3e409b6e
Tolomei, S. (20 de 11 de 2017). Shrinking APKs, growing installs. Obtenido de Medium:
https://medium.com/googleplaydev/shrinking-apks-growing-installs-
5d3fcba23ce2
Travel Tao, Ltd. (s.f.). xCurrency. Obtenido de Google Play Store:
https://play.google.com/store/apps/details?id=com.tratao.xcurrency&hl=en
113
Wikipedia. (s.f.). Xamarin. Obtenido de Wikipedia: https://en.wikipedia.org/wiki/Xamarin
Word Tourism Organization. (2019, 01 21). International Tourist Arrivals Reach 1.4
billion Two Years Ahead of Forecasts. Retrieved from UNWTO:
https://www2.unwto.org/press-release/2019-01-21/international-tourist-
arrivals-reach-14-billion-two-years-ahead-forecasts
Xe Corporation. (s.f.). About Us. Obtenido de Xe: https://www.xe.com/company/
114
Apéndice I – Publicación en la Google Play Store
Para realizar la publicación de una forma adecuada, estructurada y exitosa se ha seguido
el plan de despliegue de Google (Android Developer, 2019). En ella se definen una serie
de pasos y recomendaciones que seguir para llegar a lanzar nuestra app en la tienda de
aplicaciones de Google para Android.
Entre las más relevantes destacamos:
- Entender las Políticas del Programa de Desarrollador68. Cualquier app publicada en
la Google Play Store tiene que seguir y cumplir estas políticas diseñadas para
asegurar la fiabilidad de la tienda.
- Testear siguiendo las guías de calidad de Android, así como tests propios. El objetivo
es asegurar que la app cumple con unos mínimos de calidad. Además de los test
propios, vistos en el apartado de Pruebas y validación de la memoria, Google
recomienda seguir su guía de calidad69. En esta ocasión, por restricciones de tiempo,
no se han podido probar todos los requisitos establecidos, pero sí la mayoría,
asegurando así un funcionamiento correcto.
- Compilar la aplicación usando el sistema de Android App Bundle. Frente a los
paquetes de aplicaciones Android (APK) universales tradicionales, los App Bundle,
ofrecen mucha mayor flexibilidad y modularidad. Además, gracias a esto Google Play
puede distribuir la versión necesaria para cada dispositivo, con los recursos
adecuados para su resolución y traducción al idioma configurado, disminuyendo así
el tamaño de cada app.
- Definir una política de privacidad. Uno de los aspectos más importantes a la hora de
hacer pública cualquier proyecto hoy en día. Se ha creado una política de privacidad70
explicando los datos recopilados de las diferentes librerías usadas y cómo se
procesarán. Al descargar la aplicación desde la Google Play Store los usuarios
aceptan dicha política.
- Completar la ficha de la app. Uno de los aspectos más costos del proceso de
publicación y que más pueden marcar el éxito o fracaso de una app. El título,
68 https://play.google.com/about/developer-content-policy/ 69 https://developer.android.com/docs/quality-guidelines/core-app-quality 70 https://izadi.xyz/exploratu/privacy/
115
subtítulo y la descripción son los elementos clave a la hora de mejorar el
posicionamiento en la tienda. Es aquí donde se tiene que realizar el ASO, App Store
Optimization, para que la app sea lo más fácil de encontrar por los usuarios.
Para ello, se ha realizado una pequeña búsqueda de palabras clave de la
competencia, visto en el Análisis del mercado, además de seleccionar algunas
propias de elementos diferenciadores de Exploratu, para llegar a la siguiente lista
empleada en la descripción: exchange rates, exchanges, rate, converter, currency,
currencies, price, money, offline, AR, OCR, camera, free.
Esto, junto a las capturas de pantalla mostrando funciones relevantes de la app y su
uso, atraerá a los usuarios para que descarguen y prueben la app.
Decir que esto sería la primera versión de la descripción y gráficos empleados. Dadas
las facilidades que ofrece el Google Play Store en un futuro se realizarán
“experimentos en la ficha”, es decir pruebas A/B71, para ver qué combinación de
descripción, capturas, icono etc. resulta en mayores cantidades de instalaciones.
- Subir el Android App Bundle. Una vez teniendo la ficha cumplimentada con su política
de privacidad toca subir la aplicación en sí. Esto se podría subir a diferentes canales
de distribución como alpha, beta o producción. En el caso de Exploratu al ser la
primera versión disponible públicamente se distribuirá en el canal de producción. En
un futuro, para probar funciones y ver que todo funciona correctamente antes de
desplegarlo para todo el mundo se podría hacer uso de estos otros canales más
“experimentales”.
- Determinar y elegir las opciones de distribución tanto regional como de edad. Se
realizan diferentes cuestionarios para definir los usuarios que podrán acceder a la
app. Esto se realiza tanto para dispositivos, regiones, así como del contenido y edad.
Junto con esto último se obtienen los certificados adecuados para cada categoría de
edad como el PEGI. En este caso, al no contener ningún tipo de contenido sensible,
se dispondrá para todo tipo de público, para todas las regiones y dispositivos
compatibles.
- Publicar y publicitar la app. El último paso para la publicación de la app. Con todo lo
anterior listo pasaríamos finalmente a la distribución de Exploratu.
71 Pruebas A/B: pruebas donde se crean dos o más versiones de algún elemento del sistema y se
prueba para ver cuál obtiene en mejores resultados.
116
Al publicarlo, Google Play Store pasa a verificar que la aplicación cumple con las
políticas de del programa desarrollador antes de mostrarlo en la tienda. Este proceso
puede durar varios días, aunque normalmente suele ser de menos de 24 horas.
Con Exploratu, 23 horas después de enviarlo para la publicación, se recibió un correo
diciendo que no cumplía con todos los requisitos de la política del programa
desarrollador y si no se solucionaba no podría ser publicado en la tienda.
El problema resultó ser que, al haber seleccionado que la app podría usarse por
personas de todas las edades, hay un requisito extra para aplicaciones de realidad
aumentada que debe implementarse. Esto no es más que advertir a los usuarios de
que tengan cuidado con su alrededor al usar dicho modo, y en caso de que fuera
necesario, lo hagan bajo la supervisión de un adulto.
En Exploratu se ha solucionado dicho problema incluyendo un aviso al entrar en el
modo de AR. Con opciones para que no vuelva a salir el aviso o que se muestre la
próxima vez.
Figura 39: Modal de alerta avisando de haber entrado en el modo de AR
(Fuente propia)
Con este problema solucionado ya se ha podido publicar Exploratu en la Google Play
Store72 de forma correcta, siguiendo las recomendaciones de Google.
A partir de aquí queda publicitar la aplicación entre amigos, familiares, redes sociales
y portales tecnológicos, como Product Hunt73, para conseguir los primeros usuarios
y que la aplicación se dé a conocer.
72 https://play.google.com/store/apps/details?id=xyz.izadi.exploratu 73 https://www.producthunt.com/posts/exploratu
117
