Is it better coding practice to register the receiver in a manifest or in code?

I am writing a simple broadcast receiver. I registered the receivers both in the manifest and in the code before. For my purposes, this is a simple receiver that does not need to do anything.

Is there a reason for choosing one method over another in this case? Is registering the receiver in the manifest more efficient (faster)? Or are they both basically the same?

I ask because the application I am writing must be very efficient and I could not find good information about the practical difference between the two methods. I try to follow all coding rules.

Greetings

+7
source share
4 answers

Well, they are actually different. You seem to think it's almost the same. When you register the receiver in code, you must unregister when the application is destroyed (in fact, when the Activity or Service that registers it is destroyed). On the other hand, when you declare it in a manifest, you make it available, even if the application does not work.

Just ask yourself: which of the two approaches best suits your needs?

+8
source

I can’t talk about the effectiveness of implementing one over the other (my intuition tells me that this is too close to the really important one), but for the reasons outlined in Christian's answer, registering and unregistering programmatically can make your application more efficient.

If you register in the manifest, your broadcast receiver will always be awakened by any intentions that match your filters. If you sign up programmatically, you can only allow your receiver to wake up at a specific time, and you can control what intentions your receiver will wake up and at what time.

If you're really worried about waking up the receiver at times, which is not necessary, then do it programmatically in code. You need to be more careful to always unregister and make sure that your receiver is registered anytime you expect it, but if you do it right, you can avoid unnecessarily waking up your recipient and thus save some efficiency.

+2
source

It depends on the scenario.

When to use this method for registration

Which method to use to register your BroadcastReceiver depends on what your application is doing with the system event. I think there are two reasons why your application wants to learn about system-wide events:

  • Your application offers some kind of service around these events.

  • Your application wants to respond kindly to state changes.

Examples for the first category are applications that should work immediately after loading the device or start some work when installing the application. Battery Widget Pro or App2SD are good examples for such applications. For this type, you must register BroadcastReceiver in the manifest file.

Examples of the second category are events that signal a change in circumstances that your application can rely on. Say that your application depends on the established Bluetooth connection. You must respond to a state change - but only when your application is active. In this case, there is no need for a statically registered broadcast receiver. Dynamically registered would be more reasonable.

There are also several events for which you are not even allowed to statically register. An example of this is the Intent.ACTION_TIME_TICK event, which is broadcast every minute. This is a wise decision because the static receiver overcharged the battery.

0
source

Simply put

Dynamic registration - your application expects something to happen immediately when the application is launched

Static registration - the application expects something to happen in the long run. And since you cannot guarantee that your application will be launched when this happens, you can politely ask the Android system to inform you when it does

Both will have the same performance outside this point.

0
source

All Articles