19

Background

On Android, there are 2 possible ways to listen to system events via BroadcastReceivers :

  • statically, via the manifest
  • programmatically, via the code.

Since some projects contain a lot of activities, services, and "manager"-classes , it could be useful to have a single BroadcastReceiver that will notify all of its listeners on the app about what has happened, instead of having multiple BroadcastReceivers being used (and their code handling).

An example of such a BroadcastReceiver, is the one that listens to the connectivity changes:

@Override
public void onCreate() {
    super.onCreate();
            ...
    registerReceiver(new ConnectivityChangedBroadcastReceiver(), new IntentFilter(
            ConnectivityManager.CONNECTIVITY_ACTION));
            ...
    }

The question

The purpose is to listen to the events while the app is "alive" (by services and/or activities) .

Using the manifest would miss this purpose, as it will wake the app each time the event occurs, even if the app doesn't need it.

Thing is, unregistering doesn't occur, and maybe it causes the OS treat the app in a different way because of it.

Does having a call to "registerReceiver" on the class that extends from Application is a good known practice?

Does it have any side effects and things to know about when using it?

Is there any alternative to this?

I just want to be sure it's considered safe to use.

android developer
  • 114,585
  • 152
  • 739
  • 1,270

1 Answers1

11

we can't really know what is good or better for you.

I advise you to learn more about the difference between the registration ways of the receiver:

1/ in the manifest : the handler of the receiver will be triggered each time that the correspondent event comes. Example: the messenger of facebook is lunched every time that you have internet connection to show you your notifications... or other applications are lunched when you connect to propose updates ... in other words, the receiver is always registered.

2/ in a service or an activity or an application : the receiver will be unregistered when the context of where it is registered is killed. in other words, it depends totally of the context where it is registred , and you are obliged to unregister it somewhere in the code. exemple : one activity is waiting that a service ( which is doing something in the background) sends an alert to update something , then you can register the receiver in your onResume() and unregester it in your onPause().

Conclusion : It depends only in the life-cycle requirement of the receiver.

see also Broadcast Receiver Register in Manifest vs. Activity

Main difference between Manifest and Programmatic registering of BroadcastReceiver

Community
  • 1
  • 1
ahmed_khan_89
  • 2,755
  • 26
  • 49
  • 3
    So is it ok to use it in the class that extends from Application? I didn't see a lot of examples that show this. – android developer Apr 23 '14 at 09:38
  • 4
    yes ! totally safe, you register it with the context of the application. you said that nobody tried it before... in this answer you have a guy registering the broadcast receiver in a singleton class, by passing the application context [http://stackoverflow.com/questions/18283967/broadcastreceiver-in-singleton-class-not-receiving-intents] – ahmed_khan_89 Apr 23 '14 at 10:16
  • 1
    So there are no side effects? maybe the OS will make the process live more time because of this? How about slowing down the onCreate method of the Application class? Does it affect it ? – android developer Apr 23 '14 at 10:22
  • than this is the case of any use of the application class: – ahmed_khan_89 Apr 23 '14 at 10:45
  • Question is, if it slows it down enough to notice. if it's so slow as enabling an application component, maybe it's better to postpone it a bit. – android developer Apr 23 '14 at 10:47
  • It is not making it slower. this is the case of any use of the application class, when you override the onCreate(): 1/ you call the super.onCreate(); then the system is doing what it is uses to do by default. 2/ you add what you want to register and to initialize, after the super. you define it and register it. if you want you can even register it in an activity with the Application Context. (you can also unregister it from an activity): in this case you define in the Application Class (as a normal attribute), and in the activity you register it. – ahmed_khan_89 Apr 23 '14 at 10:54
  • 1
    ok thank you. I just remember that enabling components take some time. wasn't sure about this one. – android developer Apr 23 '14 at 11:19
  • I am using it, and it is ok . as you said "if it slows it down enough to notice" , no I don't notice anything... but then, it belongs to you, what do you think about it ... – ahmed_khan_89 Apr 23 '14 at 12:27
  • 2
    @ahmed_khan_89 I didn't see any way to unregister the broadcast receiver in Application, but I assume it is safe? Since when the Application being GCed, your process is basically killed? – katie May 31 '17 at 19:05
  • @katie yes, I assume so. – ahmed_khan_89 Jan 16 '19 at 10:47