Me propuse como reto hacer lo que dice el profesor: que las interfaces sean genéricas para que nosotros podamos usarla con cualquier tipo de dato. Simplemente fue cuestión de modificarlas de esta manera:
interface Observable2<T> {
fun addObserver(observer: Observer2<T>)
fun removeObserver(observer: Observer2<T>)
fun notifyObservers(newValue: T?)
}
interface Observer2<T> {
fun notifyChange(newValue: T?)
}
También me propuse añadir la funcionalidad de eliminar todos los observers automáticamente cuando el Fragment se destruye, tal y como lo hace LiveData. La clase quedó de esta manera:
class AvailableBalanceObservable<T>(lifecycleOwner: LifecycleOwner) : Observable2<T>
init {
lifecycleOwner.lifecycle.addObserver(object : LifecycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun removeAllObservers() {
amountObserverList.clear()
lifecycleOwner.lifecycle.removeObserver(this)
}
})
}
// Resto del código
}
Un LifecycleOwner es una interfaz que implementan todas las clases que tienen un ciclo de vida, en este caso un Fragment, pero también puede ser una Activity. En mi implementación, al iniciar la clase, se añade un observador al ciclo de vida del Fragment. Cuando el Fragment ejecuta onDestroy(), se eliminan todos los observers de la lista y se elimina el propio observer del ciclo de vida.
Finalmente, para construir la clase, basta con llamarla así:
class HomeFragment : Fragment(), HomeContract.View {
private lateinit var availableBalanceObservable: AvailableBalanceObservable<Double>
// Resto del código...
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
// Resto del código...
availableBalanceObservable = AvailableBalanceObservable(viewLifecycleOwner)
}
}
Con estos dos cambios, la clase tiene más funcionalidades y está más cerca a la implementación de LiveData
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
o inicia sesión.