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
