android - que - rxjava single example

¿Por qué debería uno considerar usar AndroidObservables en RxJava?

Question

Según entiendo, AndroidObservable ayuda a garantizar que:

1. un suscriptor siempre observa en el hilo principal
2. cuando un fragmento / actividad se separa / detiene, la observación se detiene de inmediato y los componentes relacionados con el marco (como las vistas de texto ui, etc.) no se actualizan.

Sin embargo, para garantizar que el contexto se libere (evitando fugas), la mayoría de los ejemplos que veo normalmente dicen que tiene que hacer una .unsubscribe onDestroyView / onDestroy. .

Así que mi pregunta es:

¿Hay alguna otra ventaja de usar AndroidObservables, si indico manualmente que la suscripción debería ocurrir en el hilo principal, por medio de .observeOn (AndroidSchedulers.mainThread ()?

¿Hay alguna diferencia en los dos enfoques a continuación?

_subscription1 = AndroidObservable.bindFragment(MyFragment.this, myCustomAwesomeObservable()) //
.subscribeOn(Schedulers.io()) //
.subscribe(...);
_subscription2 = myCustomAwesomeObservable()
.subscribeOn(Schedulers.io()) //
.observeOn(AndroidSchedulers.mainThread()) //
.subscribe(...);
@Override
public void onDestroyView() {
_subscription1.unsubscribe();
_subscription2.unsubscribe();
super.onDestroyView();
}

Answer 1

Tienes razón. Lo que hace AndroidObservable.bindFragment actualmente es:

Este ayudante programará la secuencia dada para que se observe en el hilo principal de la IU y se asegurará de que no se reenviarán notificaciones a la actividad en caso de que esté programada para finalizar.

- parte del comentario del código fuente

Entonces, realmente no hace una diferencia en cuál de las implementaciones utiliza.

Pero, aún así, es una buena idea usar AndroidObservable, ya que se podrían agregar funcionalidades adicionales en el futuro.

Answer 2

Ya no existe desde la versión 1.0 de RxAndroid. Supongo que se podría decir que está en desuso o descontinuado. No creo que sea una buena idea usar esto más.