7

I'm writing a simple broadcast receiver. I've registered receivers in both the manifest and in the code before. For my purposes this is a simple receiver that doesn't need to do anything fancy.

Is there a reason to choose one method over the other in this case? Is registering the receiver in the manifest more efficient (executes faster)? Or are they both basically the same?

I'm asking because the application I'm writing needs to be very efficient, and I haven't been able to find good information on the practical difference between the two methods. I'm trying to follow whatever is the best coding practice.

Cheers

Dave
  • 3,178
  • 5
  • 28
  • 44

4 Answers4

8

Well, they are actually different. You seem to think that it is almost same. When you register a receiver in code, you must unregister it when the app gets destroy (actually, when the Activity or Service that register it, gets destroy). On the other hand, when you declare it in the manifest, you make it available even if you app is not running.

Just ask your self: which of the two approaches best fits your needs?

Cristian
  • 198,401
  • 62
  • 356
  • 264
  • Interesting. Thanks. They still sound very similar to me, it isn't too hard to control when to register/unregister the receiver. Also if you are running the receiver in a service it will work if the app is not running. Are you saying that if this was not a service, the receiver would work if the application isn't running if implemented in the manifest? That doesn't seam right. – Dave Oct 27 '11 at 20:56
  • Just one clarification... if a service is running: the app **is** running. – Cristian Oct 28 '11 at 06:28
  • aha I just had a click moment. Thanks Cristian! – Dave Oct 28 '11 at 19:30
2

I can't speak as to the efficiency of the implementation of one over the other (my intuition tells me that it's too close to really matter), but for reasons hinted at in Cristian's answer, registering and unregistering programmatically might make your app more efficient.

If you register in the manifest, your broadcast receiver will always be woken up by any intents that match your filters. If you register programmatically, you can only allow your receiver to be woken up at particular times, and you can control which intents will wake up your receiver and at which times.

If you're really worried about waking up the receiver at times that it doesn't need to be, then do it programmatically in the code. You'll need to be more careful to always unregister, and ensure that your receiver is registered at all times that you expect it to be, but if you do that correctly, you can avoid waking up your receiver unnecessarily, and thus saving some efficiency.

Chris Bye
  • 1,028
  • 7
  • 17
  • I like the idea of having the extra control of when the receiver is active or not. Thanks. – Dave Oct 27 '11 at 20:54
0

It depends on scenario.

When to use which method to register

Which method to use for registering your BroadcastReceiver depends on what your app does with the system event. I think there are basically two reasons why your app wants to know about system-wide events:

  1. Your app offers some kind of service around these events

  2. Your app wants to react graciously to state changes

Examples for the first category are apps that need to work as soon as the device is booted or that must start some kind of work whenever an app is installed. Battery Widget Pro or App2SD are good examples for these kinds of apps. For this type you must register the BroadcastReceiver in the Manifest file.

Examples for the second category are events that signal a change to circumstances your app might rely on. Say your app depends on an established Bluetooth connection. You have to react to a state change – but only when your app is active. In this case there is no need for a statically registered broadcast receiver. A dynamically registered one would be more reasonable.

There are also a few events that you are not even allowed to statically register for. An example for this is the Intent.ACTION_TIME_TICK event which is broadcast every minute. Which is a wise decision because a static receiver would unnecessarily drain the battery.

Sunil Kumar Sahoo
  • 53,011
  • 55
  • 178
  • 243
0

Simply put

Dynamic Registration - Your app expects something to happen immediately while the app is running

Static Registration - You app is waiting for something to happen over the long term. And since you cannot guarantee your app will be running when it happens you can politely ask the android system to notify you when it does

They both would have the same execution beyond that point

cagney
  • 492
  • 3
  • 11
  • Welcome to Stack Overflow! Please feel free to take a [tour](//stackoverflow.com/tour) of the site, and if you need additional help with the site, check [this](//stackoverflow.com/help) out. Oh, and if you ever run into issues that the help page doesn't cover, feel free to ask on [meta](//meta.stackoverflow.com/). – Claudia Jun 20 '17 at 16:21
  • Also, do note that this question is almost 6 years old, and if it were posted now, it would very quickly get migrated to [SoftwareEngineering.SE](https://softwareengineering.stackexchange.com/). I've downvoted it for this reason, but please don't take it personally. :-) – Claudia Jun 20 '17 at 16:23
  • Oh, so should I have attempted to move the question? Or just not respond to old questions no matter what? – cagney Jun 22 '17 at 14:28
  • More to the point you should just be more aware of what questions you answer. It's pretty common actually for newbies to answer very old questions and/or questions that are not quite [on topic](//stackoverflow.com/help/on-topic) here, since they're still learning the site and its community. – Claudia Jun 22 '17 at 21:34
  • Also, the only people who can migrate questions to other sites are those with moderator privileges. So don't worry too much, and feel free to check out some of the other questions, because I see far too many with answers that aren't even mildly useful, if any at all. – Claudia Jun 22 '17 at 21:36
  • If these kinds of questions interest you, though, I would *definitely* check out that other site (Software Engineering), because that's where most of these types of questions are. This one was missed in the mass migration when most design-related questions were moved from here to there. If you feel strongly about it, definitely see about getting a little bit more reputation (you only need 15) and flagging this question. – Claudia Jun 22 '17 at 21:40
  • Gotcha. Thanks for the response! – cagney Jun 23 '17 at 16:01