Android Broadcast Receiver vs Service [duplicate]

Answer 1

Broadcast Receiver

Quoting Dianne Hackborn on the Android Developers blog:

When handling a broadcast, the application is given a fixed set of time (currently 10 seconds) in which to do its work. If it doesn't complete in that time, the application is considered to be misbehaving, and its process immediately tossed into the background state to be killed for memory if needed.

Broadcast receivers are limited by maximum amount of time(10 seconds generally), they have to finish.

Service

If your action takes some longer time (connecting to the internet can take some).More preferrably as the run at background. You definitely should call a service from the receiver or Activity for this purpose. They are last to be killed by android Operating System.

Conclusion:

1. Generally speaking all the work (fetching, parsing, caching, updating database) which is important to your application should be moved to Service as they are long lived on Android. As you've almost considered that all the social networking sites have there STICKY_SERVICES which does all troublesome work.

2. BroadcastReceiver are mostly used to start the service. It generally depends upon application. Most of the application uses ConnectivityManager to broadcast whenever network is UP OR DOWN. With the help of these Service are started by BroadcastReceiver.

Answer 2

First, read the documentation for both Broadcast Receiver and Services.

You can find useful tutorials here and here.

at last, to make the long story short:

Service starts upon your request (startService(intent)). You can think of The Broadcast receiver as an intent listener.

Answer 3

Services are meant to perform an action in the background for some period of time, regardless of what the user is doing in foreground (the user could be switching between activities). A good example would be a music player service - the user starts playing music through a music player app but when they exit the app the music keeps playing.

Services are also useful to provide/manage common access to a resource across multiple applications. This is often used for system resources, such as sensors.

Broadcast receivers are meant to respond to an intent (usually one sent by a service or a system event), do something, and be done. An example here might be the user touches an NFC-enabled phone to a tag, the system creates an intent for it, and a registered receiver handles it to change some settings (change volume, turn on bluetooth, etc).

When an intent is broadcast via sendBroadcast, it will be sent to all receivers that have matching intent filters. However, it is important to note that in API26+ most receivers registered in the manifest are no longer invoked in such situations, see the Google docs for more information.

---

Example 1: Suppose you want to expose a function (to be available from any application that wants to use it) that asks a website to calculate degrees of separation from Kevin Bacon.

Note that this example is "do something and return", as opposed to perform a long-running background operation.

You could implement this in several ways:

Create a library project that all users compile into their application.

• There are now multiple copies of your code and they could all be different versions.
• You could not batch or cache requests as each request is handled independently.

Create a broadcast receiver to handle each request.

• Your application registers a broadcast receiver to accept an Intent asking the Bacon question
• Each application sends an Intent to ask the question.
• The broadcast receiver accepts the Intent and either
  • Passes the request to a service to do the processing, which sends an Intent to the requester with the result
  • Sends a request to the server which will respond using Google Cloud Messaging when it's done
• Because all requests go through one application, you can batch/cache results
• This is always asynchronous
• API is "Intents" - not the friendliest way to expose your functionality

Create a service to handle each request

• Your application creates a service to handle the requests, and exposes an API via a Binder or using AIDL
• The API can be synchronous (direct call and return) or asynchronous (allow listener registration and call the listener when the result is ready). You should only choose synchronous if the processing is expected to be very quick; server calls should more often be handled asynchronously
• API is "method calls" - a much friendlier way to expose functionality

---

Example 2: You want to perform some data analysis to find some patterns in your data

Background Thread If all processing should happen while the user is in the same application and on the same Activity, a background thread (or an AsyncTask that manages a background thread) would be a good approach

Service If you want to allow the user to exit the application while the processing is being performed (and notify them of the results later), or allow them to progress through multiple activities in the same application while the processing is being performed, a Service would be a better approach