EventBus vs Callbacks, da utilizzare quando?

Question

Ho molte attività che sollevano attività in background; le attività passeranno come se fossero state implementate una callback listener, in modo che le attività in background possano generare un evento nelle attività. Le attività a loro volta possono mostrare qualcosa nell'interfaccia utente per indicare che un'attività in background è stata superata o non è riuscita.

In alternativa, potrei usare uno EventBus, in cui ottengo l'attività di registrarsi come listener/subscriber. Posso avere un'attività in background per aumentare un evento sull'EventBus e l'attività che lo ascolta può gestirlo.

Quali sono i vantaggi di uno rispetto all'altro? Quando useresti l'uno sull'altro? (Codice pulizia? Performance? Caveats?)

---

Follow-up: ho finito con l'uso di EventBus. Il codice è decisamente molto più pulito e non ci sono callback appesi ovunque. L'IDE (IntelliJ) pensa che i metodi onEvent sono inutilizzati, così ho creato un'annotazione

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

e lo mise sopra le mie onEvent metodi. Quindi Alt + fatto clic su di esso e ha chiesto a IntelliJ di non trattarlo come non utilizzato.

@EventBusHook 
public void onEvent(MyEventType myEventType){ 

Answer 1

vantaggi di utilizzare EventBus:

• il codice sarà molto più pulito
• il codice diventerà più modulare che vi permetterà di creare facilmente banco di prova per il vostro codice
• Evitare perdite di memoria da riferimenti agli oggetti cattivi che bloccano l'oggetto e non consentono a Garbage Collector di pulirlo
• Potrebbe avere più di un ricevitore per volta, che è molto simile a broadcasti ng
• Semplifica più interfacce in una singola, EventBus
• In una classe di interfaccia, è necessario eseguire l'override di ogni singolo metodo nella classe che viene ereditata. Con EventBus puoi ascoltare solo un evento che desideri veramente

Ma la parte peggiore è che potresti essere un po 'più mal di testa con la dichiarazione di funzione dato che IDE non può aiutarti con il completamento automatico.

Il mio suggerimento è, se si scopre che è necessario creare un listener personalizzato, quindi si prega di considerare EventBus, potrebbe essere una scelta migliore per la maggior parte (se non tutti) dei vostri requisiti/casi.

In ogni caso, è tutta la vostra scelta dopo tutti =)

Answer 2

sono d'accordo con la risposta di @ nnuneoi.

Il bus eventi ha un solo vantaggio: consente la comunicazione tra componenti che sono "inconsapevoli" della propria esistenza.

E ci sono diversi svantaggi:

1. I componenti diventano debolmente accoppiati da dipendere il sia bus evento e specifico tipo di evento
2. Il giunto descritto sopra # 1 non è forte
3. L'accoppiamento descritto in # 1 sopra non è evidente
4. Il bus eventi introduce un sovraccarico delle prestazioni su semplici callback
5. Se il bus eventi contiene un forte riferimento agli abbonati (come è il caso con ad es. GreenRobot's EventBus), quindi gli abbonati non registrati causeranno perdite di memoria

Considerati tutti questi svantaggi, semplici callback dovrebbe essere la scelta implementazione di default.

Il bus eventi deve essere utilizzato solo quando l'accoppiamento diretto non è desiderato o difficile da implementare. Ad esempio:

1. Invio Eventi Dal Service a Activity
2. Cambio eventi tra eventi a livello indipendente Fragments
3. applicazione (es login/logout)

Se i componenti comunicanti sono già "consapevole "l'uno dell'altro, non c'è bisogno che comunichino tramite il bus degli eventi.

Answer 3

È necessario verificare se il proprio evento è globalmente univoco nella visualizzazione semantica. O un iscritto è interessato all'evento o no. Altrimenti non dovrebbe iscriversi.

Il meccanismo Event-Bus è corretto se si dispone di una relazione tra abbonato editore. L'evento deve essere totalmente indipendente dal ricevitore.

Quindi un abbonato che scarta l'evento per qualsiasi motivo di responsabilità ("Non sono responsabile dell'evento anche se sono registrato") è un forte indicatore che l'uso di un Event-Bus è sbagliato. Quindi dovresti considerare l'utilizzo di ascoltatori dedicati.