Narrow Receivers

In the examples shown previously, the intent filters were set up on activities. Sometimes, tying intents to activities is not exactly what we want:

• Some system events might cause us to want to trigger something in a service rather than an activity.

• Some events might need to launch different activities in different circumstances, where the criteria are not solely based on the intent itself, but some other state (e.g., if we get intent X and the database has a Y, then launch activity M; if the database does not have a Y, then launch activity N).

For these cases, Android offers the intent receiver, defined as a class implementing the interface. Intent receivers are disposable objects designed to receive intents – particularly broadcast intents – and take action, typically involving launching other intents to trigger logic in an activity, service, or other component.

The interface has only one method: . Intent receivers implement that method, where they do whatever it is they wish to do upon an incoming intent. To declare an intent receiver, add a receiver element to your file:

An intent receiver is only alive for as long as it takes to process – as soon as that method returns, the receiver instance is subject to garbage collection and will not be reused. This means intent receivers are somewhat limited in what they can do, mostly to avoid anything that involves any sort of callback. For example, they cannot bind to a service, and they cannot open a dialog box.

The exception is if the is implemented on some longer‑lived component, such as an activity or service – in that case, the intent receiver lives as long as its “host” does (e.g., until the activity is frozen). However, in this case, you cannot declare the intent receiver via . Instead, you need to call on your ’s callback to declare interest in an intent, then call from your ’s when you no longer need those intents.