En kotlin podemos usar el lateinit para instanciar la variable despues y no inicializarla nula
private lateinit var homePresenter: HomeContract.Presenter
Luego en el onViewCreated se puede instanciar
homePresenter = HomePresenter(this)
Arquitectura
Patrones de diseño en aplicaciones Android
Componentes de Arquitectura de Software en Android
Arquitecturas Android: MVP y MVVM
Clonación de Repositorios con Git y GitHub
Arquitectura Modelo Vista Presentador: Principios y Aplicaciones Prácticas
Arquitectura MVC: Diseño y Estructura de Paquetes en Android
Comunicación entre Capas y Contratos en Arquitectura MVP
Arquitectura MVVM para Aplicaciones Android
Arquitectura MVVM en Android: Comunicación y Funcionalidad
Patrones de diseño
Patrones de Diseño Comunes en Android Development
Patrones de diseño creacionales
Patrón Singleton en Kotlin: Implementación práctica
Uso de Singletons en Kotlin: Patrón de Diseño Inteligente
Patrones de Creación: Implementación del Builder en Android
Patrón Builder: Creación de Objetos Complejos en Java
Scope Functions en Kotlin: Uso de apply para Modificar Instancias
Patrón Factory: Creación y Uso en Aplicaciones de Mensajería
Patrones de diseño estructurales
Patrones de Diseño: Creación de Adaptadores en Proyectos de Software
Patrón Proxy: Seguridad y Negocio en Transferencias de Datos
Patrón de Diseño Fachada en Proyectos Complejos
Patrones de comportamiento
Patrones de Diseño: Implementación del Observer en Java
Patrón Observer en Kotlin: Implementación y Uso en Aplicaciones Android
Patrón Comando en Kotlin: Implementación con Command Manager
Comandos en Android: Leer y Escribir Archivos
Programación en Android: Patrones de Comportamiento en Java
Bonus: Architecture Components
Componentes de Jetpack en Android: Manejo Eficiente de Recursos
Programación reactiva con LiveData en Android
Instalación y Configuración de Room en Android Studio
Bases de datos con Kotlin: Creación de entidades y acceso con Room.
Conexión de Room Database con Android: Guardar y Leer Transferencias
Implementación de ViewModel en Android con LiveData
Bonus: Custom View
Creación de Vistas Personalizadas en Android con Custom View
Conclusiones
Patrones de Diseño Clave para Aplicaciones Android
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
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.
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:
private val 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.
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:
showLoading
, hideLoading
y showFavorites
.requestFavorites
.En programación Kotlin, manejar objetos nulos es esencial, especialmente al interactuar con vistas. Para evitar errores, considere:
?.let
para ejecutar código solo si el objeto no es nulo, reduciendo así posibles errores de ejecució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.
El ResponseCallback
actúa como enlace de datos entre el interactor y el presentador, mediante la venta de métodos como:
interface ResponseCallback {
fun onFavoritesResponse(favoriteList: List<Favorite>)
}
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.
En una arquitectura bien definida, es esencial cumplir con el principio de responsabilidad única. Cada capa tiene su papel definido:
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!
Aportes 16
Preguntas 1
En kotlin podemos usar el lateinit para instanciar la variable despues y no inicializarla nula
private lateinit var homePresenter: HomeContract.Presenter
Luego en el onViewCreated se puede instanciar
homePresenter = HomePresenter(this)
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
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:
retrieveFavoriteTransferFromCache( callback: (List<FavoriteTransfer>)->(Unit) )
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
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
parentesis? 3:32
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.
Buena explicación
para no crear un objeto vacio y luego que me diera error on picasso hice lo siguiente
override fun getItemCount(): Int {
var size = 0;
try {
size = favoriteTransferItems.size
}catch (e:Exception){
e.printStackTrace()
return 0
}
return size
}```
La explicacion IMPECABLE.
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)
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?