29

What is difference between BroadcastReceiver and ResultReceiver in android?

OcuS
  • 5,320
  • 3
  • 36
  • 45
user1670564
  • 391
  • 2
  • 4
  • 12

4 Answers4

38

Result Receiver:

Generic interface for receiving a callback result from someone.

Broadcast Receiver:

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

EDIT:

Background: All networking operations/long running operations should take place away from the main thread. Two ways to do this :

  1. Async task - For Simple networking like say retreive an image/ do db processing
  2. Service - For Complex long running background process

If you need to perform work outside your main thread, but only while the user is interacting with your application, then you should probably instead create a new thread and not a service. For example, if you want to play some music, but only while your activity is running, you might create an Async Thread. But if you want the process to continue even after the user exits the app (say a download) then use a service

Lets say you pick 2. Now

  1. You activity sends a web request to your service

  2. Your service executes that using say DefaultHttpClient

  3. It sends back data to your activity.

    The third step of receiving data here can be done in two ways

1.) Broadcast receiver: Multiple receivers can receive your data. Used if you want to send data/notifications across applications(say you are also interacting with fb and twitter, multiple receivers for your web broadcast), whenever you send broadcast its sent system wide.

2.) Result receiver: Your application is the only receiver of the data. It is an Interface you implement and pass it to the intentService through putExtra. IntentService will then fetch this object and call its receiver.send function to send anything (in bundle) to calling activity. Result receiver has preference over broadcast receivers if your all communication is internal to your application

EDIT: I should also mention this caution

Caution: A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work. By using a separate thread, you will reduce the risk of Application Not Responding (ANR) errors and the application's main thread can remain dedicated to user interaction with your activities.

Community
  • 1
  • 1
Vrashabh Irde
  • 14,129
  • 6
  • 51
  • 103
  • Which one is best for long running networking process? Eg: File downloading, JSON parsing.etc – user1670564 Nov 01 '12 at 13:53
  • Look at the top answer here: http://stackoverflow.com/questions/3197335/restful-api-service to understand the result receiver + service pattern. It gives a really good use case of application – Vrashabh Irde Nov 01 '12 at 13:58
  • Thanks for reply. I gone through the link. Once crossed the link i have doubts in both receivers. Both receiver are supporting long running tasks. At what situation i need to use Broadcast and result. – user1670564 Nov 01 '12 at 14:02
  • Thanks alot..But already am using Service with Broadcast Receiver for some other logic. Again i have the same logic situation to use service within service. If am using more than service, Is application will be slow down? – user1670564 Nov 01 '12 at 14:16
  • All services run on the main application thread so your code must have logic to spawn new threads in the services. As long as this is true multiple services shouldnt impact usability – Vrashabh Irde Nov 01 '12 at 14:30
  • Could you please answer a question. If I need to show the progress of download process in a notification bar lets say, and update it every 1 second so I can see its current progress. Then, is it OK to use the ResultReceiver to send the progress to notification every 1 second? Or should I use in this case a BroadcastReceiver, or it's the same? – Andy Res Jan 21 '13 at 12:12
  • INFO: If you want to avoid the overhead of managing a thread in a service you can use IntentService which managed it for you. – Arun C Jun 28 '15 at 08:18
  • Any difference in performance in receiving data in BroadcastReceiver vs ResultReceiver? – Micro Feb 23 '16 at 04:20
  • And everyone reading this post should see IntentService (As I believe it is a better choice vs Service):http://stackoverflow.com/questions/15524280/service-vs-intentservice – Micro Feb 23 '16 at 04:22
12

A BroadcastReceiver is a receiver receiving broadcasts. Those are sent by someone in the intention that there can be many receivers receiving them (like radio broadcasts).

A ResultReceiver on the other hand is intended to receive a callback result from someone. So this could be compared with a walkie talkie, where you call someone and then are going to receive an answer (a result) from the one you called.

Ridcully
  • 23,362
  • 7
  • 71
  • 86
  • Please be aware that a walkie talkie is technically doing a broadcast to a given RF frequency and can then be heard by several receivers through that RF frequency. I suggest you re-phrase this to instead use a mobile# SIM card instead. And as for the case of `BroadcastReceiver` the best analogy would be those special emergency SMS alerts or a walkie talkie which you confusingly used. – daparic Sep 19 '21 at 16:09
3

These two classes are completely different. It's actually quite the same difference as between Broadcast and Result.

  • what it Broadcast? In simple words it's some message which is visible to whole system and it can be consumed by every part of the system (which knows the contract), it wasn't originated by smb reuest;
  • what is Result? It's something we're expecting to receive from another part of the system. Usually there's only one receiver for result and usually that receiver has requested processing to obtain result (feel the difference - for broadcast nobody needs to do any 'request' to let it originated);

That was explanation from logic point of view. From the code perspective if You would compare BroadcastReceiver and ResultReceiver You could observe huge difference. Basically both classes are built on top of IPC but BroadcastReceiver is much more complex because of it's different nature (which I've tried to explain in first part).

sandrstar
  • 12,503
  • 8
  • 58
  • 65
  • Wheteher both receiver can support Async HTTP request and response? – user1670564 Nov 01 '12 at 13:54
  • hm, I think no, because both are not about HTTP request. If You need, You can send result from Your service or async task using any of them. But for AsyncTask You can use just Handler usually. – sandrstar Nov 01 '12 at 14:14
0

Broadcast Receiver

A broadcast receiver is a component that responds to system-wide broadcast announcements. example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Applications can also initiate broadcasts—for example, to let other applications know that some data has been downloaded to the device and is available for them to use. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event.

Result Receiver

If your service is going to be part of you application then you are making it way more complex than it needs to be. Since you have a simple use case of getting some data from a Restful Web Service, you should look into ResultReceiver and IntentService.

This Service + ResultReceiver pattern works by starting or binding to the service with startService() when you want to do some action. You can specify the operation to perform and pass in your ResultReceiver (the activity) through the extras in the Intent.

Nirav Ranpara
  • 13,753
  • 3
  • 39
  • 54