Patrón Observer en Android: Implementación y Uso Práctico

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

Ciclo de Vida de Una Actividad

O pueden verlo mas detallado aquí 😉

Los eventos del observable deberían delegarse al Presenterya que a la vista (fragment o activity) no debe tener conocimiento de esta lógica. Cuando se observe un cambio, este se notifica a la vista a través del mismo Presenter.

El reto implementado en Dart:

abstract class Observer<T> {
  void notifyChange(T newValue) {}
}

abstract class Observable<T> {
  void addObserver(Observer<T> observer) {}
  void removeObserver(Observer<T> observer) {}
  void notifyObservers(T newValue) {}
}

class AvailableBalanceObservable implements Observable<double> {
  final List<Observer> _observerList = [];
  double _amount = 0.0;

  void changeAmount(double newValue) {
    _amount = newValue;
    notifyObservers(_amount);
  }

  @override
  void addObserver(Observer observer) {
    _observerList.add(observer);
  }

  @override
  void removeObserver(Observer observer) {
    _observerList.remove(observer);
  }

  @override
  void notifyObservers(double newValue) {
    for (var observer in _observerList) {
      observer.notifyChange(newValue);
    }
  }
}

Es muy importante tener en cuenta que estas dos interfaces tienen una continua comunicacion en andorid nuestras activities tienen un ciclo de vida volatil (el OS destruye actividades que estan en segundo plano para optimizar recursos)al momento de llamar al metodo onDestroy es una muy buena practica desuscribirme de todos los eventos de ese observable.

No que la Vista se comunicaba con el Presentador y este con el Observable ? En este ejemplo se saltaron el Presenter jajaja

En este curso el docente ha explicado conceptos que en cursos anteriores fueron asumidos como ya conocidos por los estudiantes, lo cual fue un error, debido a que el curso se hacia confuso. Era como leer un libro sin conocer el idioma en el que está escrito.
El curso me ha sido de gran ayuda.

“$ $newValue” el primer simbolo de dolar es string para mostrarlo el segundo para mostrar el valor de la variable

Buenas practicas