¿Cómo implementar la comunicación entre capas en arquitectura MVP?
La arquitectura Modelo-Vista-Presentador (MVP) es crucial para la organización de aplicaciones, permitiendo una separación clara de responsabilidades entre las capas. Aquí, exploraremos cómo establecer la comunicación efectiva entre las capas del MVP, usando contratos e interfaces.
¿Cómo crear instancias y comunicar entre capas?
Para iniciar la comunicación efectiva entre la Vista y el Presentador, es fundamental crear instancias adecuadas. En la clase Home, se crea una instancia del Presentador con:
privateval homePresenter =HomePresenter(this)
En este caso, usamos HomePresenter y se pasa como parámetro al contrato de vista, permitiendo una comunicación fluida basada en contratos.
¿Cómo establecer contratos en MVP?
El uso de contratos es esencial para una buena comunicación entre las capas. Al definir contratos, facilitamos que las capas interactúen sin depender de detalles internos. Por ejemplo:
Vista-Contrato: implementa métodos como showLoading, hideLoading y showFavorites.
Presentador-Contrato: define las interacciones permitidas desde la Vista hacia el Presentador, como requestFavorites.
¿Cómo manejar objetos opcionales y nulos?
En programación Kotlin, manejar objetos nulos es esencial, especialmente al interactuar con vistas. Para evitar errores, considere:
Declarar variables mutables opcionales e inicializarlas cuando la vista esté creada.
Utilizar expresiones como ?.let para ejecutar código solo si el objeto no es nulo, reduciendo así posibles errores de ejecución.
¿Por qué es importante la capa de conexión?
La capa de conexión o interactor es fundamental para gestionar la obtención de datos, ya sea desde un caché o una fuente externa. A través de un patrón de callback, como ResponseCallback, esta capa puede devolver listas de elementos favoritos al presentador, asegurando una gestión eficiente de datos.
¿Cómo implementar ResponseCallback?
El ResponseCallback actúa como enlace de datos entre el interactor y el presentador, mediante la venta de métodos como:
En el Interactor, este callback se utiliza para simular la obtención de datos en memoria y devolver listas relevantes al presentador para su posterior trabajo.
¿Qué pasa con las responsabilidades únicas?
En una arquitectura bien definida, es esencial cumplir con el principio de responsabilidad única. Cada capa tiene su papel definido:
Vista: visualizar y actualizar la interfaz de usuario.
Presentador: manipular la lógica de la UI y interactuar con el interactor.
Interactor: gestionar el acceso a los datos y brindar al presentador la información necesaria.
Este enfoque asegura que cada componente se encargue de su propio ámbito, mejorando la mantenibilidad del software.
Con estas prácticas, puedes asegurar una implementación eficaz y mantenible de una arquitectura MVP, trayendo claridad y separación de responsabilidades a tu aplicación. ¡Sigue explorando y optimizando tu código!
Estaba a punto de comentar lo mismo, jajaja. No puedo creer que este sea el curso que está en la cima de toda la ruta de aprendizaje. :/
totalmente deacuerdo
Si estamos hablando de mantener arquitecturas es recomendado pasar las depemdencias por constructor y no intanciarlas sobre la clase, eso ayudara que las pruebas unitarias sean mas faciles de escribir y seguir la buena practica del principio de inyección de dependencias :)
Aparte de utilizar la palabra clave de lateinit, se puede hacer una declaración tipo de lazy de kotlin, de la siguiente manera:
private val homePresenter:HomeContract.Presenter by lazy {HomePresenter(this)}
De esta forma una vez que se utilize la variable homePresenter dentro del fragment, kotlin creara la instancia y para ese entonces la vista ya estara creada.
Creo que necesitaríamos un curso entre medias de este y los fundamentos de Kotlin. Muchas de las cosas que da por echo que se saben no fueron explicadas anteriormente
yo tuve que para este curso para ir a hacer otros cursos gratuitos en youtube, para tener mas cancha y regresar
Creo que hay un problema con el adapter y es el siguiente; el adaptador necesita el arreglo de transferencias para poder funcionar, pero como ya estamos haciendo un retrieve q se demora 3 segundos, se levanta un error porque no tiene ningun arreglo aun.
Lo que yo hice para solucionarlo fue en el método initRecyclerView asignar una lista vacia.al adaptador. De esta manera, el adaptador ya tiene un arreglo (vacio) para poder trabajar y no levanta excepciones.
Como aporte, existe otra forma muy sencilla de implementar los callbacks en Kotlin usando funciones de orden superior:
Sin embargo, debo decir que en el proyecto se usan interfaces lo cual está muy bien.
Para el profesor:
Ya que este curso es de arquitectura deberías tomar en cuenta que una decisión vital para cualquier arquitectura es el coding style, en especial si no vas a trabajar tu solo en el proyecto. Te recomiendo leer este documento oficial de google https://developer.android.com/kotlin/style-guide
#Nice
He comparado lo que enseñas de MVP con lo que enseña Anais en su curso, y veo algunas diferencias, como la de no tener una interfaca para el Interactor, repasando ambos nose bien con cual quedamer :S
Misma situación de mi lado.
Es comprensible que en este curso, MVP si se apega a Clean Architecture y por ende cambie un poco la organización. Sin embargo desconozco cuál sería la estructura correcta.
Partiendo desde la forma de nombrar a la clase y a la interfaz de presenter, el directorio model(ahora es data) y por ende la clase modeladora FavoriteTransfer no está dentro de model, si no que queda en un plano más "general"
Existen incongruencias, eso es un hecho.
parentesis? 3:32
lol : )
null safety
Nota: Deja tu código bien limpio con los espacios necesarios para que puedan ser legibles
Esta clase me recuerda mucho a los profesores de mi colegio, en donde no explican, hacen preguntas para ellos mismo y se responden a si mismos como si fuera lo mas obvio del mundo, no se si sea el único con esta sensación pero hace la clase muy pesada y el aprendizaje bastante torpe, no entiendo que esta pasando en todo esto y no se si eliminaron un curso entre este y el diseño de interfaces pero es entrar a este y estar perdido.
Hilo para mi mismo, nuevo enfoque, imprimir el código e ir desenvolviendo que chingados por mi cuenta y luego de entenderlo regresar al curso.
(Si respondo mis propios comentarios, es como mi bitácora jaja)
unusual sound
a Cristian y a la comunidad ¿creen que usar diagramas de clases pueden mejorar la visibilidad de las relaciones entre las clases y el uso del mvp?
Hola Ivan, lo que entiendo de tu pregunta es si los diagramas de clases te ayudan a entender mucho mejor las relaciones entre las entidades, la respuesta personal es que sí, ya que te da una visión global donde podrías empezar a ver que tantas relaciones o entidades tienes y así poder optimizarlo
Buena explicación
para no crear un objeto vacio y luego que me diera error on picasso hice lo siguiente
S — Single responsibility principle (Principio de responsabilidad única)
O — Open/closed principle (Principio abierto/cerrado)
L — Liskov substitution principle (Principio de sustitución de Liskov)
I — Interface segregation principle (Principio de segregación de interfaces)
D - Dependency inversion principle (Principio de inversión de dependencias)
