sistema de aplicaciones mÓviles para el mejoramiento de …
TRANSCRIPT
SISTEMA DE APLICACIONES MÓVILES PARA EL MEJORAMIENTO DE
LA COMUNICACIÓN ENTRE COMUNIDAD Y ESTACIÓN DE BOMBEROS
DEL MUNICIPIO DE SAHAGÚN
SERGIO ERIC MORALES RICARDO
LUIS ÁNGEL MORENO SARABIA
UNIVERSIDAD DE CÓRDOBA
FACULTAD DE INGENIERÍAS
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PROGRAMA INGENIERÍA DE SISTEMAS
SAHAGÚN, CÓRDOBA
2020
SISTEMA DE APLICACIONES MÓVILES PARA EL MEJORAMIENTO DE
LA COMUNICACIÓN ENTRE COMUNIDAD Y ESTACIÓN DE BOMBEROS
DEL MUNICIPIO DE SAHAGÚN
SERGIO ERIC MORALES RICARDO
LUIS ÁNGEL MORENO SARABIA
Trabajo de grado presentada, en la modalidad de Trabajo de
Investigación y/o Extensión, como parte de los requisitos para optar al Título de
Ingeniero de Sistemas
Director (s):
Pedro Guevara Salgado, M.Sc.
UNIVERSIDAD DE CÓRDOBA
FACULTAD DE INGENIERÍAS
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PROGRAMA INGENIERÍA DE SISTEMAS
SAHAGÚN, CÓRDOBA
2020
La responsabilidad ética, legal y científica de las ideas, conceptos y resultados del
proyecto, serán responsabilidad de los autores.
Artículo 61, Acuerdo N° 093 del 26 de noviembre de 2002 del Consejo Superior.
Nota de aceptación
_______________________________
_______________________________
_______________________________
_______________________________
________________________________
Firma del jurado
________________________________
Firma del jurado
A mis padres …
A mi s hermanos…
Agradecimientos especial a:
A los docentes del área de ingeniería por su dedicación en la enseñanza del día a día.
Agradecimientos:
Al cuerpo de bomberos del municipio de Sahagún por brindar información que ayudo en
el proceso de realización de este proyecto.
vi
TABLA DE CONTENIDO
Pág.
RESUMEN ................................................................................................................. 13
ABSTRACT ............................................................................................................... 14
1. OBJETIVOS....................................................................................................... 16
1.1 OBJETIVO GENERAL .................................................................................. 16
1.2 OBJETIVOS ESPECÍFICOS ......................................................................... 16
2. REVISIÓN DE LITERATURA ......................................................................... 17
2.1 NUESTRO NICHO (PROBLEMA) ............................................................... 17
2.2 JUSTIFICACIÓN ........................................................................................... 18
2.3 ESTADO DEL ARTE ..................................................................................... 20
2.3.1 Primer Alerta ............................................................................................... 20
2.3.2 BomberosYa ................................................................................................. 21
3. MATERIALES Y MÉTODOS .......................................................................... 22
3.1 DISEÑO METODOLÓGICO ......................................................................... 22
3.1.1 TIPO DE INVESTIGACIÓN ...................................................................... 22
3.1.2 POBLACIÓN Y MUESTRA ....................................................................... 22
3.2 FASES DEL PROYECTO .............................................................................. 23
3.2.1 FASE I INVESTIGACIÓN ......................................................................... 23
3.2.2 FASE II IDENTIFICACIÓN DE REQUERIMIENTOS ........................... 24
3.2.2.1 Requerimientos Funcionales (app principal) .......................................... 24
3.2.2.2 Requerimientos No Funcionales (app principal) ..................................... 25
3.2.2.3 Requerimientos Funcionales (app bomberos) ......................................... 26
3.2.2.4 Requerimientos No Funcionales (app bomberos). .................................. 26
3.2.3 FASE III DISEÑO DEL SISTEMA DE APLICACIONES ....................... 27
3.2.4 FASE IV PRUEBAS DE FUNCIONAMIENTO DEL SISTEMA ............. 28
3.3 ANÁLISIS Y DISEÑO DEL SISTEMA ......................................................... 29
3.3.1 ANÁLISIS DEL SISTEMA ......................................................................... 29
3.3.2 DISEÑO DEL SISTEMA ............................................................................ 30
3.3.2.1 MODELOS NoSQL DE LOS ESQUEMAS DE DATOS ........................ 30
3.3.2.2 DIAGRAMA DE CASOS DE USO ......................................................... 35
3.3.2.3 CASOS DE USO – USUARIO ................................................................. 36
3.3.2.4 CASOS DE USO – BOMBEROS............................................................. 39
3.3.2.5 DIAGRAMAS DE SECUENCIAS .......................................................... 42
3.3.2.6 DIAGRAMA DE COMPONENTES ....................................................... 43
3.4 DESARROLLO DEL APLICATIVO ............................................................ 43
3.4.1 TECNOLOGÍAS UTILIZADAS ................................................................. 44
3.4.1.1 Flutter SDK .............................................................................................. 44
3.4.1.2 Firebase..................................................................................................... 47
3.4.1.3 Google maps ............................................................................................. 51
3.4.1.4 agora.io ..................................................................................................... 52
3.4.2 LENGUAJE / LIBRERÍAS / PAQUETES ................................................. 53
3.4.2.1 Dart ........................................................................................................... 53
3.4.2.2 PUB.DEV .................................................................................................. 55
3.4.3 ARQUITECTURA DE ESTADOS ............................................................. 57
3.4.3.1 Bloc y Provider ......................................................................................... 57
4. RESULTADOS Y DISCUSIONES .................................................................... 62
4.1 PRUEBAS DE FUNCIONAMIENTO / MANUAL DE USUARIO .............. 62
5. CONCLUSIONES .............................................................................................. 75
6. RECOMENDACIONES .................................................................................... 76
7. BIBLIOGRAFÍA. ............................................................................................... 77
ANEXOS .................................................................................................................... 80
ix
LISTADO DE ANEXOS
Pág.
Anexo 1. Aplicaciones instaladas en dispositivo real ............................................... 80 Anexo 2. Aplicación principal en la Play Store ........................................................ 80
Anexo 3. Mock-Up de las Aplicaciones en Adobe XD ............................................. 81 Anexo 4. Colores Usados en las Aplicaciones........................................................... 81
Anexo 5. Fuente tipográfica usada. .......................................................................... 82 Anexo 6. Alertas en la base de datos Firestore ........................................................ 82
x
LISTADO DE FIGURAS
................................................................................................................................ Pag.
Figura 1. Aplicación Primer Alerta.......................................................................... 20
Figura 2. BomberosYa flujo de la aplicación móvil ................................................. 21 Figura 3. BomberosYa Panel de administración ..................................................... 21
Figura 4. Modelo Cloud Firestore ............................................................................ 31 Figura 5. Path Schema in Firestore .......................................................................... 32
Figura 6. Esquema de Alertas en Firestore.............................................................. 32 Figura 7. Esquema de datos de los bomberos .......................................................... 33
Figura 8. Modelo Relacional del Sistema de Alerta. ............................................... 34 Figura 9. Diagrama Casos de Uso – Usuario ........................................................... 35
Figura 10. Diagrama Casos de Uso – Bomberos ...................................................... 35 Figura 11. Diagrama de Secuencia de Envío de Alerta ........................................... 42
Figura 12. Diagrama de Secuencia Login (app principal) ....................................... 42 Figura 13. Diagrama de Componentes ..................................................................... 43 Figura 14. Servicios de Firebase ............................................................................... 44
Figura 15. Stateless and Stateful widgets in flutter ................................................. 45 Figura 16. Widget Básico en flutter ......................................................................... 46
Figura 17. Crear un proyecto en firebase ................................................................ 47 Figura 18. Paso 1, dar nombre al proyecto en firebase ........................................... 47
Figura 19. Paso 2, habilitar Google Analytics. ......................................................... 48 Figura 20. Paso 3, elegir la cuenta de firebase ......................................................... 48
Figura 21. Feedback Creando el proyecto de Firebase ........................................... 49 Figura 22. Feedback, proyecto de firebase creado .................................................. 49
Figura 23. Activando Google Auth en la consola de firebase. ................................. 50 Figura 24. Creando base de datos en firebase. ........................................................ 50
Figura 25. Habilitando Storage en Firebase. ........................................................... 51 Figura 26. Consumo de Servicios de Google ............................................................ 52
Figura 27. Precios de agora.io .................................................................................. 52 Figura 28. Dart to native – AOT .............................................................................. 53
Figura 29. Stateful Hot Reload in Flutter with Dart ............................................... 54 Figura 30. UIs in Flutter with Dart .......................................................................... 54
Figura 31. Hola mundo en Dart ............................................................................... 55 Figura 32. Ejemplo Dependencias de la aplicación principal ................................. 56
Figura 33. Home Page del repositorio de paquetes de Dart y Flutter ..................... 56 Figura 34. Bloc Architecture .................................................................................... 58
Figura 35. Obtener Ubicación _ Bloc ....................................................................... 59 Figura 36. Capturar Imagen _ Bloc ......................................................................... 60
Figura 37. Seleccionar Categoría _ Bloc .................................................................. 61 Figura 38. Primer Inicio de la Aplicación Principal ................................................ 62
Figura 39. Inicio de Sesión Aplicación Principal ..................................................... 63 Figura 40. Ingreso de Código de Acceso, Aplicación Principal ............................... 63
Figura 41. Home Page - Activar GPS en Aplicación Principal ............................... 64 Figura 42. Activación de snackBar al obtener Ubicación ....................................... 64
Figura 43. Feedback de la Animación en Home Page, Aplicación Principal .......... 65
xi
Figura 44. Acción de tomar imagen en Aplicación Principal .................................. 65 Figura 45. Página de Confirmar foto tomada, Aplicación Principal ...................... 66
Figura 46. Feedback subiendo Imagen a la nube, Aplicación Principal ................. 66 Figura 47. Seleccionando la Categoría, Aplicación Principal ................................. 67
Figura 48. Componente de Alertar, Aplicación Principal ....................................... 67 Figura 49. Página de Espera al enviar alerta, Aplicación Principal ....................... 68
Figura 50. Alerta Recibida, Aplicación de Bomberos ............................................. 69 Figura 51. Aceptar o Rechazar Alerta, Aplicación de Bomberos ........................... 70
Figura 52. Alerta Aceptada, Aplicación Principal ................................................... 71 Figura 53. Page de video llamada ............................................................................. 72
Figura 54. Vista de llamada entre 2 personas .......................................................... 73 Figura 55. Alerta Atendida, feedback ...................................................................... 73
Figura 56. Home Page App Bomberos ..................................................................... 74 Figura 57. Widget de Llamada entrante .................................................................. 74
xii
LISTADO DE TABLAS
Pág.
Tabla 1. Versiones de la plataforma Android .......................................................... 23 Tabla 2. Requerimientos Funcionales (app principal) ............................................ 24
Tabla 3. Requerimientos No Funcionales (app principal) ....................................... 25 Tabla 4. Requerimientos Funcionales (app Bomberos) ........................................... 26
Tabla 5. Requerimientos No Funcionales (app Bomberos) ..................................... 26 Tabla 6. Módulos Aplicación Principal .................................................................... 30
Tabla 7. Módulos Aplicación Bomberos .................................................................. 30 Tabla 8. Caso de Uso (Iniciar Sesión) app principal ............................................... 36
Tabla 9. Caso de Uso (Iniciar Alerta) app principal ............................................... 36 Tabla 10. Caso de Uso (Obtener Ubicación) app principal ..................................... 37
Tabla 11. Caso de Uso (Capturar Incidente) app principal .................................... 37 Tabla 12. Caso de Uso (Seleccionar Categoría) app principal ................................ 38
Tabla 13. Caso de Uso (Enviar Alerta) app principal ............................................. 39 Tabla 14. Caso de Uso (Recibir Alerta) app bomberos ........................................... 39 Tabla 15. Casos de Uso (Aceptar Alerta) app bomberos ......................................... 40
Tabla 16. Caso de Uso (Rechazar Alerta) app bomberos ........................................ 40 Tabla 17. Caso de Uso (Abrir Google Maps) app bomberos ................................... 40
Tabla 18. Lista de paquetes usados .......................................................................... 57
13
RESUMEN
Este proyecto de investigación tiene como finalidad diseñar un sistema de alertas para
mejorar la comunicación entre la comunidad y el cuerpo de bomberos del municipio de
Sahagún - Córdoba. El sistema de alertas dispone de dos aplicaciones móviles; una
aplicación para que la comunidad reporte los incidentes, capturando los datos de la alerta
como son: ubicación (GPS), foto del incidente y la categoría. Esta información se envía
a la segunda aplicación que es usada únicamente por el Cuerpo de Bomberos; los
bomberos podrán aceptar la alerta y atenderla, o descartar falsas alarmas.
El sistema de alertas se desarrolló bajo el bajo el framework llamado Flutter1 y el
backend como servicio llamado Firebase, ambos desarrollados por Google; utilizando el
sistema Android para desarrollar y ejecutar el proyecto. Con este sistema, un usuario
usando la red 3G o 4G en su dispositivo Android; será capaz de enviar una alerta en un
tiempo mínimo 20 segundos (esto dependerá del tipo de dispositivo). Este proyecto da
una opción tecnológica para que los bomberos ofrezcan una mejor atención y respuesta
ante los incidentes.
Palabras Clave: Sistema de Alertas, Emergencias, Bomberos, Android, Flutter.
1 Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and
desktop from a single codebase.
14
ABSTRACT
This research project aims to design an alert system to improve communication between
the community and the fire department of the municipality of Sahagún - Córdoba. The
alert system has two mobile applications; an application for the community to report
incidents, capturing the alert data such as: location (GPS), photo of the incident and the
category. This information is sent to the second application that is used only by the Fire
Department; firefighters may accept the alert and attend to it, or dismiss false alarms.
The alert system was developed under the framework called Flutter2 and the backend as
a service called Firebase, both developed by Google; using the Android system to
develop and execute the project. With this system, a user using the 3G or 4G network on
their Android device; It will be able to send an alert in at least 20 seconds (this will
depend on the device phone). This project gives a technological option for firefighters to
offer better attention and response to incidents.
Key words: Alert System, Emergencies, Firefighters, Android, Flutter.
2 Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and
desktop from a single codebase.
15
INTRODUCCIÓN
La presente investigación se refiere al tema de sistemas informáticos de alertas, a través
de los cuales se tiene la facultad de informar incidentes que ocurran a nuestro alrededor;
SAT o Sistemas de alertas tempranas, aplicado específicamente al mejoramiento de la
forma en la que los ciudadanos del municipio de Sahagún Córdoba, dan alerta y se
comunican con el cuerpo de bomberos ante cualquier tipo de eventualidad o urgencia
que se presente en el territorio municipal de Sahagún.
La característica principal de los sistemas de alertas es que hacen uso de la tecnología y
la informática ya sea en sus procesos, en el análisis de datos, en la sistematización o la
organización.
El propósito de esta investigación desde lo más simple es dar una opción tecnológica
para que la gente pueda comunicarse con la instalación de bomberos, pero, partiendo de
lo más elemental, como alertar, hasta algo más complejo o elaborado como un sistema
de registro, progreso y medición. Para el desarrollo del sistema nos valemos de las
tecnologías de la información y la comunicación, del uso de geoposicionamiento y de
plataformas de desarrollo móvil.
Encontramos útil y necesario un sistema como el expuesto debido a que Sahagún es una
ciudad que cuenta con la infraestructura de redes y comunicación que sirven para el
desarrollo de este, además cuenta con el mapeo de las calles que la conforman en la
plataforma de Google maps y sus habitantes poseen dispositivos móviles con acceso a
ubicación en tiempo real.
En el ámbito profesional, como Ingeniero de Sistemas, surge el interés por conocer los
limitantes que tienen los habitantes del municipio de Sahagún y su cuerpo de bomberos
en cuanto al alcance que se dispone al momento de presentarse una eventualidad de
urgencia y dar alerta de esta, para así implementar nuevas tecnologías que mejoren los
sistemas establecidos en la comunidad.
16
1. OBJETIVOS
1.1 OBJETIVO GENERAL
Diseñar y desarrollar un sistema de notificación a eventualidades para el cuerpo de
bomberos y la comunidad de la ciudad de Sahagún.
1.2 OBJETIVOS ESPECÍFICOS
✓ Entender el funcionamiento y normatividad del sistema de notificación a
eventualidades dentro del cuerpo de bomberos del municipio de Sahagún.
✓ Realizar el análisis y levantamiento de requerimientos del sistema de
notificación de eventos.
✓ Desarrollar el sistema de notificación a eventos para la comunidad del
municipio de Sahagún.
✓ Realizar pruebas de funcionamiento al sistema para cada módulo definido en
los requerimientos.
17
2. REVISIÓN DE LITERATURA
2.1 NUESTRO NICHO (PROBLEMA)
En lo transcurrido entre el 1ro de enero y 9 de agosto de 2019, se presentaron más de
37.976 emergencias ante eventos ocurridos en todo el país según los datos ofrecidos por
la DNBC (Dirección Nacional Bomberos Colombia) de esos más de 37 mil eventos se
han presentado centenares de Falsas Alarmas que son producidas por bromas o
desconocimientos de aquellas personas que reportan la alarma. Entrevistas hechas al
Cuerpo de Bomberos de Bucaramanga afirman: “que estas falsas emergencias ocasionan
el despliegue innecesario de hombres y maquinaria; se estima que los bomberos pierden
hasta 20 minutos en la atención de un caso ficticio, broma o mal información”
(vanguardia.com, 2019). En esta misma entrevista, “En la mayoría de veces se trata
personas que llaman a molestar. Casi todas estas falsas alarmas nos llegan a través de la
línea de emergencias 119”, informó Williams Domínguez Serrano, capitán del Cuerpo
Oficial de Bomberos de Bucaramanga.
Este socorrista también indicó que, en algunos casos, las falsas alarmas se generan a raíz
de confusiones por parte de la comunidad. Según Domínguez Serrano, “hemos atendido
situaciones en las que nos llamaron por la supuesta presencia de humo en un inmueble,
pero cuando llegamos hasta el lugar constatamos que se trata de tareas de fumigación”.
“También se han atendido casos en los que la comunidad cree que es humo, pero resulta
que es una persona enferma que se está realizando nebulizaciones”, explicó el rescatista.
Cada vez que se atiende una falsa alarma se estima que se pierden entre 15 y 20 minutos
desde que los bomberos reaccionan a la alarma y, esta pérdida de tiempo afecta
seriamente en el caso que se dé una emergencia real mientras los bomberos atienden una
falsa.
De un promedio de 17.500 llamadas que recibe la línea de atención 123 entre lunes y
viernes, 14.000 (80 %) son bromas o falsas alarmas, según informó la Policía
Metropolitana de Cali, que se encarga de esta central de emergencias de la ciudad
(elpais.com,2016).
18
2.2 JUSTIFICACIÓN
El estado colombiano a través del organismo del Ministerio de Interior y su dependencia
la Dirección Nacional de Bomberos de Colombia, ha estipulado normativas que regulan
la manera en la que se establece la comunicación en términos de atención a los
ciudadanos. Estableciendo en la Ley 1575 de 2012 en su Artículo 2, Parágrafo 2 que "es
deber del Estado asegurar su prestación eficiente a todos los habitantes del territorio
nacional, en forma directa a través de Cuerpos de Bomberos Oficiales, Voluntarios y
aeronáuticos" de Colombia.
A su vez con el fin de preservar una gestión integral y preparativos contra incendio,
atención de rescates en todas sus modalidades y la atención de incidentes con materiales
peligrosos se han establecido funciones para los cuerpos de bomberos. En Al artículo 22
Parágrafo 6 de la Ley 1575 se especifica dentro de sus funciones que cada cuerpo de
bomberos debe “Apoyar a los comités locales de gestión del riesgo en asuntos
bomberiles”.
Así mismo en el Artículo 3 Parágrafo 3 se decreta que “Los entes territoriales deben
garantizar la inclusión de políticas, estrategias, programas, proyectos y la cofinanciación
para la gestión integral del riesgo contra incendios, rescates y materiales peligrosos en
los instrumentos de planificación territorial e inversión pública”, dejando en evidencia
dichos artículos el claro respaldo a la inclusión de proyectos que contribuyan a la
mitigación, planeación o erradicación en materia de presencia de emergencias; y con el
fin de brindar apoyo a lo anteriormente mencionado este proyecto se vale del uso de las
nuevas tecnologías de la información y la comunicación que vienen brindando un aporte
valioso a las empresas en diferentes áreas de atención.
Se ha encontrado que el uso de las tecnologías de la información y comunicación dentro
del proceso de atención de las empresas y entidades para las comunidades genera un
avance y mejoría inmediata. El diario El Tiempo afirmó en su artículo Tecnologías para
emergencias que:
El Mintic lanzó el Sistema Nacional de Telecomunicaciones de Emergencias, con
base en una norma (Decreto 2434) que otorga las facultades a las entidades para
establecer e implementar las regulaciones y funciones en las redes de los
19
prestadores de servicios, para beneficiar a los colombianos en situación de riesgo.
Tiene como objetivo facilitar, apoyar y fortalecer las comunicaciones requeridas
en los procesos de la gestión del riesgo de desastres
Como es el caso de Saneso, para prevenir siniestros en edificaciones, el portal El
Tiempo expuso:
El objetivo principal de Saneso (sanesoapp.com) es evitar siniestros en las
edificaciones. Y busca, en caso de una emergencia inminente, que los sistemas
previstos para mitigar los daños sean funcionales y cumplan el objetivo de
preservar la vida y los bienes. Permite evaluar si una obra civil está protegida
contra incendios, si sus rutas de evacuación son adecuadas o si la estructura es
sismorresistente, entre otros.
Inclusive la aplicación de la Cruz Roja para catástrofes donde “hay una enfocada que
ofrece acceso a alertas climáticas, consejos de seguridad e información de preparación y
monitoreo de sitios de riesgo donde se encuentren seres queridos”.
Además como apoyo al uso de tecnologías que hacen uso de internet, según un estudio
hecho por la firma Deloitte sobre el consumo móvil del país en 2019, en Colombia el
69% de las personas para comunicarse con otros usan las Redes Sociales y mensajería
instantánea por encima del medio “Voz” en el cual tenemos las llamadas de voz y
aquellas por VoIP que hacen uso de internet y que tiene un porcentaje del 57%, que está
por debajo de las anteriores. Dicho estudio también arroja que un 40% hace uso de
mapas para navegar a sitios de interés.
20
2.3 ESTADO DEL ARTE
2.3.1 Primer Alerta
Primer Alerta3 es una aplicación desarrollada en Argentina para teléfonos celulares que
funciona integrada a un Sistema Web y permite tener conectados al Cuartel de
Bomberos con todos los miembros del cuerpo activo.
La App permite notificar sobre un incendio, accidente, rescate, auxilio u otro tipo de
emergencia en tiempo real a todo el personal adherido del cuartel de forma inmediata y
privada.
Cave recalcar que esta es una aplicación para cuerpos de bomberos netamente, en la cual
un líder registra miembros del equipo dentro del sistema, y emite alertas a sus cuarteles
o miembros.
Figura 1. Aplicación Primer Alerta
Fuente: (primeralerta.com, 2020)
3 Primera Alerta una aplicación que conecta los Cuarteles de Bomberos con cada uno de sus miembros [en línea].
Disponible en Internet: (https://www.primeralerta.com/, 2020)
21
2.3.2 BomberosYa
BomberosYa4 es otra aplicación Argentina que al igual que PrimerAlerta es solo para
cuerpos de bomberos, en la cual puedes registrar bomberos de un determinado cuartel y
gestionar las alertas, como se muestra en su website:
Figura 2. BomberosYa flujo de la aplicación móvil
Fuente:(bomberosya.com, 2019)
También ofrece un panel con el historial de alertas y aquellos datos que se relacionan
con esta.
Figura 3. BomberosYa Panel de administración
Fuente:(bomberosya.com, 2019)
4 BomberosYa [en línea].
Disponible en Internet: (https://bomberosya.com/,2019)
22
3. MATERIALES Y MÉTODOS
3.1 DISEÑO METODOLÓGICO
3.1.1 TIPO DE INVESTIGACIÓN
“Investigar significa llevar a cabo diferentes acciones o estrategias con el fin de
descubrir algo. Así, dichos actos se dirigen a obtener y aplicar nuevos conocimientos,
explicar una realidad determinada o a obtener maneras de resolver cuestiones y
situaciones de interés. La investigación es la base del conocimiento científico, si bien no
toda investigación es científica de por sí” dice Oscar Castillero Mimenza psicólogo en
Barcelona.
Podemos encontrar dos tipos de investigación en función del propósito con el que se
realizan. La Investigación pura o teórica y la Investigación aplicada; de las cuales este
proyecto encaja en la parte de investigación aplicada. Dicho tipo está centrado en
encontrar mecanismos o estrategias que permitan lograr un objetivo concreto, como
curar una enfermedad o conseguir un elemento o bien que pueda ser de utilidad. Por
consiguiente, el tipo de ámbito al que se aplica es muy específico y bien delimitado,
puesto que no se trata de explicar una amplia variedad de situaciones, sino que más bien
se intenta abordar un problema específico.
Y si nos situamos en nuestro problema lo que tratamos es de dar un sistema de alerta
para la comunidad del municipio de Sahagún y a su cuerpo de bomberos ya que hemos
establecido un objetivo central y común.
3.1.2 POBLACIÓN Y MUESTRA
Este producto e investigación aplicada se centra en el municipio de Sahagún Córdoba,
por lo cual definimos al municipio como población.
23
3.2 FASES DEL PROYECTO
3.2.1 FASE I INVESTIGACIÓN
Esta fase estuvo centrada en la recolección de información concerniente a:
• Normas o leyes que rigen a las estaciones de bomberiles sobre cómo actuar y
aquellas diferentes emergencias que pueden y deber atender. La Ley 1575 de
2012, por medio de la cual se establece la Ley General de Bomberos de
Colombia y la resolución 0661 de 2014, por la cual se adopta el Reglamento
Administrativo, Operativo, Técnico y Académico de los Bomberos de Colombia
son las que los rigen.
• Aplicaciones que tuviesen relación directa con los tópicos que trabajamos, como
sistemas de alerta, ubicación geográfica y categorización, de las cuales se
mencionan en el punto 2.3 del Estado del Arte.
• Tecnologías que más se adecuaban a un desarrollo móvil nativo, que pudiésemos
usar a bajo y alto nivel, para realizar las operaciones de geoposicionamiento,
captura de imágenes, y la video comunicación en tiempo real que se agregó en
última instancia.
• Indagar el porcentaje de Apis de Android usadas a nivel mundial, lo cual nos da
un panorama general del mercado; los datos se encuentran la Tabla 1.
• Buscar prototipos de referencias o ejemplos sobre las características que se
requirieron.
Tabla 1. Versiones de la plataforma Android
Fuente: (developer.android.com, 2020)
Version Codename API Distribution
4.4 KitKat 19 6.90%
5.0 Lollipop
21 3.00%
5.1 22 11.50%
6.0 Marshmallow 23 16.90%
7.0 Nougat
24 11.40%
7.1 25 7.80%
8.0 Oreo
26 12.90%
8.1 27 15.40%
9.0 Pie 28 10.40%
De las versiones de la Tabla 1, se da soporte desde la versión 5.0 hasta la versión 9.0
24
3.2.2 FASE II IDENTIFICACIÓN DE REQUERIMIENTOS
En esta fase del proyecto, se realizó un análisis global de cómo debían funcionar las
Aplicaciones móviles, dicho análisis arrojó los siguientes requerimientos, “separado por
aplicaciones”
3.2.2.1 Requerimientos Funcionales (app principal)
Tabla 2. Requerimientos Funcionales (app principal)
Identificador Descripción Prioridad
RF 01 La aplicación deberá ser de fácil acceso al usuario. Muy Alta
RF 02 Los usuarios deberán iniciar sesión con una cuenta de
Google.
Alta
RF 03 La aplicación deberá pedir permisos para usar las APIS
de ubicación, cámara y micrófono.
Alta
RF 04 Para iniciar el proceso de alertar, este debe ser
intencional, por lo que en la aplicación esta interacción
no será un simple botón.
Alta
RF 05 Al iniciar la aplicación se deberá pedir al usuario que
active el GPS si este no lo está.
Alta
RF 06 La toma de la captura del incidente deberá hacerse
internamente en la aplicación.
Media
RF 07 No está permitido escoger una foto de la galería del
dispositivo que realiza la alerta.
Alta
RF 08 Si por alguna razón el usuario al tomar la foto no cree
que esta fue tomada adecuadamente, se le dará la
opción de volver a tomar la foto.
Alta
RF 09 Una vez tomada la foto, si el usuario desea continuar
con el proceso, se subirá la foto al servidor de archivos
en la nube.
Alta
RF 10 Mientras se sube la foto a la nube, el usuario podrá
escoger la categoría del incidente que se le está
presentando.
Alta
RF 11 Una vez completado el requerimiento RF 09 se le
mostrará un popUp5 al usuario en el cual podrá enviar
la alerta.
Alta
RF 12 Si el usuario decide mandar la alerta, se redireccionará
a una nueva pantalla en la cual estará esperando por
respuesta.
Alta
RF 13 En la pantalla de espera se estará escuchando a la base
de datos por cambios en el estado de la alerta.
Alta
RF 14 No se podrá salir de la aplicación con el gesto de ir
atrás. Para salir de la aplicación esta deberá cerrase
manualmente, así evitamos que por error se salga el
usuario.
Muy Alta
5 popUp es un widget emergente que se sobrepondrá a la pantalla actual, este puede ser cerrado.
25
Además de los requerimientos anteriores, surgieron nuevas funcionalidades que no se
establecieron al inicio del proyecto, una de ellas en la cual se le da la opción al usuario
de realizar una video llamada en tiempo real con el cuerpo de bomberos.
3.2.2.2 Requerimientos No Funcionales (app principal)
Tabla 3. Requerimientos No Funcionales (app principal)
Identificador Descripción Prioridad
RNF 01 Como se estipula en el RF 04, la intencionalidad de iniciar
la alerta deberá reflejarse al completar una animación que
se accionará al dejar presionado un widget por una
cantidad de segundos mayor a 2 y menor a 4.
Alta
RNF 02 Una vez completado la animación de la acción en el RNF
01 se reflejará en este mismo widget que la acción fue
completada de manera correcta, y se deberá redireccionar
al usuario al siguiente paso.
Alta
RNF 03 Los textos usados en cada widget deberán ser lo
suficientemente grandes para que cualquier persona los
pueda leer.
Alta
RNF 04 Los colores usados en toda la aplicación serán tenues,
aprovechando el uso del blanco y escalas de negro.
Media
26
3.2.2.3 Requerimientos Funcionales (app bomberos)
Tabla 4. Requerimientos Funcionales (app Bomberos)
Identificador Descripción Prioridad
RF 01 La aplicación de bomberos solo estará disponible para
ellos.
Alta
RF 02 No será necesario el registro o login para usar la
aplicación. Esto se hará por “debajo”.
Alta
RF 03 Al llegar una notificación de alerta, ésta al ser abierta
mostrara una página con la foto y la categoría del
incidente.
Alta
RF 04 Se le dará la opción de “aceptar” o “rechazar” la alerta. Alta
RF 05 Si escoge la opción de “rechazar” se le preguntara si
está seguro de realizar dicha acción.
RF 06 Se dará la opción de abrir en una vista de Google maps
el lugar del incidente.
Alta
RF 07 Los bomberos podrán ver el camino más optimo y la
distancia hacia el lugar del incidente en la aplicación
oficial de Google maps.
Alta
RF 08 Una vez llegado al lugar del incidente, podrán marcar
como “atendida” la alerta.
Alta
3.2.2.4 Requerimientos No Funcionales (app bomberos).
Tabla 5. Requerimientos No Funcionales (app Bomberos)
Identificador Descripción Prioridad
RNF 01 Los textos usados en cada widget deberán ser lo
suficientemente grandes para que cualquier persona los
pueda leer.
Alta
RNF 02 Los colores usados en toda la aplicación serán tenues,
aprovechando el uso del blanco y escalas de negro.
Alta
27
3.2.3 FASE III DISEÑO DEL SISTEMA DE APLICACIONES
Esta fase, describe en forma general el Sistema y se toman las consideraciones
pertinentes en cuanto al Software necesario para el diseño y desarrollo de este, así como
también se representan las funciones del Sistema, a través de esquemas y diagramas
tales como: Casos de uso, Diagramas de secuencia, Diagramas de clases y Diagramas de
Componente.
Se realizó el diseño de las interfaces de Usuarios, el modelo de datos en Firebase y se
tuvo en consideración, que estos diseños se adaptaran de la mejor manera a los
requerimientos funcionales del Sistema.
La plataforma escogida para realizar el sistema de aplicaciones fue Android, pero se
realizó bajo el SDK de Flutter, el cual es creado y mantenido por Google, más adelante
se da una aclaración de las herramientas usadas a detalle.
El backend de la aplicación soportado bajo Firebase, que no solo es una base de datos
NoSQL, si no, todo un backend como servicio, es decir, que ofrece todo aquello que es
común en una aplicación que requiera un servidor, como autenticación, base de datos,
almacenamiento de archivos (como imágenes), cloud messaging, machine learning y
muchas más herramientas.
Todo lo expuesto anteriormente, está representado en forma detallada en el ítem 3.3.2
Diseño del sistema en el presente documento.
28
3.2.4 FASE IV PRUEBAS DE FUNCIONAMIENTO DEL SISTEMA
Luego de haber revisado cada módulo, y hecho las correcciones en los errores que se
presentaron durante la ejecución de la Aplicaciones móviles, se realizaron pruebas de
funcionamiento real, para ambas aplicaciones, estas pruebas se mencionan a
continuación:
✓ Primera apertura de la aplicación principal, en la que se piden adecuadamente los
permisos para acceder a usar la cámara, ubicación y micrófono del dispositivo.
Esta acción se pide solo si el usuario no ha dado los permisos, para todos
aquellos casos en que se vuelva a abrir la aplicación, una vez dado los permisos,
ya no se volverán a pedir.
✓ Registro y/o Login a través de un correo de Google, para dicha acción el usuario
selecciona el correo con el cual desea identificarse.
✓ Captura del incidente, la cual requiere que el dispositivo tenga una versión
Android 5 o superior, y no mayor a la 9. Esta prueba funciona para dispositivos
con una memoria RAM de al menos 2GB, en dispositivos antiguos no se
garantiza que se pueda realizar la foto.
✓ Prueba del paso 3, en el cual se sube la foto a Firebase en el apartado de Storage,
el tiempo depende del dispositivo móvil y la conexión a internet, nosotros
optimizamos las imágenes para que ocupen el menor tamaño posible, pero
conservasen una calidad buena, de manera que el proceso no se extendiese.
✓ Una vez subida la imagen, el siguiente paso es mandar la notificación, esta
prueba manda una petición HTTP a la API de Google que se encarga de manejar
FCM (Firebase Cloud Messaging) en la cual le pasamos la referencia o ID de la
alerta que se guardó en la base de datos.
✓ Ya mandada la alerta, en la aplicación de bomberos probamos mediante un
REST CLIENT como Postman6, para crear alertas de manera rápida y verificar
los datos que llegaban a la aplicación. De manera que pudiésemos solucionar
cualquier error evitando que las aplicaciones no se comunicasen.
✓ En la aplicación de bomberos se da la opción de abrir Google maps para ver la
ruta optima, para ello se testeo con varios puntos aleatorios en Sahagún, y
verificamos que la información fuese acorde a la arrojada por Google maps. Así
6 Postman es un software para probar Apis, sitio web https://www.postman.com/
29
cuando los bomberos recibiesen la alerta, pudiesen dirigirse al lugar sin
problema.
✓ Como última prueba, se realizaron llamadas entre ambas aplicaciones, estando
conectados a red 4G y una red wifi doméstica, la cual arrojo mejor conexión y
estabilidad en la imagen si se está en una red 4G, resaltando que la red WIFI es
buena si no tiene mucho tráfico de datos. En ambos casos la calidad del audio fue
buena.
Las pruebas se describen gráficamente en el ítem 4 de Resultados y Discusiones.
3.3 ANÁLISIS Y DISEÑO DEL SISTEMA
3.3.1 ANÁLISIS DEL SISTEMA
Se diseñaron 2 aplicaciones móviles, que dividen las funcionalidades que cada una debe
ejecutar.
La aplicación principal, como hemos venido llamándola, es aquella que usará la
comunidad del municipio de Sahagún, en la cual se manda la alerta con los 3 parámetros
definidos en nuestros requerimientos, además de estos, internamente manejamos la fecha
exacta en que es creada, el usuario que la genera y un estado de la alerta, el cual
abarcaremos más adelante.
Por otro lado, la aplicación de los bomberos es exclusiva de la estación, la cual tiene el
control sobre las alertas que se generan, y tiene la habilidad de ver donde ocurre
exactamente el incidente.
A continuación, en la tabla 5, se muestran los módulos de la comunidad y bomberos.
30
Tabla 6. Módulos Aplicación Principal
Módulos Pasos Paginas
Módulo de Inicio de Sesión 2 1
Módulo de Ubicación 2 1
Módulo de Captura de Imagen 2 2
Módulo de Categoría 1 1
Módulo de Subida y Alerta 1 1
Módulo de Alerta 0 2
Módulo de video llamada 1 1
Tabla 7. Módulos Aplicación Bomberos
Módulos Pasos Paginas
Módulo de Inicio de Sesión 0 0
Módulo de Espera 0 1
Módulo de Alerta Indeterminado 3
Módulo de video llamada 0 1
El diseño de estos módulos se mostrará en el ítem 4 de Resultados y Discusiones.
3.3.2 DISEÑO DEL SISTEMA
Las imágenes que se muestran a continuación, representan la fase denominada diseño
del Sistema para cada uno de los módulos de la App. Se realizaron utilizando software
libre y de licencia paga, como StartUML, Adobe Illustrator, Adobe XD y Adobe
Photoshop.
3.3.2.1 MODELOS NoSQL DE LOS ESQUEMAS DE DATOS
“Las bases de datos NoSQL están diseñadas específicamente para modelos de datos
específicos y tienen esquemas flexibles para crear aplicaciones modernas. Las bases de
datos NoSQL son ampliamente reconocidas porque son fáciles de desarrollar, por su
funcionalidad y el rendimiento a escala.” (aws.amazon.com/es/nosql)
Existen varios tipos de base de datos NoSQL, en nuestro caso, como usamos Firebase,
estamos forzados a usar el tipo basado en documentos; en estos documentos los datos se
representan a menudo como un objeto o un documento de tipo JSON porque es un
modelo de datos eficiente e intuitivo para los desarrolladores.
31
Además de lo anterior, la base de datos que usamos específicamente fue Cloud Firestore
“Cloud Firestore es una base de datos flexible y escalable para la programación
en servidores, dispositivos móviles y la Web desde Firebase y Google Cloud
Platform. Al igual que Firebase Realtime Database, mantiene tus datos
sincronizados entre apps cliente a través de agentes de escucha en tiempo real y
ofrece asistencia sin conexión para dispositivos móviles y la Web, por lo que
puedes compilar apps con capacidad de respuesta que funcionan sin importar la
latencia de la red ni la conectividad a Internet.”
(firebase.google.com/docs/firestore)
A partir del modelo de datos NoSQL de Cloud Firestore, almacenamos los datos en
documentos que contienen campos que se asignan a valores. Estos documentos se
almacenan en colecciones, que son contenedores para nuestros documentos y que
podemos usar para organizar nuestros datos y compilar consultas.
La siguiente imagen ilustra el esquema de Cloud Firestore:
Figura 4. Modelo Cloud Firestore
Fuente: (firebase.google.com, 2020)
También podemos verlo como un sistema de directorios en Linux, en el cual tendremos
una colección de documentos, y estos documentos a su vez pueden tener más
colecciones, pero siempre en este patrón, como se ilustra en la siguiente imagen.
32
Figura 5. Path Schema in Firestore
Fuente: (firebase.google.com, 2020)
Una vez explicado que es cloud firestore y como se guardan los datos, podemos mostrar
nuestro esquema de alerta, en cual posee los siguientes datos:
Figura 6. Esquema de Alertas en Firestore
Fuente: Autores
33
En el cual guardamos 7 campos que definen una alerta.
• ID: Este corresponde al id del usuario logueado que mando la alerta.
• Latitude: Corresponde la posición latitudinal.
• Longitude: Corresponde la posición longitudinal.
• Categories: Corresponde a la categoría del incidente.
• getDownloadUrl: Es la URL de la imagen que se guardó en el Storage.
• State: Es el estado de la alerta, que puede ser, pendiente, aceptada, rechazada o
atendida.
• Created: Que sería la fecha en que se crea la alerta.
Ahora en lo que respecta a los bomberos, tenemos un único documento, que guarda
información de manera dinámica, el cual podemos ver en la siguiente imagen.
Figura 7. Esquema de datos de los bomberos
Fuente: Autores
El state indica si se está atendiendo una alerta en el momento que el usuario entra en la
aplicación principal; userId es una cadena que almacena el id del usuario en caso de que
se acepte una alerta y el token es el identificador de los bomberos para poder recibir las
push notifications de firebase cloud messaging.
Si bien en una base de datos relacional, estamos acostumbrados a ver un diagrama
relacional entre entidades, podríamos armar uno como el que se muestra a continuación.
34
Figura 8. Modelo Relacional del Sistema de Alerta.
Fuente: Autores
Del cual podemos decir que un usuario puede realizar múltiples alertas y, una alerta en
especifica solo es emitida por un único usuario.
35
3.3.2.2 DIAGRAMA DE CASOS DE USO
Figura 9. Diagrama Casos de Uso – Usuario
Figura 10. Diagrama Casos de Uso – Bomberos
36
3.3.2.3 CASOS DE USO – USUARIO
Tabla 8. Caso de Uso (Iniciar Sesión) app principal
ID: CU-01 Nombre: Iniciar Sesión
Autor Sergio Morales
Actor Usuario
Descripción Este caso de uso describe el comportamiento cuando un usuario desea iniciar sesión o registrarse.
Precondición Haber descargado la aplicación desde la Play Store.
Flujo de eventos
Pasos Acción
1 El usuario al iniciar la aplicación por primera vez se le muestra el botón de logueo.
2 Al presionar el botón de inicio de sesión se le abrirá un popUp de correos.
3 El usuario selecciona el correo con el cual desea iniciar.
4 Si todo el correo es válido, se inicia sesión y el usuario es redireccionado al home.
Excepciones Si el usuario cierra el popUp por error, o no selecciona un correo, se le mostrara una acción que indique esto.
Tabla 9. Caso de Uso (Iniciar Alerta) app principal
ID: CU-02 Nombre: Iniciar Alerta
Autor Sergio Morales
Actor Usuario
Descripción En este caso de uso es donde el usuario inicia los pasos para mandar la alerta
Precondición Estas Logueado en la aplicación y haber dado los permisos de las APIS usadas.
Flujo de eventos
Pasos Acción
1 Se le pide a usuario que active su GPS para obtener la mejor ubicación posible.
2 El usuario debe dejar presiona un widget que se encuentra en la pantalla, el tiempo será estipulado por los desarrolladores.
3 Si el usuario no completa la acción anterior, la animación de carga, la cual refleja el tiempo trascurrido, se reiniciará.
37
4 Si el usuario completa la carga de la animación anterior, será redireccionado a tomar la foto.
Excepciones
Si hay una alerta en curso, no se mostrara el widget para realizar la animación, en cambio, se le mostrara un mensaje de dicha situación y un botón de "Actualizar" para verificar si la alerta en curso fue resuelta.
Tabla 10. Caso de Uso (Obtener Ubicación) app principal
ID: CU-03 Nombre: Obtener Ubicación
Autor Luis Ángel Moreno
Actor Sistema
Descripción En este caso de uso el sistema se comporta tal y como se describe a continuación
Precondición Estas Logueado en la aplicación
Flujo de eventos
Pasos Acción
1 Al entrar en el home, se le pide al usuario activar el GPS, y si este es activado se captura su posición geográfica.
2 La ubicación geográfica obtenida en el paso anterior es guardada en el estado (basado en la arquitectura)
3 Los datos de ubicación estarán disponibles en todas las pantallas a través de esa instancia de sesión.
4 Las acciones anteriores se repiten si un usuario no activa su GPS, y se ejecuta la animación del caso de uso CA-02.
Tabla 11. Caso de Uso (Capturar Incidente) app principal
ID: CU-04 Nombre: Capturar Incidente
Autor Luis Ángel Moreno
Actor Usuario
Descripción En este caso de uso el sistema se comporta tal y como se describe a continuación cuando el usuario captura la imagen del incidente.
Precondición Haber ejecutado el CA-03
Flujo de Pasos Acción
38
eventos
1 El usuario se encuentra en la pantalla de tomar foto y se le muestra la vista previa de lo que captura la imagen y un botón de capturar foto.
2 El usuario captura la foto y esta es guardada en la memoria cache del dispositivo, además se guarda la ruta de la foto en el estado de la aplicación.
3 El usuario es redireccionado a una vista que le muestra la imagen tomada.
4 Se le muestra un botón flotante en el que acepta esa foto que ha tomado, si lo presiona es redireccionado a la siguiente pantalla.
Excepciones Al usuario se le da la opción de volver a tomar la foto, por lo cual se ejecutan los pasos nuevamente.
Tabla 12. Caso de Uso (Seleccionar Categoría) app principal
ID: CU-05 Nombre: Seleccionar Categoría
Autor Luis Ángel Moreno
Actor Usuario
Descripción En este caso de uso el sistema se comporta tal y como se describe a continuación cuando el usuario selecciona la categoría del incidente.
Precondición Haber ejecutado el CA-04
Flujo de eventos
Pasos Acción
1 Al entrar en esta página, se le muestra al usuario las diferentes categorías.
2 El usuario selecciona la categoría.
3 El sistema muestra un popUp con la información de la alerta, el usuario puede cerrar este y seleccionar otra categoría.
4 Luego entra en juego en caso de uso CA-06
39
Tabla 13. Caso de Uso (Enviar Alerta) app principal
ID: CU-06 Nombre: Enviar Alerta
Autor Sergio Morales
Actor Usuario y Sistema
Descripción EL usuario interactúa con el sistema y este le responde según los pasos a continuación.
Precondición Haber ejecutado el CA-05
Flujo de eventos
Pasos Acción
1 El sistema muestra un botón de "Alertar"
2 El usuario presiona el botón de alertar, entonces el sistema sube los datos de la alerta a la base de datos
3 Una vez los datos son guardados, se envía la push notification a la aplicación de bomberos.
4 El usuario es redireccionado a la pantalla de espera por una respuesta.
3.3.2.4 CASOS DE USO – BOMBEROS
Tabla 14. Caso de Uso (Recibir Alerta) app bomberos
ID: CU-01 Nombre: Recibir Alerta
Autor Sergio Morales
Actor Bomberos
Descripción El sistema se comportará tal y como se describe a continuación.
Precondición Ninguna
Flujo de eventos
Pasos Acción
1 La notificación cae en el dispositivo móvil de los bomberos.
2 La notificación es abierta haciendo tap en ella.
3 El sistema redirecciona hacia la pantalla de carga de alertas.
4 El sistema muestra el texto correspondiente al incidente, y empieza a mostrar la carga de la imagen.
5 Una vez carga la imagen, el usuario puede hacer zoom en ella y rotarla, a su conveniencia.
40
Tabla 15. Casos de Uso (Aceptar Alerta) app bomberos
ID: CU-02 Nombre: Aceptar Alerta
Autor Luis Ángel Moreno
Actor Bomberos
Descripción En este caso de uso se describe el comportamiento del sistema cuando se acepta una alerta.
Precondición Haber ejecutado el CA-01.
Flujo de eventos
Pasos Acción
1 El sistema muestra 2 opciones, entre las cuales está la descrita en este caso de uso.
2 Los bomberos dan tap en aceptar la alerta.
3 El sistema actualiza su estado en la base de datos, para que otro usuario no pueda mandar una alerta hasta que la actual sea resuelta.
Tabla 16. Caso de Uso (Rechazar Alerta) app bomberos
ID: CU-03 Nombre: Rechazar Alerta
Autor Luis Ángel Moreno
Actor Bomberos
Descripción En este caso de uso se describe el comportamiento del sistema cuando se rechaza una alerta.
Precondición Haber ejecutado el CA-01.
Flujo de eventos
Pasos Acción
1 El sistema muestra 2 opciones, entre las cuales está la descrita en este caso de uso.
2 Los bomberos dan tap en rechazar la alerta.
3 El sistema muestra un "widget de alerta" que pregunta si está seguro de realizar esa acción, "SI" o "No".
4 Si la opción es "SI" se actualiza dicho valor en la base de datos y son redireccionados al home.
5 Si la opción es "No" se oculta el widget de alerta y pueden continuar.
Tabla 17. Caso de Uso (Abrir Google Maps) app bomberos
41
ID: CU-04 Nombre: Abrir Google Maps
Autor Sergio Morales
Actor Bomberos
Descripción En este caso de uso se describe el comportamiento del sistema cuando se requiere abrir Google maps.
Precondición Haber cargado los datos de la alerta.
Flujo de eventos
Pasos Acción
1 El usuario da tap en "abrir en maps"
2 El sistema pone en pila la página de google maps, que muestra el punto de la alerta, y su punto actual.
3 Si el bombero de tap en el punto de la alerta, puede abrir en la aplicación nativa de google maps la ruta óptima para llegar a ese lugar y la distancia.
4 El bombero puede regresar a la vista anterior, ya sea para aceptar o rechazar la alerta.
42
3.3.2.5 DIAGRAMAS DE SECUENCIAS
Figura 11. Diagrama de Secuencia de Envío de Alerta
Figura 12. Diagrama de Secuencia Login (app principal)
43
3.3.2.6 DIAGRAMA DE COMPONENTES
Figura 13. Diagrama de Componentes
3.4 DESARROLLO DEL APLICATIVO
Todo desarrollo se compone de una serie de pasos en pro de conseguir un producto final,
en nuestro caso, quisimos enfocarnos en desarrollar las aplicaciones de la manera más
segura y factible que se pudiera. El modelo de Cliente – Servidor que ha sido usado por
muchos años es algo que está cambiando; no se quisimos malgastar tiempo en ello, ya
que existen servicios especializados que lo hacen de maravilla.
Hoy los microservicios son una gran ayuda y ventaja en la hora del desarrollo, ya que los
desarrolladores solo nos enfocamos en el producto, y no tanto en lo que está por detrás,
es decir, servidores, sistema operativo, capa de seguridad, etc.
Se decidió usar Firebase como backend de la aplicación. Firebase en palabras sencillas
es un backend como servicio, nos ofrece todo eso que es común en aplicaciones, por
ejemplo, autenticación, almacenamiento de archivos, base de datos, y muchos más
servicios. Lo mejor de todo es que es usado y mantenido por Google y, si eres una
persona que usa un dispositivo Android con seguridad estas usando firebase.
Debajo tendrás una imagen con sus principales servicios.
44
Figura 14. Servicios de Firebase
Fuente: firebase.google.com/
3.4.1 TECNOLOGÍAS UTILIZADAS
Ahora se mencionan todas las tecnologías utilizadas, de dónde las obtuvimos, cómo las
usamos y por qué.
3.4.1.1 Flutter SDK
Flutter es un framework de código abierto desarrollado por Google para crear
aplicaciones nativas de forma fácil, rápida y sencilla. Su principal ventaja radica en que
genera código 100% nativo para cada plataforma, con lo que el rendimiento y la UX es
totalmente idéntico a las aplicaciones nativas tradicionales.
Las principales funcionalidades de flutter son:
• Calidad nativa: Las aplicaciones nativas se desarrollan específicamente para un
sistema operativo, Flutter utiliza todas las ventajas de las aplicaciones nativas
para conseguir calidad en el resultado final. Flutter está escrito en Dart, un
lenguaje de Programación creado por Google, en el cual, nuestras aplicaciones
escritas con Dart y flutter serán compiladas a código máquina, armeabi-v7a
(ARM 32-bit), arm64-v8a (ARM 64-bit), y x86-64 (x86 64-bit).
45
• Experiencia de usuario: Flutter incluye Material Design de Google y Cupertino
de Apple, con lo que la experiencia de usuario es óptima y las interfaces de
usuario idénticos a los de las aplicaciones desarrolladas por las propias
compañías.
• Tiempo de carga: Una de las principales causas de abandono de una aplicación
es el tiempo que tarda en cargar, con Flutter se experimentan tiempos de carga
bajos en cualquiera de los soportes iOS o Android.
• Desarrollo ágil y rápido: Gracias a la característica hot-reload, podemos
programar y ver los cambios en tiempo real en nuestro dispositivo o en
simuladores.
En flutter todo, literalmente TODO es un widget y, estos widgets pueden ser de 2 tipos,
aquellos que tienen estados, y aquellos que no.
Figura 15. Stateless and Stateful widgets in flutter
Fuente: flutter.dev
Los widgets en sí mismos están compuestos de muchos widgets pequeños de un solo
propósito que se combinan para producir efectos potentes. Por ejemplo, Container, un
widget de uso común, está compuesto por varios widgets responsables del diseño,
painting, positioning, and sizing. Específicamente, el Container está compuesto por
widgets LimitedBox, ConstrainedBox, Align, Padding, DecoratedBox y Transform. En
lugar de subclasificar el Contenedor para producir un efecto personalizado, podemos
componer estos y otros widgets simples de formas novedosas.
46
Figura 16. Widget Básico en flutter
Fuente: Autores
Para empezar a desarrollar con flutter necesitamos tener los siguiente:
✓ JAVA JDK: Como estamos ejecutando una aplicación Android, necesitamos el
kit de desarrollo de java, esto es algo común en todo desarrollo Android, sin
importa el framework.
✓ ANDROID SDK: El cual contiene todo el kit de desarrollo para trabajar con
Aplicaciones Android. Este requiere del jdk de java.
✓ Flutter SDK: La parte más importante, el sdk de flutter que puede ser
descargado desde su página oficial, el cual contiene todo lo necesario para
trabajar aplicaciones escritas con este framework.
✓ Dispositivo con Android: Ya sea un celular o un emulador para poder correr
nuestras aplicaciones.
✓ IDE: Un IDE es un entorno de desarrollo integrado, podemos usar Android
Studio o Visual Studio Code, ya que estas poseen herramientas de depuración
que son extremadamente útiles a la hora de desarrollar e ir probando.
La guía de pasos para su instalación está disponible en https://flutter.dev/docs/get-
started/install.
47
3.4.1.2 Firebase
Como se ha dicho anteriormente, usamos firebase como backend. Para utilizarlo solo
basta con tener un correo de Google, además entre sus planes, ofrece uno gratuito que
nos vale en nuestro caso para desarrollar nuestro prototipo funcional.
Las siguientes figuras son capturas tomadas desde la misma consola.
Para empezar nos vamos a la consola de firebase en console.firebase.com.
Podemos iniciar creando un proyecto en el botón que lo indica.
Figura 17. Crear un proyecto en firebase
El siguiente paso es darle el nombre al proyecto, en este caso le daremos: falerapp
Figura 18. Paso 1, dar nombre al proyecto en firebase
Damos en “continuar”, y en el paso 2 nos preguntara si queremos usar Google Analytics,
el cual dejaremos habilitado
48
Figura 19. Paso 2, habilitar Google Analytics.
Luego seleccionamos la cuenta usar, que en este caso será la por defecto, y creamos el
proyecto
Figura 20. Paso 3, elegir la cuenta de firebase
Al darle en crear proyecto nos mostrara una animación de carga que nos indica que se
está realizando cierta acción en sus servidores, tendremos que esperar unos segundos.
49
Figura 21. Feedback Creando el proyecto de Firebase
Figura 22. Feedback, proyecto de firebase creado
Con estos pasos estamos casi listos para empezar una aplicación en la cual nuestros
usuarios podrán iniciar sesión, registrarse, guardar datos, archivos, etc.
De manera que, en nuestro proyecto el inicio de sesión es a través de Google, por ello
activamos dicha opción en la consola de firebase, como se muestra en la siguiente
imagen.
50
Figura 23. Activando Google Auth en la consola de firebase.
En este paso no se necesita hacer nada extra, es solo activar la opción; la consola de
firebase te va guiando a través de cada paso, así que no hay que preocuparse si nunca se
ha usado firebase anteriormente.
Ahora habilitaremos la base de datos, para ello en el panel de “Desarrollo” nos dirigimos
a “Database” y damos en “Crear base de datos”
Figura 24. Creando base de datos en firebase.
51
Por último, el servicio que hace falta es el de Storage, que corresponde al
almacenamiento de archivos, como imágenes.
Para ello en el panel de Desarrollo, seleccionamos “Storage” seguido de “Empezar”
Figura 25. Habilitando Storage en Firebase.
¡Listo!, con esto estamos preparados para crear aplicaciones con un servidor como
servicio.
3.4.1.3 Google maps
Usamos Google maps para poder ofrecer la ubicación exacta del incidente que se esté
reportando en la aplicación principal.
Para poder usar Google maps en nuestros proyectos, independientemente de la
plataforma en que corra, necesitamos una API KEY, es decir, una clave de acceso única,
la cual podemos conseguir si disponemos de una tarjeta que podamos asociar en la
consola de Google, pero no es porque se tratase de un pago, podemos usar Google maps
en dispositivos móviles de manera gratuita, solo que muchos otros servicios dentro de
Google Cloud son de pago.
Por seguridad y disponibilidad no se mostrará como configurar Google maps, ya que se
requiere tarjeta y una serie de pasos que pueden ser tediosos y largos.
A continuación, vemos el consumo que las aplicaciones llevan hasta el momento
52
Figura 26. Consumo de Servicios de Google de Nuestras aplicaciones
Consumos de los cuales podemos ver que “Cloud Messaging” posea la mayor cantidad;
este servicio es el de push notifications, en el cual mandamos la alerta desde la
aplicación del usuario hacia la de bomberos
3.4.1.4 Agora.io
Esta herramienta corresponde al SDK de agora, el cual se usa para hacer las video
llamadas. Lo que nos ofrece es su sistema de llamadas a través de internet, de manera
segura y encriptada.
Agora posee un panel de administración en el cual podemos crear y administrar nuestros
proyectos, los cuales nos darán un API KEY, así como Google maps, con el cual
podemos usar sus servicios.
Agora no es del todo gratuito, aunque si deja utilizar sus servicios bajo cuotas limitadas
en desarrollo. A continuación, veremos los precios que ellos ofrecen.
Figura 27. Precios de agora.io
Fuente: https://www.agora.io/en/pricing/
Agora está disponible para todas las plataformas, web, móvil y desktop.
53
3.4.2 LENGUAJE / LIBRERÍAS / PAQUETES
En este ítem se muestran y describen los framework de Android y flutter utilizados para
el desarrollo de las aplicaciones.
3.4.2.1 Dart
Dart es un lenguaje de programación de código abierto, desarrollado por Google y
liberado al mundo en 2011, se describe a sí mismo como un lenguaje optimizado para el
lado del cliente para el desarrollo de aplicaciones de cualquier plataforma de manera
rápida.
A continuación, una lista rápida de las características de Dart que juntas lo hacen
indispensable para Flutter:
• Dart es AOT (Ahead Of Time) compilado en código nativo rápido y predecible,
lo que permite que casi todo Flutter sea escrito en Dart. Esto no sólo hace que
Flutter sea rápido, sino que prácticamente todo (incluidos todos los widgets) se
puede personalizar.
Figura 28. Dart to native – AOT
Fuente: (dart.dev, 2020)
• Dart también puede ser compilado JIT (Just In Time) para ciclos de desarrollo
excepcionalmente rápidos y un flujo de trabajo que cambia el juego (incluyendo
la popular sub-segunda Stateful Hot Reload — recarga rápida con manejo de
estado).
54
Figura 29. Stateful Hot Reload in Flutter with Dart
Fuente: dart.dev
• Dart facilita la creación de animaciones y transiciones suaves que se ejecutan a
60fps. Dart puede hacer object allocation y garbage collection sin bloqueos. Y, al
igual que JavaScript, Dart evita la programación anticipada y la memoria
compartida (y, por lo tanto, los bloqueos). Debido a que las aplicaciones Flutter
están compiladas en código nativo, no requieren un puente lento entre dominios
(por ejemplo, JavaScript a nativo). También arrancan mucho más rápido.
Figura 30. UIs in Flutter with Dart
Fuente: dart.dev
55
• Dart permite que Flutter evite la necesidad de un lenguaje de diseño declarativo
separado como JSX o XML, o constructores de interfaces visuales separados,
porque el diseño declarativo y programático de Dart es fácil de leer y visualizar.
Y con todo el diseño en un solo lenguaje y en un solo lugar, es fácil para Flutter
proporcionar herramientas avanzadas que hacen que el diseño sea fácil.
Podemos ver el famoso “Hola Mundo” escrito en Dart en la siguiente imagen.
Figura 31. Hola mundo en Dart
Fuente: dart.dev
3.4.2.2 PUB.DEV
Pub es el repositorio de paquetes para Dart y Flutter que se encuentra en su sitio web
pub.dev. Estos paquetes pueden ser instalados a través de las herramientas de comando
que ofrecen tanto Dart como Flutter, por ejemplo, para instalar el paquete de la Cámara
o el Location.
Tanto Flutter como Dart, usan un sistema de control de paquetes, el cual consiste de un
archivo “pubspec.yaml” en la siguiente imagen se muestra una pequeña parte del
paquete de dependencias de la aplicación principal de los usuarios.
56
Figura 32. Ejemplo Dependencias de la aplicación principal
Fuente: Autores
En el archivo pubspec podemos ver como se muestra en la figura 32, el apartado para
“dependencies” en el que están las dependencias del proyecto, dichas dependencias son
tomadas del repositorio en línea pub.dev.
Figura 33. Home Page del repositorio de paquetes de Dart y Flutter
Fuente: pub.dev
A continuación, la lista completa de dependencias utilizadas
57
Tabla 18. Lista de paquetes usados
NOMBRE DEL PAQUETE Versión
location ^3.0.2
firebase_auth ^0.16.0
firebase_core ^0.4.4+3
cloud_firestore ^0.13.5
firebase_storage ^3.1.5
firebase_messaging ^6.0.13
google_sign_in ^4.4.4
permission_handler ^5.0.0+hotfix.3
google_fonts ^1.0.0
provider ^4.0.5
bloc ^4.0.0
flutter_bloc ^4.0.0
equatable ^1.1.1
meta ^1.1.8
camera ^0.5.7+4
path_provider ^1.6.7
flutter_image_compress ^0.6.7
http ^0.12.1
shared_preferences ^0.5.7
agora_rtc_engine ^1.0.10
url_launcher ^5.4.5
google_maps_flutter 0.5.27+3
maps_launcher ^1.2.0
flutter_ringtone_player ^2.0.0
vibration ^1.2.4
3.4.3 ARQUITECTURA DE ESTADOS
En este ítem se describe como se maneja la arquitectura de la aplicación, y como se
integran los paquetes para que todo funcione de acuerdo a los requerimientos.
Por arquitectura no nos referimos a la de componentes, si no, aquella que se usa para
manejar los estados de los atributos que componen por ejemplo a la alerta, que
principalmente son la ubicación, la foto y categoría.
3.4.3.1 Bloc y Provider
Estos 2 paquetes son los encargados de manejar los estados, eventos y transiciones de
nuestras aplicaciones.
58
Bloc (Business Logic Component) en sus siglas en inglés, hace referencia a la lógica de
negocio de nuestros componentes; este patrón de diseño nos ayuda a separar la capa de
presentación, que corresponde a lo que el usuario ve y flutter pinta, de la capa lógica que
se encarga, por ejemplo, de hacer una petición http, obtener la ubicación, etc.
Bloc maneja un glosario de 3 conceptos:
Events: Corresponde a los eventos dentro de nuestro bloc y son la entrada de este. Son
comúnmente eventos de la UI, como presionar un botón. Estos eventos son añadidos al
Bloc para luego ser mapeados a Estados.
States: Corresponde a los estados dentro del bloc y, son las salidas de estos. Podemos
tener en nuestra capa de presentación, lo que se llaman Observadores, los cuales están
escuchando ante cambios de estados para actualizar las porciones de nuestra UI que
necesiten ser actualizadas.
Transitions: Corresponde a las transiciones. El cambio de un estado a otro se le llama
Transición, Las transiciones constan de un estado actual, un evento y el siguiente estado.
Figura 34. Bloc Architecture
Fuente: bloclibrary.dev
Provider es una librería para manejar Herencia entre widgets de manera más fácil, Bloc
usa Provider para manejar los estados. Provider nos permite exponer valores, crearlos,
escucharlos, entre otras acciones, todo esto para mantener un control del valor de
59
nuestros estados a través de múltiples widget y pantallas, lo que se conoce el flutter
como el árbol de widgets.
Si te cuesta trabajo entender esto, imagínate ahora a nosotros tratando de explicarlo.
Todo esto requiere estudio y práctica.
Figura 35. Obtener Ubicación _ Bloc
Fuente: Autores
60
Figura 36. Capturar Imagen _ Bloc
Fuente: Autores
61
Figura 37. Seleccionar Categoría _ Bloc
Fuente: Autores
Una vez tomado los 3 datos imprescindibles, se puede mandar la alerta, para ello
directamente se accede a los datos del bloc para ser almacenados en la base de datos y,
al mandar la push notifications a los bomberos, lo que viajaría es la referencia o ID de la
alerta en la base de datos.
62
4. RESULTADOS Y DISCUSIONES
4.1 PRUEBAS DE FUNCIONAMIENTO / MANUAL DE USUARIO
Como se describió en el ítem 3.4.3 sobre la Arquitectura de Estados, se usó Bloc y
Provider, a continuación, se evidencia como se iba actualizando los estados a través de
las pantallas.
4.1.1 Flujo a través de la aplicación y estados de bloc.
Figura 38. Primer Inicio de la Aplicación Principal
63
Figura 39. Inicio de Sesión Aplicación Principal
Figura 40. Ingreso de Código de Acceso, Aplicación Principal
64
Figura 41. Home Page - Activar GPS en Aplicación Principal
Figura 42. Activación de snackBar al obtener Ubicación
65
Figura 43. Feedback de la Animación en Home Page, Aplicación Principal
Figura 44. Acción de tomar imagen en Aplicación Principal
66
Figura 45. Página de Confirmar foto tomada, Aplicación Principal
Figura 46. Feedback subiendo Imagen a la nube, Aplicación Principal
67
Figura 47. Seleccionando la Categoría, Aplicación Principal
Figura 48. Componente de Alertar, Aplicación Principal
68
Figura 49. Página de Espera al enviar alerta, Aplicación Principal
Las anteriores figuras mostraron la interacción del usuario. Ahora, cuando la alerta es
enviada a los bomberos estos la reciben en su aplicación.
La Alerta anterior enviada se vería en la aplicación de los bomberos de la siguiente
forma. Ten presente la foto que se tomó desde la cámara.
69
Figura 50. Alerta Recibida, Aplicación de Bomberos
70
Figura 51. Aceptar o Rechazar Alerta, Aplicación de Bomberos
71
Figura 52. Alerta Aceptada, Aplicación Principal
72
Figura 53. Page de video llamada
73
Figura 54. Vista de llamada entre 2 personas
Figura 55. Alerta Atendida, feedback
74
Figura 56. Home Page App Bomberos
Figura 57. Widget de Llamada entrante
75
5. CONCLUSIONES
A través de la realización de este proyecto se pudo evidenciar la falta de la inclusión
tecnológica en ámbitos de la seguridad, ya que son pocos los proyectos que comunican
de manera directa a la ciudadanía con entes de primeros auxilios.
Como se evidenció en el estado del arte, las principales aplicaciones respecto a sistemas
de alertas bomberiles están enfocadas exclusivamente para cuerpos de bomberos,
dejando de lado a la ciudadanía con el único recurso de poder realizar una llamada
telefónica para alertar un incidente. Dichas llamadas pueden ser falsas alarmas o bromas,
ya que no se puede determinar el valor de verdad de estas.
El desarrollo del proyecto nos permitió analizar de qué manera se podía mejorar la
comunicación entre una determinada población y un cuerpo de primeros auxilios. Para
ello se recurrió al uso de tecnologías de geoposicionamiento, imágenes y comunicación
en tiempo real.
El sistema de aplicaciones desarrollado puede ser controlado y regulado bajo reglas que
permitan mayor seguridad, ya que, como es requerido una cuenta de Usuario, en caso de
quebrantar las reglas se podrá bloquear en el sistema.
Se puede decir que una persona que se encuentre en una situación de peligro puede
llamar por vía telefónica como normalmente se hace a la estación de bomberos y pedir
asistencia, a la vez que puede dar, a través de la aplicación de los usuarios, los datos de
su ubicación y una foto del lugar; esto daría a los bomberos una ruta óptima para llegar
al lugar y poder dar asistencia mientras se desplazan al lugar.
Se probó el tiempo mínimo que una persona se demoraría dando los datos necesarios en
la aplicación, el cual depende de la condición de red y del dispositivo, dando como
resultado 20 segundos.
76
6. RECOMENDACIONES
En el desarrollo del proyecto se definieron funcionalidades y requisitos que debía
cumplir el sistema. Lo primordial se definió en principio como ubicación y foto del
incidente, luego se agregó el parámetro de la categoría en que se puede clasificar.
A medida que se iba diseñando y desarrollando el sistema de aplicaciones se pensaron
en más funcionalidades que podían enriquecer la comunicación entre los entes, así fue
como se agregaron las video llamadas. Además, se definió que el proceso de alertar
debía ser rápido dentro de la aplicación, por ello no debía haber campos de textos en
ella, ya que esto requeriría más tiempo en completar la alerta.
Así que quedaron futuras mejoras al proyecto, funcionalidades para mejorar en las
aplicaciones:
✓ En los casos en que un usuario no sepa en que categoría cae el incidente en que
se encuentra, se tiene la opción de escoger la opción “Otro”, la cual dice poco o
nada si es que la imagen no refleja lo que sucede. En este caso sería conveniente
que el usuario grabe una nota de voz de no más de 10 segundos diciendo la
situación en que se encuentra, y esta sea mandada junto con los demás datos.
✓ En ambas aplicaciones se da la opción de hacer una videollamada, es decir, audio
y video, pero, no se da la opción de solo hacer una llamada VoIP. Es algo que
quedaría para mejorar.
✓ Las alertas son almacenadas en una base de datos, pero, después de eso no se está
haciendo algo con esta información; por ello, se podría usar la información para
genera modelos de datos que relacionen un determinado espacio con la cantidad
de alarmas creadas, además se podrían generar reportes semanales o mensuales
de las alertas, esto se le conoce como tratamiento de los datos.
✓ Ya que las alertas poseen una fecha en que se crean, dicha fecha contiene el
instante exacto cuando se mandan, se puede determinar la efectividad en la
reacción del cuerpo de bomberos.
77
7. BIBLIOGRAFÍA.
COMUNICACIONES DNBC. (2019). Eventos Atendidos por Bomberos Colombia.
DNBC Sitio web: https://bomberos.mininterior.gov.co/sala-de-
prensa/noticias/eventos-atendidos-por-bomberos-colombia [ octubre 2019]
Redacción de El País. (noviembre 05, 2016 - 12:00 a. m). 80 % de llamadas al 123 son
falsa alarma o bromas. El País Sitio web: https://www.elpais.com.co/cali/80-de-
llamadas-al-123-son-falsa-alarma-o-bromas.html [ octubre 2019]
José Luis Pineda. (miércoles 27 de marzo de 2019 - 12:00 a. m). Cada cinco minutos
Bomberos Bucaramanga reciben una llamada falsa. Vanguardia Sitio web:
https://www.vanguardia.com/area-metropolitana/bucaramanga/cada-cinco-
minutos-bomberos-bucaramanga-reciben-una-llamada-falsa-DE699050 [ octubre
2019]
EL CONGRESO DE COLOMBIA. (agosto 22 de 2012). LEY 1575 DE 2012 Por medio
de la cual se establece la Ley General de Bomberos de Colombia. Función
Pública, Sitio web:
https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=48943 [
noviembre 2019]
CONFEDERACIÓN NACIONAL DE CUERPOS DE BOMBEROS DE COLOMBIA.
(Bogotá, D. C., miércoles, 27 de agosto de 2014). RESOLUCIÓN NÚMERO
0661 DE 2014 por la cual se adopta el Reglamento Administrativo, Operativo,
Técnico y Académico de los Bomberos de Colombia. Recuperado de
https://www.cfnbcolombia.com/pdf/DN/DiariOficial/Res-
661%20de%202014%20DIARIO%20OFICIAL.pdf [mayo 2020]
Primer Alerta. (2019). APP EXCLUSIVA DE ALERTAS: Conecta tu Cuartel de
Bomberos con cada uno de sus miembros, de Primer Alerta Sitio web:
https://primeralerta.com/index.php [octubre 2019]
Firma Deloitte. (2019). Consumo móvil en Colombia 2019 Sitio Web:
https://www2.deloitte.com/co/es/pages/technology-media-and-
78
telecommunications/articles/consumo-movil-en-colombia-2019.html [diciembre
2019]
Bomberos Ya. (2019). Envía y recibe alertas en Tiempo Real de forma rápida y segura,
para estar conectados las 24 horas entre cuarteles, bomberos y guardias. Sitio
Web: https://bomberosya.com/ [octubre 2019]
Dart Platform. (2020). Lenguaje de programación creado por Google. Sitio Web:
https://dart.dev/ [enero 2020]
Firebase por plataforma. (2020). Firebase te da las herramientas para programar apps de
alta calidad. Recuperado de: https://firebase.google.com/docs [enero 2020]
Flutter by Google. (2020). Flutter SDK para construir aplicaciones de alto rendimiento,
alta fidelidad para iOS, Android, Web(beta) y Escritorio (technical preview)
desde un solo código base. Recuperado de:
https://flutter.dev/docs/resources/technical-overview [enero 2020]
Cesar Vega. (Mar 4, 2019). ¿Por qué Flutter usa Dart?, de Medium Sitio web:
https://medium.com/comunidad-flutter/por-qu%C3%A9-flutter-usa-dart-
8e7703650def [mayo 2020]
Guru patel. (Apr 5, 2020). Can it be done in Flutter? de Medium Sitio web:
https://medium.com/@gurupatel107/can-it-be-done-in-flutter-2e5a8fe966f8
[mayo 2020]
Vladimir Babenko. (Mar 15, 2019). Flutter App Lifecycle. de Medium Sitio web:
https://medium.com/pharos-production/flutter-app-lifecycle-4b0ab4a4211a
[mayo 2020]
Developers Google. (Last updated 2020-05-01). Obtén una clave de API para Google
Maps. de Developers Google Sitio web:
https://developers.google.com/maps/documentation/android-sdk/get-api-key
[mayo 2020]
79
Written by Lasse Nielsen. (April 2013 (updated October 2018)). Creating streams in
Dart, de dart.dev Sitio web: https://dart.dev/articles/libraries/creating-streams
[mayo 2020]
Fernando Herrera. (abril 2020). Flutter: Diseños nivel profesionales y animaciones, de
Udemy Sitio web: https://www.udemy.com/course/flutter-disenos-y-
animaciones/ [abril 2020]
80
ANEXOS
Anexo 1. Aplicaciones instaladas en dispositivo real
Anexo 2. Aplicación principal en la Play Store
81
Anexo 3. Mock-Up de las Aplicaciones en Adobe XD
Anexo 4. Colores Usados en las Aplicaciones
Fuente: Autores
82
Anexo 5. Fuente tipográfica usada.
Fuente: Google Fonts.
Anexo 6. Alertas en la base de datos Firestore
Fuente: (Consola de Firebase)