Esta reseña ha sido probado por nuestros expertos para que tengas la seguridad de la veracidad de nuestra esta reseña.
Solución:
MVP existe para abordar el problema de la actividad de Dios (una actividad/fragmento que tiene demasiadas líneas).
Si bien no era obligatorio (puede codificar en cualquier patrón que desee), muchos desarrolladores están de acuerdo en que MVP es adecuado para Android. Hace que su código fuente sea más limpio, comprobable, mantenible y robusto.
Puede pensar en un interactor como su “Modelo/Controlador”. Un interactor obtendrá datos de su base de datos, servicios web o cualquier otra fuente de datos. Después de obtener los datos, el interactor enviará los datos al presentador. Por lo tanto, hacer cambios en su interfaz de usuario.
Las ventajas de usar interactor en una clase separada es que desacoplará su clase, haciéndola más limpia y comprobable. Claro, puede poner el interactor en su clase interna de presentador, pero ¿cuál es el punto? Las desventajas de poner el interactor en su presentador es que hará que su clase de presentador sea más grande y relativamente más difícil de leer y administrar.
Actualización: por supuesto, esto es solo una simplificación excesiva, si desea profundizar, puede ver el blog de fernando cejas o el blog de antonio leiva
Interactor es una clase que separa la capa de dominio de la capa de presentación. En palabras simples, proporciona una forma de escribir la lógica comercial por separado del código que se usa para manipular la interfaz de usuario (al vincular datos a la interfaz de usuario/animación/navegación).
Entonces, Interactor es un mediador entre Presenter/ViewModel y el patrón Repository.
No he usado el patrón Interactor en MVP, aunque lo he usado en MVVM. Interactor se puede usar indistintamente para UseCases.
Por ejemplo, tomemos el caso de uso de buscar categorías para mostrar en la lista (en el siguiente ejemplo, Presenter representa MVP y ViewModel representa el patrón MVVM).
- Ver (Actividad/Fragmento) llamará al método de Presenter/ViewModel para obtener la lista de categorías.
- Luego, Presenter/ViewModel llamará al método del interactor para obtener la lista de categorías.
- Interactor llamará al método Repository (CategoryRepository) para obtener la lista de categorías
- El repositorio tendrá lógica para decidir si obtener categorías del servicio web (origen de datos remoto) o del almacenamiento de base de datos (origen de datos local) o del caché (almacenamiento temporal; puede ser variable en la clase de repositorio).
- El repositorio devolverá la lista de categorías (obtenida de la fuente de datos seleccionada) a Interactor
- Interactor procesará en categoryList (algunos formatos, etc.) y lo enviará a Presenter/ViewModel. Interactor puede enviar directamente la lista a Presenter/ViewModel si no se necesita procesamiento
- Presenter/ViewModel llamará al método de View con categoryList como parámetro
- La vista mostrará la lista de categorías con o sin animación
Tenga en cuenta que en este proceso se puede evitar Interactor, por lo que en lugar de utilizar un flujo de datos como este Repositorio->Interactor->Presentador/ViewModella comunicación puede ocurrir por Repositorio->Presentador/ViewModel Por aquí. Aquí Presenter/ViewModel será parte de la presentación, así como también de la capa de dominio. Como dije anteriormente, Interactor actúa como separador de estas dos capas.
Estos son algunos blogs escritos de manera concisa para explicar este concepto como referencia.
- arquitectura-limpia-con-mvvmi
- android-mvp-architecture-extension-with-interactor
- arquitectura-android-la-manera-limpia
Espero que esto lo ayude a comprender mejor el papel de Interactor. ¡¡¡Feliz codificación!!!
Interactor contiene los casos de uso de la aplicación, lo que significa que contendrá todas las implementaciones para el dominio empresarial del proyecto.
Aquí hay un artículo muy bien organizado sobre arquitectura de aplicaciones de Android, utilizando el patrón MVP, que le recomiendo que estudie.