Generalidades

Arquitectura reactiva de MVP/MVC a Jetpack Compose por Yijian | enero de 2022

parentesco fácil

Esto puede ser un problema común para cualquier aplicación de Android que tenga más de cinco años porque Los desarrolladores intentan integrar Jetpack Compose. Antes del lanzamiento de los componentes de la arquitectura de Android en 2017, Google no tenía una arquitectura recomendada o opinada. Como resultado, las personas que escribieron aplicaciones copiaron y pegaron ejemplos del sitio de documentación de Android y los usaron como «arquitecturas»; los ejemplos en ese entonces no eran tan buenos como lo son hoy, por lo que las personas terminaron poniendo mucha lógica comercial en sus fragmentos. y actividades Esta es una arquitectura pseudo-MVC (Modelo-Vista-Controlador), los fragmentos/actividades son «controladores», los diseños XML son «vistas» y cualquier clase de datos son «modelos» (las interacciones de base de datos/web a veces están en modelos, hay cuando está a la vista depende de cómo el desarrollador interprete la documentación de Android).Las aplicaciones que usan MVC tienden a verse como Esta:

Estructura de Android MVC de https://www.codementor.io/@dragneelfps/implementing-mvc-pattern-in-android-with-kotlin-i9hi2r06c

Las personas que se dan cuenta de que poner la lógica empresarial en Fragmentos/Actividad es difícil de probar (usualmente necesita robot electrico), terminaron usando el modelo MVP (Modelo-Vista-Presentador) (en algunos casos, descompusieron Presentadores grandes en casos de uso e interactuadores, o algo así como iOS víbora Modelo). Una «vista» es una interfaz definida para un fragmento/actividad. El «modelo» sigue siendo prácticamente el mismo, pero también es donde siempre ocurre el acceso a la base de datos/red. La lógica empresarial termina en el presentador, la vista llama al presentador y el presentador llama a la vista para actualizar los cambios del modelo en la vista; el presentador también maneja el ciclo de vida de Android mediante los métodos onStart/onDestroy() llamados por la vista. MVP es una arquitectura muy orientada a la devolución de llamada.esto es bueno generalizar Cómo se ve un MVP en una aplicación grande:

LEER  Consulte la documentación oficial de la actividad de Android - 3 (Comprensión del ciclo de vida de la actividad) | Por Joon Hyung | Abril de 2022

Desafortunadamente, estas antiguas arquitecturas MVC/MVP no son adecuadas para una interfaz de usuario reactiva como Jetpack Compose. El presentador es, en última instancia, solo un intermediario de retransmisión de datos vacío sin apenas lógica real.

No sorprende que las IU reactivas (ReactJS, SwiftUI, Flutter y Jetpack Compose) funcionen mejor con flujos de datos reactivos. Por definición, una IU reactiva reacciona a los cambios en su modelo de datos, por lo que no se requiere un presentador (por definición, un presentador controla la vista). Por lo tanto, cualquier arquitectura con datos observables tiene una fricción mínima cuando se usa una interfaz de usuario reactiva.

Las arquitecturas de Android admitidas oficialmente son MVVM (Model-View-ViewModel); el soporte viene en forma de soporte de documentación y biblioteca. Google lanzó esta función en 2017 como parte del programa Android Architecture Components (AAC).

La lógica empresarial en ViewModel actualiza los campos creados como LiveData (para aplicaciones que no usan Kotlin Coroutines) o StateFlow (para aplicaciones que usan Kotlin Coroutines).uso de la aplicación RxJava Todas las llamadas de red y base de datos y otros subprocesos generalmente se mantienen en RxJava hasta que alcanzan el límite de ViewModel donde la transmisión de RxJava se expone como LiveData. Para las aplicaciones antiguas basadas en el diseño XML de Android, el enlace de datos se usaba a menudo para vincular las propiedades del campo de diseño XML a los campos LiveData en ViewModel. Esto generalmente se ve así:

Aquellos que adopten la arquitectura MVVM en 2017 pueden usar la misma arquitectura que Jetpack Compose. Sin embargo, para optimizar el uso de MVVM por parte de Compose, los campos deben agruparse en una clase de estado.

Irónicamente, cuando se lanzó AAC MVVM, la comunidad de Android ya estaba adoptando IMV Edificio hace un año.

ReactJS fue de código abierto de Facebook en 2013 y ha sido la inspiración para la mayoría de los marcos de IU reactivos en la actualidad. Las técnicas utilizadas en ReactJS también se aplican a Jetpack Compose. marco redux (Código abierto en 2015) es un marco de gestión de estado muy popular reacciónmundo JS. Redux generalmente no se usa en el mundo de las aplicaciones, ya que requiere un almacén de datos de aplicaciones global, pero las aplicaciones nativas tienen múltiples pantallas de creación/destrucción, por lo que solo debe considerar esto para aplicaciones más simples.

