Aplicación móvil en Flutter y Express Js para Visualizar Horarios de Corte de Luz en Ecuador
Corría el mes de octubre de 2023 y se anunciaba en Ecuador el racionamiento de energía eléctrica en Ecuador, la razón se atribuye a la severa sequía que se registra en la zona austral, donde se ubican tres hidroeléctricas: Paute, la segunda más grande del país; Mazar; y Sopladora. Bajo dicho contexto, uno de los desafíos de aquellos días era mantener comunicada a las personas sobre los horarios en los que se iba a realizar el corte por sector.
La estrategia que se tomó para dicho proceso fue el de compartir un archivo PDFs para que los ciudadanos busquen su sector y verifiquen allí la información requerida; esto era importante para alcanzar a apagar los electrodomésticos y artículos tecnológicos a tiempo y prevenir problemas en su funcionamiento. En consecuencia, me encontraba buscando mi barrio un 26 de octubre a las 11 pm de la noche para indicarle a mi familia a que hora apagar los equipos, les adelanto lo siguiente: “me demoré 10 min” y al siguiente día escuché a las personas en el trayecto a mi trabajo, en uno de los autobuses que utilizo para desplazarme, conversar que les tomó más de 1 hora y otros ni lo encontraron.
El hecho anterior me dejó impactado y me encontraba cavilando inopinadamente… Nah no se crean, pero sí me entró una idea: “Qué podríamos hacer para facilitarle la vida a las personas” y di con el hecho de organizar la información de los PDFs en una sola App en donde solo se tendría que registrar tu sector para luego consultarlo y así, la próxima vez entrarías y verías a que hora tendrías que apagar tu electrodoméstico y fue ahí donde sentí como tenía una buena idea entre mis manos, al menos inicialmente pero necesitaba ayuda.
El pana Jhon Huiracocha
Una vez terminado mi recorrido del bus, llamé a mi amigo Jhon Jairo Huiracocha Carrillo, porque sabía que le iba a gustar la idea… Lo llamé y me dijo: “tas loco” y con eso supe que estaba dentro del proyecto, le comenté todo y lo que tenía avanzado, a lo que él respondió “tas loco x2” porque todo lo avanzado eran las ideas y las cosas por definir, pero finalmente estábamos decididos a llevar a cabo el proyecto.
La aplicación HorarioCorteLuz proporciona información en tiempo real sobre los cortes de luz en nuestros sectores específicos. A diferencia de depender de archivos PDF estáticos publicados en redes sociales, la aplicación actualiza automáticamente la información, brindándonos detalles precisos y oportunos sobre cualquier cambio en los horarios de cortes de luz.
Al registrar nuestros sectores en la aplicación, obtenemos información personalizada no solo del lugar donde vivimos si no también del lugar donde está nuestra pareja, familiares o personas conocidas en las que sabemos que tal vez, no tengan internet por wifi y solo podremos comunicarnos con ellos por llamada celular.
Algo muy importante que debo indicar es que analizamos la posibilidad de utilizar una aplicación web por la rapidez y de no depender de una tienda de aplicaciones como Google Play para ser publicada, pero la descartamos, pese a sus ventajas, por el hecho que con ello ganamos visibilidad, acceso directo desde la pantalla de inicio, menos pasos para llegar a nuestro sistema.
Tecnologías usadas:
App móvil de Android (Flutter)
Decidimos utilizar Flutter como nuestra tecnología de la parte móvil ya que hay mucha documentación sobre las herramientas y librerías que contiene, además nos gustó mucho el hot reload (https://docs.flutter.dev/tools/hot-reload) que nos permitía hacer cambios y verlos reflejado al instante en nuestro producto y ni hablar de su curva de aprendizaje.
Como nota adicional, realizamos nuestro comparativo entre velocidades de las alternativas existentes en el mercado como IONIC, React Native, Java, Kottlin y aunque estos dos últimos siempre van a ser mejores en cuanto al rendimiento, Flutter nos sorprendió porque no se alejaba mucho del rendimiento que estos ofrecían porque al fin y al cabo, se compila a código nativo y utiliza un motor de renderizado de alto rendimiento llamado Skia, que permite animaciones suaves y garantiza una excelente experiencia de usuario.
Escogimos Express.js porque se destaca por su sintaxis simple y elegante además de usar como lenguaje principal a Javascript. La creación de rutas y la manipulación de solicitudes y respuestas se simplifican significativamente, lo que facilita el desarrollo y mantenimiento del código. La estructura minimalista de Express Js permite construir aplicaciones robustas sin abrumar a los desarrolladores con una complejidad innecesaria.
Proporciona una base sólida para el desarrollo, simplifica el manejo de rutas, ofrece flexibilidad mediante middleware y se integra bien con otras herramientas como el ORM Prisma que nos ayudó a desarrollar de una manera más rápida al conectarnos con la base de datos de MySql. La combinación de estas características hace de Express una opción atractiva para construir aplicaciones web eficientes y escalables.
En el proyecto tuvimos dos grandes desafíos, por un lado el de organizar mucha información relevante sobre sectores y por otro referente a cuál sería nuestra característica diferenciadora.
Organizar mucha información relevante sobre sectores
Debíamos organizar mucha información relevante sobre sectores distribuidos en los documentos PDFs y nos hizo cuestionar mucho, varias ideas interesantes pasaron por nuestra mente que comenzamos a descartar:
A) Entrenar una IA para que recibiera la información de los sectores y los horarios de corte de luz.
B) Revisar pdf por pdf e ir colocando cada uno de los sectores disponibles en la base de datos.
C) Construir una api para solo copiar los sectores y la lista de horarios en los que se prevé el corte de luz.
D) Utilizar un utensilio interesante en mi época de automatizador QA y crear un web scraper que sacara información a todo momento de los pdfs que se publicarán en la red social X.
Teníamos varías opciones y debatimos mucho, dijimos que la opción de entrenar una IA era la mejor pero nos tomaría tiempo, cosa que no teníamos y por eso la descartamos. Luego analizamos cuál sería nuestro producto mínimo viabley nos dimos cuenta que para empezar a probar nuestra idea rápido sí o sí, debe existir nuestra intervención y por eso nos fuimos por la opción C.
Nuestra característica diferenciadora
Nuestra característica diferenciadora surgió de una pregunta muy curiosa, inicialmente solo íbamos a mostrarle a los usuarios sobre su sector pero mi amigo Jhon Huiracocha me dijo: “Y si quieres saber a qué hora se le va la luz a Helen” (Helen es mi novia), a lo que yo contesté: “Me creo otra cuenta xddd” y fue ahí que surgió la necesidad de no solo guardar un sector sino múltiples, en este momento ya pasó de ser individual a grupal y aún mejor, podríamos basarnos en esta idea de nuestros seres queridos para hacer marketing sobre ello.
Organización (Descripción cortesía Jhon Jairo)
Holaaa! soy Jhon Jairo Huiracocha, me he tomado este espacio para explicar cómo le hicimos para organizarnos y juntar todo al final y no morir en el intento:
Antes que nada, todo nuestro proyecto está en github para el control de versiones, realizar revisiones y aceptar cada uno de los cambios que íbamos haciendo; esto es así porque aunque nosotros nos dividimos el proyecto en 2 mundos (frontend y backend), siempre había comentarios que resultaban de “correr” localmente cada uno de estos proyecto, para muestra una captura de un cambio hecho
Haciendo cambios en el backend
Arquitectura de la aplicación
Como teníamos que realizar una conexión entre el API RESTful, ambos proyectos debían contar con buenas prácticas para que en un futuro si se debe realizar un mantenimiento, no perder noción de lo que se llevó a cabo con un código explicativo y organizado. Para muestra de ello, una pequeña descripción en la imagen que sigue a continuación sobre qué arquitectura tiene el backend para comunicarse con el frontend teniendo en cuenta lo que se mencionó.
Arquitectura de nuestra aplicación BackEnd - FrontEnd
Como se puede observar en la imagen anterior, el backend fue dividido de la siguiente forma:
A)Services: Es aquella lógica del negocio que se implementa dentro de nuestra aplicación, por ejemplo la lista de sectores validados por ciudad.
B)Controllers: Es la capa que expone nuestros endpoints al mundo y que podrá ser consumido por el FrontEnd.
C)Auth: Es nuestro componente que realiza validaciones de autenticación y registro del usuario.
D)DTOs: Este transporta datos entre procesos y lo usamos por ejemplo, para recibir los datos de MySql retorna al cliente el nombre de usuario y los sectores; esto es importante para no exponer a detalle los campos de nuestra base de datos por temas de seguridad.
E)Prima: ORM: Es nuestro ORM (Object Relational Mapping - Object Relational Mapping) y sirve para manejar la persistencia y consulta de datos a nuestra base de datos MySql.
F)Persistencia: (MySql): Es nuestro gestor de base de datos.
Para el lado de la aplicación en Flutter:
A)Core: Aquí colocamos constantes, códigos, mensajes o configuración que mostraremos en cualquier lado de la aplicación.
B)Architecture: Es la capa expuesta a los servicios externos por lo que, aquí conviven los datasources y repositorios.
C)Providers: Es la sección donde colocaremos todos nuestros gestores de estados, en el proyecto se usó para el tema (dark mode y light mode).
D)Domain: En este punto conviven todas nuestras clases abstractas que serán “plantillas” para toda la aplicación, así como los DTOs y los casos de uso.
E)Presentation: Aquí ocurre la magia de las pantallas, los Widgets de flutter, las secciones y componentes; tiene que ver 100% con el aspecto visual que tendremos.
Pueden observar que en ambos mundos (Backend y FrontEnd) al tener aspectos que los diferencian, siempre es bueno buscar una buena organización y separar responsabilidades en diferentes directorios para evitar problemas a futuro de malas prácticas. En este caso, la implementación se hizo adaptado para nuestro requisito específico del proyecto.
Inicio
Sectores
Conclusiones (Descripción Ambos)
El proyecto surgió como una solución para organizar la información disponible en algo más adecuado para el usuario que es afectado por los horarios programados de corte de luz, sin embargo con el paso de tiempo y a medida que íbamos avanzando con nuestro desarrollo nos dimos cuenta que el mayor riesgo que corríamos y que haría que nuestro trabajo sea abandonado era que dejasen de publicar nuestra materia prima (los PDFs), cosa que sucedió a finales de noviembre porque CNEL publicó un sitio web, que inclusoaconsejamos usar.
A pesar de los cambios en la fuente de datos y la falta de impacto social, perseveramos en el desarrollo, entregando un producto de calidad. La fascinación por la idea original nos llevó a completar el proyecto con código organizado y adquirir una cuenta de desarrollador para Google Play. Aunque carece de impacto social, estamos satisfechos y orgullosos con la finalización al 100% y la experiencia ganada.
