greenrobot - eventbus android gradle

¿Qué métodos de ciclo de vida de actividad son los mejores para registrar/anular el registro en el bus de eventos?

Question

¿Cuál es el mejor lugar para registrarse y anular el registro en un bus de eventos (como otto, EventBus o tinybus) en una actividad y por qué?

1. onCreate () - onDestroy ()
2. onStart () - onStop ()
3. onResume () - onPause ()

El ejemplo de Otto usa onResume () - onPause (), EventBus menciona onStart () - onStop (), y necesitábamos usar onCreate () - onDestroy () en nuestra aplicación para actualizar la IU de la actividad incluso cuando estaba en segundo plano. Así que supongo que puede ser cualquiera de los tres dependiendo de la naturaleza de los eventos y su manejo, pero me preguntaba si hay algo más que debería ser considerado.

Answer 1

Formulario Documentation EventBus que encontré y funciona bien para mí:

@Override
 public void onStart() {
     super.onStart();
     EventBus.getDefault().register(this);
 }

 @Override
 public void onStop() {
     super.onStop();
     EventBus.getDefault().unregister(this);
 }

Y si necesita enviar la referencia de EventBus al niño, entonces:

private EventBus eventBus = EventBus.getDefault();
@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        .......
}

@Override
public void onStart() {
    super.onStart();
    if(!eventBus.isRegistered(this)){
        eventBus.register(this);
    }else{
        Log.e(TAG, "EventBus is registered");
    }
}

@Override
public void onStop() {
    super.onStop();
    if(eventBus.isRegistered(this)){
       eventBus.unregister(this);
    }else{
       Log.e(TAG, "EventBus is not registered");
    }
}

Answer 2

@levavare, creo que la hora correcta para registrarse / cancelar el registro depende de sus eventos y de lo que pretende hacer con ellos. Y puede ser diferente para diferentes eventos dentro de la misma aplicación.

Por ejemplo, estoy usando EventBus en una aplicación de Android que monitorea un dispositivo de registro de datos en tiempo real (Arduino, en este caso) a través de Bluetooth. Tengo dos tipos de eventos muy diferentes.

Mi código de Bluetooth publica el primer evento para notificar a uno de mis fragmentos que se ha recibido un nuevo conjunto de lecturas del instrumento desde el dispositivo. Ese fragmento luego los escribe en una tabla de base de datos. Es importante que el evento siempre sea escuchado y actuado. El fragmento se registra / anula el registro en sus métodos OnCreate / OnDestroy. También me suscribo para ese evento con prioridad elevada.

El otro evento es publicado por la capa de base de datos cuando el nuevo registro se agrega a la base de datos. Tengo una serie de fragmentos que muestran diferentes subconjuntos de las lecturas (temperaturas, presiones, condiciones de alarma). Cuando se visualice uno de esos fragmentos, debería actualizarse tan pronto como la nueva lectura esté en la base de datos. Pero cuando el fragmento está fuera de la vista, no hay razón para que actúe en una lectura. Tengo esos fragmentos de registro / anulación de registro en OnStart / OnStop. Iba a hacer ese trabajo en OnResume / OnPause y, francamente, creo que funcionaría tan bien allí para mi aplicación. Pero la respuesta y el enlace de @Jordy me convencieron de ir con OnStart / OnStop en su lugar.

Answer 3

Eliminé mi comentario en la respuesta anterior que sería mejor registrarse / cancelar el registro en onresume / onpause. Obtuve un caso de uso extraño donde algunos si mis eventos no llegaban al suscriptor anotado. Parece que la mejor manera es usar onstart / onstop. Aquí hay una buena publicación de SO que explica por qué:

https://.com/a/19737191/2361947

Answer 4

En primer lugar, no es una pregunta objetiva sino que es subjetiva y generará muchos argumentos basados ​​en argumentos.

Desde mi experiencia, usamos Otto en uno de nuestros proyectos. Seguimos onResume () - onPause () que nos sirvió muy bien. También tiene sentido porque deberíamos registrarnos lo más tarde posible y cancelar el registro lo más rápido posible mientras usamos un bus de eventos.