green - eventbus android fragment

EventBus vs Callbacks, que usar cuando?

Question

Tengo muchas actividades que plantean tareas de fondo; Las Actividades se pasarán como si hubieran implementado una devolución de llamada del oyente, de modo que las tareas en segundo plano puedan generar un evento en las Actividades. Las actividades, a su vez, pueden mostrar algo en la interfaz de usuario para indicar que una actividad en segundo plano pasó o falló.

Alternativamente, podría usar un EventBus , donde obtengo la Actividad para registrarme como un oyente / suscriptor. Puedo hacer que una tarea en segundo plano genere un evento en EventBus y la Actividad que lo escucha puede manejarlo.

¿Cuáles son las ventajas de uno sobre el otro? ¿Cuándo usarías uno sobre el otro? (¿Código de limpieza? ¿Rendimiento? ¿Advertencias?)

Seguimiento - Terminé usando EventBus. El código es definitivamente mucho más limpio y no hay devoluciones de llamadas en todas partes. El IDE (IntelliJ) cree que los métodos onEvent no se utilizan, por lo que creé una anotación

@Target({ElementType.METHOD})
public @interface EventBusHook {}

y lo puse sobre mis métodos onEvent . Luego Alt + Hizo clic en él y le pidió a IntelliJ que no lo tratara como no utilizado.

@EventBusHook
public void onEvent(MyEventType myEventType){

Answer 1

Beneficios de utilizar EventBus:

• Tu código se verá mucho más limpio
• Su código será más modular, lo que le permitirá crear fácilmente un caso de prueba para su código
• Evite las pérdidas de memoria de referencias de objetos incorrectos que bloquean el objeto y no permiten que Garbage Collector lo limpie
• Podría tener más de un receptor a la vez, lo que se parece mucho a la transmisión
• Simplifique múltiples interfaces en una sola, EventBus
• En una clase de interfaz, debe anular todos los métodos de la clase que se hereda. Con EventBus, puede escuchar solo un evento que realmente desee

Pero lo malo es que podría tener un poco más de dolor de cabeza con la declaración de la función ya que IDE no pudo ayudarlo a completar automáticamente.

Mi sugerencia es que, si encuentra que tiene que crear un escucha personalizado, entonces considere EventBus, podría ser una mejor opción para la mayoría (si no todos) de sus requisitos / casos.

De todos modos, es toda su elección después de todo =)

Answer 2

Debe verificar si su evento es globalmente único en la vista semántica. O un suscriptor está interesado en el evento o no. Si no, no debería suscribirse.

El mecanismo Event-Bus es correcto si realmente tiene una relación editor-suscriptor. El evento debe ser totalmente independiente del receptor.

Por lo tanto, un suscriptor que descarte el evento por cualquier motivo de responsabilidad ("No soy responsable del evento, incluso si estoy registrado") es un indicador claro de que usar un Event-Bus es incorrecto. Entonces deberías considerar usar oyentes dedicados.

Answer 3

No estoy de acuerdo con la respuesta de @nnuneoi.

El bus de eventos tiene una sola ventaja: permite la comunicación entre componentes que "desconocen" la existencia del otro.

Y hay varias desventajas:

1. Los componentes se acoplan libremente por la dependencia tanto del bus de eventos como del tipo de evento específico
2. El acoplamiento descrito en el # 1 anterior no es fuerte
3. El acoplamiento descrito en el # 1 anterior no es evidente.
4. El bus de eventos introduce la sobrecarga de rendimiento a través de devoluciones de llamada simples
5. Si el bus de eventos contiene una fuerte referencia a los suscriptores (como en el caso de EventBus de GreenRobot ), los suscriptores no registrados causarán pérdidas de memoria

Dadas todas estas desventajas, las devoluciones de llamada simples deben ser la opción de implementación predeterminada.

El bus de eventos debe usarse solo cuando el acoplamiento directo no es deseado o difícil de implementar. Por ejemplo:

1. Enviando eventos de Service a Activity
2. Intercambiar eventos entre Fragments independientes.
3. Eventos de toda la aplicación (por ejemplo, inicio / cierre de sesión del usuario)

Si los componentes que se comunican ya están "conscientes" de la existencia de cada uno, no hay necesidad de que se comuniquen a través del bus de eventos.