¿Qué métodos de ciclo de vida de actividad son los mejores para registrar / anular el registro en el bus de eventos?
¿Cuál es el mejor lugar para registrar y anular el registro en un bus de eventos (como otto, EventBus o tinybus) en una Actividad y por qué?
- OnCreate () – onDestroy ()
- OnStart () – onStop ()
- OnResume () – onPause ()
El ejemplo de Otto usa onResume () – onPause (), las menciones de EventBus onStart () – onStop (), y necesitamos usar onCreate () – onDestroy () en nuestra aplicación para actualizar la UI 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 debe ser considerado.
- Utilizar Intents o un bus de eventos para comunicarse dentro de la misma aplicación
- ¿Cómo enviar un evento de Servicio a Actividad con el bus de eventos Otto?
- NullPointerException con Otto y Dagger
- Mejores Prácticas para el Manejo de la Búsqueda
- Utilizar Otto para actualizar un listadapter de un GcmListenerService
- Problema de suscripción de bus de eventos (bus de eventos Otto - Guava)
- Informe Leakcanary de pérdida de memoria usando Otto
- @Subscribe método llamado tiempo múltiple para el mismo evento
- Reducción del número de clases de eventos al utilizar EventBus o Otto
- Issue Suscribiéndose a / Receiving Otto Event Publicado desde IntentService
- IllegalArgumentException cuando se utiliza Otto con un fragmento retenido
- ClassNotFoundException: No encontró la clase "android.os.PersistableBundle" Otto Android 5.0
- Android Event Bus Alternative
@levavare, creo que la hora correcta para registrar / anular el registro depende de tus eventos y de lo que piensas hacer con ellos. Y puede ser diferente para diferentes eventos dentro de la misma aplicación.
Por ejemplo, estoy utilizando EventBus en una aplicación de Android que supervisa un dispositivo de registro de datos en tiempo real (Arduino, en este caso) a través de Bluetooth. Tengo dos tipos muy diferentes de eventos.
El primer evento es publicado por mi código Bluetooth para notificar a uno de mis fragmentos que se ha recibido un nuevo conjunto de lecturas de instrumentos desde el dispositivo. Ese fragmento los escribe en una tabla de base de datos. Es importante que el evento sea siempre escuchado y actuado. El fragmento registra / anula el registro en sus métodos OnCreate / OnDestroy. También me suscribo para ese evento con alta prioridad.
El otro evento es publicado por la capa de base de datos cuando se agrega el nuevo registro a la base de datos. Tengo una serie de fragmentos que muestran diferentes subconjuntos de las lecturas (temperaturas, presiones, condiciones de alarma). Cuando se está viendo uno de esos fragmentos debe 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 sobre una lectura. Tengo esos fragmentos registrar / cancelar el registro en OnStart / OnStop. Iba a hacer ese trabajo en OnResume / OnPause y, francamente, creo que funcionaría también para mi aplicación. Pero @ Jordy respuesta y enlace me convenció de ir con OnStart / OnStop en su lugar.
En primer lugar, no es una cuestión objetiva, sino una cuestión subjetiva y extraerá muchos argumentos basados en argumentos.
De mi experiencia, utilizamos Otto en uno de nuestros proyectos. Seguimos onResume () – onPause () que nos sirvió muy bien. También tiene sentido porque debemos registrarse tan tarde como sea posible y cancelar el registro lo más rápido posible mientras se utiliza un bus de eventos.
Quité mi comentario en la respuesta anterior que sería mejor registrar / anular el registro en onresume / onpause. Tengo una extraña usecase donde algunos si mis eventos werent llegar al suscriptor anotado. Parece que la mejor manera es usar el onstart / onstop. Aquí está un buen post SO explicando por qué:
- Obtener nombre de archivo después de que el filereader cargue asincrónicamente un archivo
- Android: incluye un xml en otro xml