Android Firebase Kotlin java Mvp Mvc Mvvm chat

¿Cuál es este repositorio para ❓

Aplicación simple con una conectividad de uno a uno utilizando la base de datos de Firebase en tiempo real escrita en la arquitectura MVC, MVP y MVVM para comprender mejor los patrones de codificación de Android. El propósito de escribir la misma funcionalidad de aplicación con 3 patrón diferente es mostrar cómo se puede desarrollar una sola aplicación utilizando 3 patrones diferentes (MVC, MVP, MVVM).

MVC (controlador de vista de modelo) 〽️ ✔️ C

MVC es un enfoque limpio en Android colocando vistas del controlador. El controlador solo es responsable de actualizar modelos, una vez que el modelo se actualiza, puede notificar a las vistas y luego la vista se puede actualizar utilizando las devoluciones de llamada adecuadas. MVC tradicional es donde hay un

Modelo : actúa como el modelo de datos
Vista : trata con la vista al usuario que puede ser la interfaz de usuario
Controlador : controla la interacción entre el modelo y la vista, donde la vista llama al controlador para actualizar el modelo. Una vista puede llamar a múltiples controladores si es necesario.

MVP (presentador de vista de modelo) 〽️ ✔️ ? ️

Algunas desventajas de MVC pueden superarse utilizando el enfoque MVP. El presentador en MVP contiene toda la lógica de negocios y esta clase está lejos del contexto de Android o las dependencias relacionadas con Android, lo que proporciona flexibilidad para enviar un texto de la lógica comercial simplemente utilizando la clase de presentadores en los módulos de prueba. Las dependencias relacionadas con Android crean complejidad en las pruebas. El presentador no tiene ninguna dependencia de Android como contexto, vista, etc. y todas las actualizaciones del modelo y las solicitudes de red se realizan a través del presentador. Una vez que el modelo se actualiza o se completa una solicitud de red, la vista se actualiza a través del presentador utilizando devoluciones de llamada para ver desde el presentador. Ningún modelo y solicitud de red puede abordar directamente las vistas.

MVVM (Modelo de vista de vista de modelo) 〽️ ✔️ ✔️ 〽️

MVVM implica un enfoque de enlace de datos para hacer corto código y reducir el código de manejo de la vista de las clases de Java. Los modelos de vista son responsables de actualizar la vista y una vez que un modelo de vista está vinculado a una vista, vea la notificación sobre sus eventos de actualización. Si un modelo se actualiza por un usuario, haga clic en el modelo, envíe las devoluciones de llamada para ver el modelo que actualiza la vista automáticamente a medida que se ata a las vistas. MVVM reduce el tamaño del código, pero la implementación de MVVM es bastante difícil y es difícil depurar grandes proyectos basados en MVVM.

Elección del arquitecto correcto

?
La elección de una arquitectura correcta para el proyecto implica la comprensión de los módulos que deben desarrollarse. Algunas funcionalidades funcionan muy bien en MVC, algunas con MVP y otras con MVVM. Es bastante difícil depurar los proyectos realizados en MVVM, especialmente aquellos que no tienen un flujo de datos un lado debido a la vinculación de datos y los datos en vivo. Si una aplicación recibe un flujo de datos continuo de una fuente, necesita una actualización de interfaz de usuario regular y tiene principalmente (80-90%) comunicación unilateral (por ejemplo: un dispositivo electrónico que envía registros a una aplicación Android) como aplicaciones de células solares, aplicaciones de inversores o el monitoreo de estado de cualquier otro dispositivo puede funcionar bien con MVVV de MVVV debido a datos en vivo . La depuración de estas aplicaciones MVVM puede ser fácil ya que el flujo importante de datos es un lado .

MVP es un buen enfoque para escribir proyectos de Android cuando nos preocupa probar las pruebas de la unidad WRT de la lógica comercial a través de Java Test Frameworks (no Android). Dado que Java Test Framework solo resolverá las dependencias de Java y una capa de presentador limpia está libre de dependencias relacionadas con Android como contexto, compartido compartido o cualquier otro com.android. * paquete. El inconveniente de MVP es que termina escribiendo un código adicional 20-25% con la misma funcionalidad escrita en MVC o MVVM. MVP es bueno si está realmente interesado en los casos de prueba y las pruebas unitarias de módulos. Para MVP usando los kits de prueba Java, solo haga instancia de las funciones de prueba y ejecute las funciones de prueba.

por ejemplo: nuevo presentador (). testSomeFunction () .

MVC es una técnica ampliamente utilizada en Android. Google escribió sus repositorios en MVC durante muchos años. Hoy en día, Google está adoptando MVVM para sus repositorios de GitHub, ya que estos repos son pequeños y principalmente muestras. La aplicación MVC se puede probar a través de los marcos de prueba de Android, no con herramientas de prueba específicas de Java debido a la falta de dependencias de com.android. * Paquetes en la herramienta específica de Java.

Ejemplo :

1. Se puede escribir una aplicación de chat en MVC, MVP, MVVM dependiendo de los requisitos de prueba y el flujo de datos.
2. Una aplicación de monitoreo de inversor luminoso puede funcionar mejor con MVVM debido al principal flujo de datos unilado.
3. La aplicación de comercio electrónico se puede construir en MVC, MVP, pero MVVM puede hacer que algunos módulos sean muy complejos.

Nota : No hay una arquitectura única que sea mejor de todo. Si hubiera uno, no habría necesidad de aprender otras arquitecturas. La elección de la arquitectura correcta depende de varios factores como requisitos iniciales, flujo de datos, escalabilidad, mantenimiento, actualizaciones (CRS), requisitos de prueba.

Excepto estas tres arquitecturas de Android, hay una arquitectura más llamada "intención de vista MVI - Modelo". Esto no es muy popular entre los desarrolladores de Android. Consulte este enlace si está interesado en MVI .
https://github.com/saksham24/android-simple-mvi-pattern-with-mvp-mvvm-colaboración

FIN ️