10

Ho implementato un servizio, dove gestisco le modifiche di stato (connessione, disconnessione, onServiceDiscoverd, onCharacteristicChange ecc.) E la ricezione di dati da un altro dispositivo tramite gatt Server.È consigliabile sostituire il ricevitore di trasmissione con Greenrobot Eventbus per attivare le funzioni basate sugli eventi e il trasferimento dei dati dal servizio all'attività?

La mia domanda è, gli eventi possono essere gestiti in modo efficiente utilizzando GreenRobot EventBus sostituzione del ricevitore di broadcast tra servizio e attività?

+0

Non ho usato Greenrobot Event ma non posso commentare in merito. Ma in generale, se la comunicazione è tra attività e servizio dello stesso processo, è meglio usare LocalBroadcastManager piuttosto che BroadcastReceiver. – kmaini

+0

@kmaini c'è qualche esempio o collegamento che hai trovato utile per te? –

risposta

7

differenza LocalBroadcastManager, EventBus è più semplice da usare. Si passa solo tramite 3 passaggi:

1- Creare una classe di evento. Una semplice classe Java che rappresenta la risposta quando si verifica l'azione .

2- registrare il bus evento come un abbonato nella vostra attività onCreate metodo

EventBus.getDefault().register(this); 

E, naturalmente, annullare la registrazione nella vostra attività OnDestroy metodo

EventBus.getDefault().unregister(this); 

3- Viene creato il metodo di sottoscrizione nella stessa attività registrata per l'EventBus. Esempio in WorkOrderActivity

@Subscribe 
    public void onEvent(EventClass event) 

Quando si verificano l'evento, si deve chiamare il metodo post, passando l'oggetto evento creato prima.

EventBus.getDefault().post(new EventClass (Data)); 

Come kmaini detto, è possibile sostituirlo con LocalBroadcastManager, ma si dovrà mappare i dati l'intento da soli. A differenza di EventBus che può passare oggetti.

Inoltre, GreenRobot, i creatori di EventBus Biblioteca, risposto a questa domanda here:

D: Come è diverso da EventBus/Intent sistema di Android BroadcastReceiver ?

A: A differenza del sistema BroadcastReceiver/Intent di Android, EventBus utilizza le classi Java standard come eventi e offre un'API più conveniente. EventBus è destinato a molti altri casi di utilizzo in cui non si desidera passare senza problemi di impostazione di Intenti, preparazione di Intenti extra, implementazione di ricevitori broadcast ed estrazione di Intenti extra. Inoltre, EventBus ha un overhead molto più basso.

2

ecco il link che ho seguito per l'attuazione LocalBroadcast:

https://stackoverflow.com/a/8875292/4406743

Ecco riassunto della mia realizzazione:

Nell'attività di ricezione o dei servizi:

1) Registrati per locali braodcast (di solito in onCreate):

LocalBroadcastManager.getInstance(this).registerReceiver(
     mMessageReceiver, new IntentFilter("broacast_name")); 

2) Annullare la registrazione per broadast locale (di solito OnDestroy):

LocalBroadcastManager.getInstance(this).unregisterReceiver(mMessageReceiver); 

3) Definire ricevitore trasmissione:

private BroadcastReceiver mMessageReceiver = new BroadcastReceiver() { 
      @Override 
      public void onReceive(Context context, Intent intent) { 
         //Handle local broadcast 
      } 
}; 

Nell'attività o il servizio di invio:

Intent it = new Intent("broacast_name"); 
it.putExtra("data", "value"); 
LocalBroadcastManager.getInstance(context).sendBroadcast(it); 
+0

Il bus degli eventi è carino lib. Rende la codifica molto semplice e disaccoppiata. Vai avanti e usalo. –

0

EventBus rende le cose molto più facile perché si può passare è arbitraria oggetti Java lungo nel event.You non fare lo stesso con Intents perché l'oggetto deve implementare Parcelable e il "noioso" l'attuazione Parcelable che è qualcosa che si potrebbe non cosa fare su un codice esistente.

1

Da un altro punto di vista, credo che i gestori di trasmissione di Android utilizzino la coda messaggi del gestore thread principale per elaborare gli eventi. Quindi, se sei libero di utilizzare un thread diverso (se non hai eventi UI/processi/attività) con una coda appropriata (come l'utilizzo di un altro HandlerThread), puoi sfruttare la coda specifica di quel thread per elaborare i tuoi lavori, senza interferire con gli eventi dell'interfaccia utente e mescolare le tue cose con il lavoro dell'interfaccia utente. Puoi anche giocare con il valore di priorità del filo per bilanciare il lavoro.

Ora, se GreenRobot fornisce tutte le funzionalità in poche righe di codice, proverei sicuramente a vedere eventuali miglioramenti delle prestazioni.