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
Qué aprenderás sobre patrones de diseño en android
¿Qué es arquitectura?
Tipos de arquitectura en Android
Presentación del proyecto: Platzi Wallet
Patrón de arquitectura MVP
Implementación de MVP en el proyecto
Comunicación entre capas MVP
Creación del loader y resultados de la implementación
Patrón de arquitectura MVVM
Patrones de diseño
Qué es un patrón de diseño y qué tipos existen
Patrones de diseño creacionales
Singleton
Object Singleton
¿Qué es Builder?
Aplicando builder en código
Función Apply en Builder
Factory
Patrones de diseño estructurales
Adapter
Proxy
Facade
Patrones de comportamiento
Observer
Cómo implementar observer en el proyecto
Command
Cómo implementar command en el proyecto
Prueba de ejecución de comandos
Bonus: Architecture Components
Introducción a Architecture Components
LiveData
Introducción a Room y preparación del proyecto
Creación de componentes de Room
Comunicación entre componentes
ViewModel
Bonus: Custom View
Creando Custom Views
Conclusiones
Conclusiones y consejos para seguir aprendiendo
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
No se trata de lo que quieres comprar, sino de quién quieres ser. Invierte en tu educación con el precio especial
Antes: $249
Paga en 4 cuotas sin intereses
Termina en:
Cristian Villamil
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?