MVI se remonta a una biblioteca inspirada en Redux llamada «Mosby”, Hannes Dorfman Creado en 2016. MVI emite un flujo continuo de estado de pantalla que Compose puede consumir directamente; esto significa que ViewModel ya no es necesario en una aplicación Compose pura (o puede pensar en el motor de estado de MVI como un «modelo de vista»). Sin embargo, el componente ViewModel de Android Arch aún se puede usar para preservar el estado durante la rotación de la pantalla y manejar otros problemas del ciclo de vida de Android, como guardar el estado para la resurrección de la aplicación y proporcionar el ciclo de vida para las corrutinas de Kotlin.

Los estados en este diagrama de arquitectura MVI son usados ​​directamente por interfaces de usuario reactivas como Compose. Debido a la definición estricta de eventos y estados, los estados también se pueden reproducir para MVI y Redux (también conocido como soporte de «máquina del tiempo» o «viaje en el tiempo»).

BLoC es el marco Flutter oficial de Google, que significa «Bloques lógicos». Por lo general, se asocia con componentes/widgets, pero también se puede conectar para crear una lógica comercial más compleja. Fue creado en 2019, pero curiosamente Google nunca lo transfirió a Android. El uso de BloC es similar al modelo de vista en Dart.

olmo es una arquitectura de front-end web que es anterior e inspiró a Redux (al menos según su documentación :-). Como puedes ver, también es muy similar a MVI:

desde https://steemit.com/utopian-io/@tensor/using-the-elm-architecture-or-the-mvu-pattern-with-dartea-inside-of-dart-s-flutter-framework

La principal diferencia es que proporciona una vista que contiene la representación. En el contexto de Jetpack Compose, la arquitectura Elm proporciona Composable, una vista. Esto acerca la visualización de la vista al modelo para lograr un acoplamiento más estrecho.

Cada arquitectura tiene ventajas y desventajas, por lo que debe decidir cuál es la mejor para usted.

MVVM Es un estándar oficial de Google, pero no aplica estrictamente el flujo de datos unidireccional (UDF). También será más conocido por los desarrolladores. Estas bibliotecas están estrechamente relacionadas con Android, por lo que la lógica empresarial no se puede compartir fácilmente con Kotlin Multiplatform (aunque la biblioteca Moko MVVM ayuda). Repetitivo mínimo (es decir, definiciones de contrato con interfaces).

reducción Esencialmente aplica las UDF, pero el almacenamiento de datos se encuentra en el nivel de la aplicación. Compatibilidad con la depuración de «viajes en el tiempo».

IMV Esencialmente aplica las UDF y la lógica empresarial es fácil de probar. Admite la depuración de «viajes en el tiempo» del almacén de datos. Los datos se almacenan a nivel de pantalla.

grupo Ampliamente probado con las aplicaciones de Flutter, pero no forma parte del componente Android Arch respaldado por Google. También hace cumplir las UDF. La compatibilidad con «Time Machine» puede no ser posible debido al almacenamiento privado de datos. La lógica se asigna al nivel de widget, mientras que los marcos generalmente se asignan al nivel de pantalla/aplicación.

MVU Existe un estrecho acoplamiento entre la vista y el modelo, lo que le permite agruparlos mejor, y también tiene la aplicación de UDF. Sin embargo, un acoplamiento más estrecho no le permite usar la misma lógica comercial para diferentes vistas.

El breve resumen es que todas estas arquitecturas se pueden usar en Compose.

MVVM tiende a alentar a las personas a exponer campos individuales como observables porque el DataBinding utilizado en el antiguo sistema XML/Layout requería una exposición separada de las propiedades del widget. Las personas que han usado MVVM antes de Jetpack Compose tienden a usar campos separados en sus modelos de vista, que también se usan en Compose.

Por el contrario, MVI y otros marcos fomentan una mayor subdivisión del estado de la pantalla en lo que se requiere para cada subsección del estado de la pantalla. Los widgets de composición pueden aceptar una sola clase de estado de vista para el estado de vista. MVI también tiende a tener más repeticiones en las definiciones de interfaz/clase para ayudar a hacer cumplir el uso correcto.

También es posible construir una capa encima de MVVM para crear un marco MVVM+ que agregue más medidas de seguridad para fomentar el uso de una sola clase de estado. Cubriremos los marcos MVVM+ existentes y sus compensaciones en otro blog.

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba