Broadcast Receiver e ResultReceiver in Android

Question

Qual è la differenza tra BroadcastReceiver e ResultReceiver in Android?

Answer 1

Ricevitore Risultato:

Generic interface for receiving a callback result from someone. 

Broadcast Receiver:

Base class for code that will receive intents sent by sendBroadcast(). 

EDIT:

Background: Tutte le operazioni di rete/lungo operazioni in esecuzione dovrebbe avvenire lontano dal thread principale. Due modi per farlo:

1. compito Async - Per Semplice networking come dire prelevare un'immagine/fare db elaborazione
2. Servizio - Per lunga esecuzione complesso processo in background

Se è necessario eseguire funziona al di fuori del thread principale, ma solo mentre l'utente sta interagendo con la tua applicazione, probabilmente dovresti invece creare un nuovo thread e non un servizio. Ad esempio, se vuoi riprodurre della musica, ma solo mentre la tua attività è in esecuzione, potresti creare una discussione asincrona. Ma se si desidera che il processo di continuare anche dopo che l'utente esce l'applicazione (diciamo un download) quindi utilizzare un servizio

Diciamo che si sceglie 2. Ora

1. attività ti invia una richiesta Web al tuo servizio
2. Il servizio esegue tale operazione utilizzando say DefaultHttpClient

3. Invia dati alla tua attività.

   Il terzo passo di ricevere dati qui può essere fatto in due modi

1.) ricevitore broadcast: ricevitori multipli possono ricevere i dati. Utilizzato se si desidera inviare dati/notifiche tra applicazioni (ad esempio, si sta interagendo anche con fb e twitter, più ricevitori per la trasmissione Web), ogni volta che si invia broadcast al sistema inviato.

2.) Ricevitore del risultato: l'applicazione è l'unico ricevitore dei dati. È un'interfaccia implementata e passata all'intenService tramite putExtra. IntentService preleverà questo oggetto e chiamerà la sua funzione receiver.send per inviare qualsiasi cosa (in bundle) all'attività di chiamata .Ricevitore risultato ha preferenza su riceventi per la radiodiffusione se il vostro tutta la comunicazione è interna alla propria applicazione

EDIT: Vorrei anche ricordare questa precauzione

Attenzione: Un servizio viene eseguito nel thread principale di il suo processo di hosting: il servizio non crea il proprio thread e non viene eseguito in un processo separato (se non diversamente specificato). Ciò significa che, se il vostro servizio sta per fare qualsiasi lavoro intensivo della CPU o bloccando le operazioni (come ad esempio la riproduzione di MP3 o di rete), è necessario creare un nuovo thread all'interno del servizio per fare quel lavoro. Utilizzando un thread separato, si sarà ridurre il rischio di applicazione non risponde errori (ANR) e thread principale dell'applicazione può rimanere dedicato all'interazione dell'utente con le vostre attività.

Answer 2

Queste due classi sono completamente diverse. In realtà è proprio la stessa differenza che tra Broadcast e Risultato.

• cosa trasmette? In parole semplici è un messaggio che è visibile all'intero sistema e può essere consumato da ogni parte del sistema (che conosce il contratto), non è stato creato da smb reuest;
• qual è il risultato? È qualcosa che ci aspettiamo di ricevere da un'altra parte del sistema. Di solito c'è un solo ricevitore per il risultato e di solito quel ricevitore ha richiesto l'elaborazione per ottenere il risultato (sentire la differenza - per la trasmissione nessuno ha bisogno di fare alcuna "richiesta" per lasciarla originata);

Questa era una spiegazione dal punto di vista logico. Dal punto di vista del codice, se dovessi confrontare BroadcastReceiver e ResultReceiver, potresti osservare un'enorme differenza. Fondamentalmente entrambe le classi sono basate su IPC ma BroadcastReceiver è molto più complesso a causa della sua natura diversa (che ho cercato di spiegare nella prima parte).

Answer 3

Un BroadcastReceiver è un ricevitore ricezione di trasmissioni. Quelli sono inviati da qualcuno nell'intenzione che ci possano essere molti ricevitori che li ricevono (come le trasmissioni radio).

A ResultReceiver d'altra parte è destinato a ricevere un risultato richiamata da una persona. Quindi questo potrebbe essere paragonato a un walkie-talkie, in cui chiami qualcuno e poi riceverai una risposta (un risultato) da quello che hai chiamato.

Answer 4

Broadcast Receiver

Un ricevitore di broadcast è un componente che risponde agli annunci di trasmissione a livello di sistema. Ad esempio, una trasmissione che annuncia che lo schermo è spento, la batteria è scarica o è stata scattata una foto. Le applicazioni possono anche avviare le trasmissioni, ad esempio per consentire ad altre applicazioni di sapere che alcuni dati sono stati scaricati sul dispositivo ed è disponibile per essere utilizzati. Sebbene i ricevitori di broadcast non visualizzino un'interfaccia utente, possono creare una notifica sulla barra di stato per avvisare l'utente quando si verifica un evento di trasmissione. Inoltre, un ricevitore broadcast è solo un "gateway" per altri componenti e ha lo scopo di eseguire una quantità minima di lavoro. Ad esempio, potrebbe avviare un servizio per eseguire alcuni lavori in base all'evento.

ricevitore Risultato

Se il servizio sta per essere parte di te applicazione allora si stanno facendo è molto più complesso di quello che deve essere. Poiché si dispone di un semplice caso di utilizzo di alcuni dati da un servizio Web riposante, è necessario esaminare ResultReceiver e IntentService.

Questo modello Service + ResultReceiver funziona avviando o vincolando il servizio con startService() quando si desidera eseguire un'azione. È possibile specificare l'operazione da eseguire e inoltrare nel ResultReceiver (l'attività) tramite gli extra nell'Intento.