Su primer proyecto de Android Clean MVI | por Seef Kordia | Agosto de 2021
Bueno, has oído hablar de arquitectura limpia y MVI, lo buscaste, finalmente llegaste aquí, bienvenido a unirte a la junta directiva.
Entonces, ¿por qué limpiar la arquitectura y el MVI?
¿Cuál es el problema con el estilo de código normal y el patrón de diseño aleatorio normal, por qué debería considerar pasar a una arquitectura limpia y MVI?
Bueno, comencemos con un arco limpio …
Imagina que eres un libro de papel leyendo en un estanteelectrónicor, y guardas todos tus libros en una habitación oscura con cajas aleatorias, qué difícil es encontrar tus libros,
Y lo difícil que es hacer un seguimiento de los libros que ha leído y cómo planificar la próxima reunión de lectura, creo que hizo clic ahora, todo tiene que ver con la organización.
Se trata de organizar tu código. No entraré en la arquitectura limpia en este artículo. Lo que estoy mostrando aquí es una arquitectura limpia desde mi punto de vista, sin discusiones complicadas y engorrosas.
¿Por qué debería cambiarme a una arquitectura limpia?
su:
-Mantenible.
– escalable.
– Limpio.
-Sigue los principios SOLID.
-Muy adecuado para grandes equipos y proyectos.
Bien, ahora estoy seguro de que una arquitectura limpia es mi mejor opción, ¿cómo puedo implementarla en mi proyecto de Android?
De hecho, configurarlo puede parecer un poco complicado y muchos pasos, pero una vez que lo hace por primera vez, su vida como desarrollador ya no es la misma.
Recuerdo cuando me uní a un equipo que estaba trabajando en un gran proyecto. No seguían ninguna regla. La aplicación estaba estropeada, el código flotaba por todas partes y, aproximadamente un mes después, la aplicación se estrelló contra la pared, así que tuvimos que Rehaga todo el proyecto desde cero. Imagine una pérdida de tiempo y dinero.
Ahora puede preguntar, ¿por qué es MVI?
Del mismo modo, no hay una discusión técnica pesada, todo está relacionado con la organización, MVI es básicamente MVVM, pero con características adicionales, tienes una intención para cada acción, sin ningún tipo de aleatoriedad, ingresaremos pronto.
Vayamos a la parte interesante …
Comenzaremos con un proyecto básico de Android vacío con una sola actividad.
Ahora que tiene un nuevo proyecto impresionante, el siguiente paso es crear capas,
Cada capa aquí es un módulo, pero espera, ¿qué capa / módulo necesitamos?
Bueno, el enfoque principal es sugerir tres capas principales (aplicación, dominio y datos).
-Data es responsable de todas las conexiones al almacenamiento interno y externo.
-El dominio es el intermediario, es el responsable del repositorio y los casos de uso.
-La aplicación se encarga de presentar los datos al usuario, toda su UI está aquí.
¿Qué pasa con este método? !
Como venía diciendo, todo esto tiene que ver con la organización, que es lo que la hace diferente.
Capa de presentación, tadaaa.
Si ha tratado con la inyección de dependencia antes, sabrá que la capa di debería ver todas las demás capas, así que coloque la lógica de la interfaz de usuario en el mismo lugar,
Corremos el riesgo de usar la lógica de datos directamente sin pasar las reglas y restricciones del repositorio, todo debe ser intencional.
Por lo tanto, el nuevo método se ve así:
-Application di – puede ver todas las capas
-Datos almacenados interna y externamente-Se puede ver la capa de dominio
-Dominio de repositorios y casos de uso-sin acceso a ninguna capa
-Visualización de la lógica de la interfaz de usuario-puede ver el dominio
Consulte el archivo Gradle en el proyecto de muestra para obtener más detalles.
Cuánto nos beneficiamos:
-Cuando usa Kotlin, puede cambiar fácilmente a KMM (Kotlin Multiplatform Mobile).
-Puedes actualizar tu lógica desde un solo lugar, y se aplicará automáticamente a todas las partes de la aplicación sin estropear cada fragmento de código.
-Cada miembro del equipo se centrará en su propio código y no le importará ningún otro cambio.
-La escalabilidad de su código está más allá de su imaginación.
Entremos en el código
Si observa su Gradle, encontrará que se ve así:
Podemos organizar aún más nuestras dependencias,
Cree un nuevo archivo llamado dependencies.gradle en el directorio principal.
¿Qué es este archivo?
Este es un archivo Gradle donde colocaremos todas las dependencias y las referenciaremos
De esta manera podemos asegurarnos de que todas nuestras dependencias sean consistentes y sigan las mismas bibliotecas y versiones.
Finalmente, agregue esta línea en la parte superior de su archivo Gradle a nivel de proyecto para indicarle a su proyecto dónde hacer referencia
Aplicación de: ‘dependencies.gradle’
Así es como se ven nuestras dependencias:
Así es como se ve nuestro archivo Gradle del módulo de aplicación:
Esto puede parecer un proceso largo, pero una vez que sientas sus beneficios, no te arrepentirás y te gustará repetirlo en cada proyecto que comiences.
De hecho, he movido algunas de mis aplicaciones muertas aquí, solo para probar las aguas y ver cómo va, y va bien.
Creo que lo entiendes ahora, ¿cuál es el siguiente paso?
Cuando eliminamos la parte de arquitectura limpia, nos alegramos de usar nuestro código.
Suponiendo que sepa cómo usar Hilt y comprenda los conceptos básicos de los componentes de navegación y Room db, comenzaré con la clase base y la clase básica, por ejemplo:
-Estado de datos
-Modelo de vista básico
-Intención básica
-Fragmento básico
Vamos a desglosarlos uno por uno:
Archivo de estado de datos
Una clase sellada que encapsula nuestra respuesta de datos, incluidos 4 tipos de estado
-Exito: cuando obtenemos los datos con éxito, envolvemos la respuesta con Éxito.
-Error: cuando obtenemos un error al obtener los datos, envolvemos la respuesta con un error.
-Loading: ningún objeto que represente el estado de carga.
-Empty: un objeto Nothing que se usa para decirle a la interfaz de usuario que la respuesta fue exitosa pero que no se encontraron datos.
Intención básica.kt
En realidad, es una clase vacía, solo para ser el padre de la clase de intención,
Luego usaremos polimorfismo con clases de subintención para generar fragmentos, no te preocupes, estamos aquí.
Vista base model.kt
Esta es la base de todos los modelos de vista. Requiere una clase BaseIntent genérica, lo que facilita la abstracción de la función onTriggerEvent. Guiaremos todas las intenciones futuras del fragmento.
Fragment.kt básico
Bien, aquí está el material gordo, pondremos las funciones de uso frecuente aquí, esta clase adoptará el tipo genérico de ViewBinding,
Esto significa que puedo completar todos los enlaces establecidos en la clase principal desde el inicio hasta la destrucción en menos pasos.
Además, tenemos una forma de iniciar fácilmente bloques de código en IO y UI usando corrutinas.
Otra cosa interesante es la actividad del host, puede preguntar aquí, ¿qué tiene de malo requireActivity ()?
En algunos casos, es posible que las actividades del host no estén disponibles a través de requireActivity (), como cuando ejecuta procesos y navega en segundo plano / IO
Fuera del fragmento antes de que se complete el proceso y luego se requiera requireActivity (), adivinó que es «anormal»,
Si se adjunta un fragmento, hostActivity en BaseFragment devolverá el contexto de MainActivity; de lo contrario, devolverá un contexto como MainActivity.
Vamos a sumergirnos ahora en la parte de MVI:
Para mostrarle la forma correcta de configurar y obtener datos del almacenamiento local, configuré una base de datos de Room, que contiene una tabla y dos columnas «tabla de nombres» (id, nombre).
La aplicación tomará el nombre ingresado por el usuario, lo almacenará y mostrará todos los nombres en la tabla.
Después de eso, configuro la interfaz del repositorio y la coloco en el módulo de dominio para que la capa de presentación pueda verla.
Luego ingresamos a la lógica del repositorio «NameRepositoryImpl.kt», que debería estar ubicada en la capa de datos, para que la capa de presentación no entienda la lógica en absoluto.
Ahora es el turno de demostrar, crearemos tres fragmentos de clases principales, modelos de vista e intenciones:
—— Nombre fragment.kt – Heredado de BaseFragment.kt
—— NameIntent.kt – heredado de BaseIntent.kt
—— Modelo de vista de nombre.kt – heredado de BaseViewModel
Comience con la intención:
Vista de nombre model.kt
Nombre fragment.kt
Eso es todo, ahora cuando solicita datos de la capa de datos, conoce el estado exacto de la respuesta y sabe cómo manejar cada tipo de estado.
Además, no está limitado a lo que se menciona en la clase DataState, puede agregar cualquier estado que se adapte a su lógica.
Aquí hay algunos consejos que puede encontrar durante el viaje:
-Agregue esta línea de implementación a su archivo de módulo de aplicación para admitir multidex
Implementar ‘androidx.multidex: multidex: 2.0.1’
-Agregue esta línea a gradle.properties para evitar el problema de hilt di
kapt.use.worker.api = falso
Una arquitectura limpia es increíble para construir su proyecto, pero siempre podemos hacerlo mejor, no dude en agregar su estilo, pero tenga cuidado.
La arquitectura de la aplicación es muy importante, pero no todo, necesitamos patrones de diseño para lograr una armonía perfecta.
Se trata de organización. Te ahorrará tiempo y dinero en proyectos medianos y grandes. Puedes pensar que es un gasto, pero no, vale la pena.
Si tiene alguna pregunta, no dude en ponerse en contacto conmigo.
Aplicación de: ‘dependencies.gradle’
