Question

What is difference between BroadcastReceiver and ResultReceiver in android?

Answer 1

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.