Luego de de esta extensa búsqueda de datos resolvimos esta dificultad que presentan ciertos de nuestros usuarios. Te ofrecemos la respuesta y nuestro deseo es que sea de mucha ayuda.
Solución:
Desde mi experiencia, cada patrón de arquitectura se inventó para resolver un problema específico que el anterior ignoró o aún no se observó.
MVC – Controlador de vista de modelo
en las aplicaciones de interfaz de usuario, la responsabilidad de representar los datos en la pantalla o la lógica empresarial y vincularlos al principio no estaba clara. Entonces MVC llegó a definir esa responsabilidad en tres componentes, cada uno tiene un propósito, y la imagen describe la relación entre esos tres componentes.
Ver: es el componente de la interfaz de usuario que tiene todas las propiedades como el color, la forma, las herramientas para escuchar los eventos de clic, etc.
Modelo: es el componente que define la lógica empresarial que desea que la vista represente y se comporte en consecuencia.
Controlador: es quien cambia el modelo, por lo que si la vista tiene un nombre, por ejemplo, para guardar, Ver pasarlo al controlador y luego el controlador manipular el modelo con las acciones correctas.
MVP – Presentador de vista de modelo
El problema con MVC es que hay un gran acoplamiento entre los tres componentes, si desea cambiar las llamadas a la vista, será necesario que actualice el controlador y el modelo. y eso está claro a partir de la imagen de MVC, la relación entre los tres componentes está muy ligada, no podría reemplazar uno de esos componentes sin el otro. Entonces MVP vino a proporcionar una solución más limpia al problema anterior al separar el modelo y la vista, mantener las interacciones entre ellos a través del presentador, el presentador es el intermediario que llaman tanto la vista como el modelo. Entonces, si desea guardar una lista de películas favoritas, Ver escuchar al usuario
ingrese la descripción de la imagen aquí
MVVM – Vista de modelo ViewModel
Con el surgimiento del paradigma reactivo, quedó claro que podemos proporcionar más preocupaciones independientes en las aplicaciones de interfaz de usuario simplemente observando los cambios y comportándonos en ellos. por ejemplo, hay un clic en la vista que necesita llamar a una API para obtener los últimos programas de televisión.
Este clic en la vista se observará en ViewModel, ViewModel interactuará con el modelo para obtener los datos y, finalmente, ViewModel publicará esos datos en la vista utilizando otro observador.
ingrese la descripción de la imagen aquí
Entonces, después de hablar sobre los patrones de arquitectura más populares, cada uno ha intentado desacoplar el código de la interfaz de usuario del código comercial. pero los patrones anteriores no vinculan la actualización de la interfaz de usuario con diferentes estados al mismo tiempo.
Si tuvo un problema relacionado con la carga que aparece con un mensaje de error que se muestra al mismo tiempo, comprenderá de lo que estoy hablando, por lo que para mantener el estado de la interfaz de usuario, debe hacer un esfuerzo adicional para buscar lo que escribió mal que causa esos tipo de problemas.
MVI – Intención de vista de modelo MVI se basa en una vieja idea llamadamáquina de estados finitos
, cualquier sistema o componente tiene predecibles, el conjunto de estados es una máquina de estados finitos. en MVI, cualquier actualización de la interfaz de usuario está definida por un nuevo estado, es posible que esto sea abrumador, pero imagina que tienes una captura de pantalla para cada vez que cambia la interfaz de usuario, ese es el estado. puede depurar, probar y reproducir los problemas de estado ahora.
cómo lograr esto, ese es el MVI en la práctica. cualquier interacción del usuario con la interfaz de usuario, se define en MVI por unIntención
, Intent es lo que el usuario necesita de esta acción, podría ser protagonizar una película, actualizar la pantalla, incluso podría abrir la pantalla, en ese caso el Intent es una intención inicial para mostrar la pantalla con todos los datos requeridos.
qué componente obtiene esos Intents para actuar de acuerdo con ellos, que lo que defina … podría usar un Presenter o un ViewModel, no importa, MVI es más una práctica que usar un nuevo componente intermedio.
Continuaré con ViewModel, ViewModel obtendrá esas intenciones, decidirá a qué caso de uso llamar (comportamientos del modelo).
todos los casos de uso pasan por la función de verano en el ViewModel, que decide qué estado debe reflejarse en la Vista, también le proporciona el estado anterior, por lo que tiene el estado anterior y el nuevo para actualizar la pantalla, lo que reduce las actualizaciones de renderizado y Ver solo obtienen las nuevas sugerencias para actualizarse.
y finalmente MVI es un flujo unidireccional, comienza con la Vista y termina con la Vista.
… Ver -> ViewModel / Presentador -> Modelo -> Ver -> …
MVI es diferente en la forma de administrar el estado, es una combinación de varias ideas para crear una aplicación más estable y comprobable.
Un gran desglose está aquí: https://academy.realm.io/posts/mvc-vs-mvp-vs-mvvm-vs-mvi-mobilization-moskala/. En esencia, MVI está tomando las ideas de MVVM (estado de IU sin estado), modelos y lógica de negocios separados, y poniendo el marco reactivo encima. Hacer que las cosas sean flujos de eventos en lugar de acciones discretas, hacer que los elementos receptores sean consumidores de flujos transformados en lugar de elementos de presentación, y convertir el estado en algo de solo lectura y desechable sobre el que se actúa explícitamente de una manera muy estructurada.
Esto requiere que adopte un enfoque funcional para escribir su aplicación, especialmente la parte UI / View de las cosas. El estado no se modifica, el nuevo estado se calcula a partir de una intención y una serie de casos de uso. Esto está bastante bien explicado aquí: https://proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8a.
Su objetivo es abordar la creciente complejidad de las aplicaciones de interfaz de usuario modernas, que tienen una cantidad no trivial de estado del lado del cliente que debe administrarse explícitamente. Como saben los programadores más experimentados, las fallas más complejas provienen de un estado que se está modificando de manera inesperada. Esta manipulación de estado puede resultar en estados “no válidos” que su aplicación no puede manejar, lo que efectivamente es una aplicación bloqueada. MVI aborda esto haciendo que las transiciones de estado sean explícitas y cuidadosamente estructuradas para que el sistema nunca llegue a un estado inválido y el estado sea siempre comprensible.
Reseñas y puntuaciones del artículo
Si te mola el proyecto, eres capaz de dejar un enunciado acerca de qué te ha gustado de este enunciado.