For instance, I need a BroadcastReceiver to get these events:
REBOOT or SHUTDOWN
SCREEN ON or OFF
battery status (voltage, plugged in, temperature)
The major difference can be that:
Event Listeneres are of more continuous form i.e. the events such as related to sensors or button clicks are more often.
But receiver is of a discontinuous nature, i.e. the events here are not so of a continuous nature for example, Boot on/off, message etc
Broad Cast Receiver is like Sigma and Event Listener is like Integration in mathematics both are summation ...
In the same way both Broad Cast Receiver and Event Listener are used for Event Listening.But Broad Cast receiver is used for listening the very important events like BATTERY_CHANGED,BATTERY_LOW,BOOT_COMPLETED,CALL ETC and Event Lister updates Continuous changes in the event like LOCATION CHANGED,FOCUS GAINED ETC.
There are so many differences between these two, them responding to something is one of the only similarities.
Differences:
BroadcastReceivers receive Intents whereas a Listener can do basically anything, since it does not have a defined purpose, it's just a naming convention. Eg, search for "BroadcastReceiver" on the dev website then search for "Listener"
BroadcastReceivers just receive an Intent Broadcast which is non-direct, Listeners get called explicitly.
A BroadcastReceiver is its own defined class since it has a definite purpose (receiving Intents) whereas Listeners can be anything - they're usually an interface
and they are provided so that callbacks can be made from one class to another.
BroadcastReceivers are usually used for global, system-wide events, Listeners for specific events (ie a Location sensor shouldn't give location updates every second unless it has something, such as a Listener to publish to. Contrasted with a screen-off intent - this is important, it affects everything, and so should be broadcast to all interested Receivers)
Events a BroadcastReceiver picks up are usually non-continuous events (one shot), whereas Listeners, depending on what they do, can be used for constant updates (continuous).
BroadcastReceivers can be instantiated by the system if they're declared in the manifest, Listeners are only dynamically made (so via code).
CPU/Power usage depends on implementation of both, especially since as mentioned, Listeners can be anything.
Are there things I can do in one but not the other, especially in regards to things like how much CPU I can take and running while the screen is off?
BroadcastReceivers only have 10 seconds of guaranteed execution time. Listeners, since they don't serve a specific purpose, don't have this limit.
What you definitely can't do from a BroadcastReceiver:
In particular, you may not show a dialog or bind to a service from within a BroadcastReceiver.
There are probably more - this is what I came up with.
Both Listeners and Receivers act as trigger handlers, however, it is the origin and characteristics of these triggers that separates them.
(Broadcast) Receivers are triggered by Intents. The origin of these Intents can come from outside the context of your own application. Thus, it is a way for applications to implement Inter-Process Communication.
In addition, applications do not need to be running to receive Intents. Intents can act as an alarm clock to wake applications up when an event has been triggered. This saves battery and cpu.