Linkeding @Stiven Morelos Barahona
Utilizando el patrón bloc para el planteamiento de la lógica de la aplicación, subdividiendo de responsabilidades y creando entidades abstractas que controlan las peticiones a través de consumo de servicios con inyectados por dependencias, mientras que clean architecture entre sus grandes bondades nos entrega una forma clara de organización de proyectos y refuerzos de principios SOLID, entre otros puntos, mejorando la legibilidad del proyecto mismo.
Para el control de la información y estados en la aplicación se emplea Cubit dado su gran manejo y adaptación a diferentes eventualidades, gracias si emisión de estados, basados en el principio de los Streams, para ciertos procesos se utilizó Provider, dado que el principio de responsabilidad única aplicado a este permite la accesibilidad estable y rápida en cualquier momento de la ejecución, sin crear otra entidad o romper el flujo de Stream.
Se utilizo la api ofrecida para el desarrollo de la prueba, viendo ciertas limitantes que se podrian crear a traves de la libreria que ofrecia la documentation decidi crear una capa de data propia para el manejo de esta, permitiendo crear UNIT TESTING sin tener una capa intermedia no creada por mi y sin control real de sus respuestas.
Las dependencias en este proyecto se manejan de la forma simple recomendada por el equipo desarrollador de Flutter, evitando usar librerías externas que proporcionen un nivel más alto de dificultad en legibilidad del código mismo y mantenibilidad del código mismo, aun siendo esto una prueba las buenas prácticas no deben dejarse de lado.
se implementaron animaciones teniendo como principio Transform, Transition, AnimanionSize, Animations Opacity y demas widget nativos del Frameword.
Ha nivel de Test se desarrollaron 2 de los 3 niveles existentes:
Este se desarrolló con la mentalidad y propósito de verificación del funcionamiento correcto de la capa de SERVICIOS/DATA y sus diferentes eventos provenientes de esta, garantizando un control de errores acorde a lo esperado por el proyecto.
El principio detrás de estas pruebas es la verificación del flujo bi-direccional de la aplicación, DATA-LOGIC-UI, esto a través de las diferentes formas de emisión de información y eventos accionados por el usuario final.