I am kind of confused about the BroadcastReceiver.
As title, I don't think I need another one BroadcastReceiver in my app.
Or, is there something wrong if I use a bunch of BroadcastReceiver in my app?
I think it will affect my OS execute memory and performance, am I right.
Thank you for your time and hot-heart.
Its all up to you. You can have multiple BroadcastReceiver for different sets of intent-filter or use single broadcast receiver to handle all the intent-filters.
Usually its better to define different receivers based on the set of intent-filters which are supposed to offer functionality for a related group of task.
Like I said, its all up to you. If you have a large set of intent-filters and you want your code to be handled properly (based on the similar classification of tasks it performs) then go for multiple receivers. Otherwise its easy and logical to handle few filters in single receiver.
Moreover, the performance of your app will not be obstructed as it depends on the execution of tasks with in the receiver, not the quantity of receivers or filters.
Tip: Try to introduce Threads wherever you are expected to perform some heavy lifting :)
It's considered that class should have one responsibility. So, if your BroadcastReceiver handles both SMS and CALL intents, then consider having multiple receivers.
You can declare as many BroadcastReceivers as you want on your app. It will affect if on every broadcast you receive you start doing a million long running background operations.
But does the app you're planning really need all those receivers?
There're some APIs to programmatically enable/disable your declared receivers, might be a good option too.
edit:
I guess it would be easier if you do a little test yourself.
On your Eclipse, create a new Android Project.
Create a class that extends the BroadcastReceiver.
Save and close it.
Now go to the manifest, Application tab, Application Nodes, ADD button, Add a receiver.
Wait for the Eclipse to search your application and find the one you just created.
Inside the receiver put a new Intent Filter. Don't need name or anything.
Inside the filter put an Action.
In the action name, check the drop-down menu.
Those are ALL the different actions a BroadcastReceiver might be receiving. So it just make it simpler and more organized for some application to implements more than one receiver, one receiver for each different type of action. Or maybe it's only receiving two very similar actions and it's simpler to make it all in one receiver.
Does it make sense?
Related
I have been looking for solutions for this, but there doesn't seem to be any. I have a fairly unique use case that I need to be able to pass data between two different apps even when one app isn't active, therefore my BroadcastReceivers need to be registered in the manifest. However, what I can't seem to figure out is how I pass the received data from my manifest-registered BroadcastReceivers to my activities. Most of the examples are using dynamically registered BroadcastReceivers, which will not work in my use case.
Even though it is hard to say without knowing what you are trying to accomplish, two solutions come into mind; one being receiving with permissions and the other is WorkManager to schedule work regardless of your user is using your app or exited your app.
Following various challenges with android (in particular Service being re-Created by AlarmManager and Log not working (or seems to drop some lines)), I am redesigning some of my code to work using Broadcast intents and Broadcast receivers. Now, suppose that you have a source of information and many listeners. The source of information wishes to send information to only one of the receivers at any point in time:
time=1: Broadcaster->Recevier 1
time=2: Broadcaster->Recevier 2
time=3: Broadcaster->Recevier 3
There are two ways to achieve this:
All the receivers can use the same action code, say "com.me.stuff.INFO_FROM_SOURCE". This means that the android system only has one extra possible broadcast type to handle but that the information goes to each receiver and each receiver has to decide if the information is for them.
Each receiver has its own code, say "com.me.stuff.INFO_FROM_SOURCE_TO_RECEIVER_X". This means that the android system has more possible broadcasts to handle but that only one receiver will have to handle the incoming broadcast.
Overall, which is the least load on the system?
I would do it the second way. br messages are meant to do one single thing. I suppose you could have one action with differences in the intent bundle, but that seems like an unnecessary step when you can filter by action, the way that its meant to to filtered.
you can have the same receiver filter for multiple actions, then on your onReceive, put in an if statement that checks all the possible actions.
I am not trying to create a BOOT_COMPLETED receiver (and doing so would not solve my problem).
Is there a way to determine if BOOT_COMPLETED has occurred? I have a library which is being called before (as well as after) Android has finished booting, and I do not want my library to complete its request if the system has not finished booting. Setting up a BOOT_COMPLETED receiver in every application that may use this library is not a reasonable approach for several reasons.
Are there any Android calls I can make to determine if the device's boot has completed? It appears that there is a property, dev.bootcomplete, which I may have to use if no better method exists.
I'm afraid the only official way of achieving this is to create RECEIVE_BOOT_COMPLETED receiver.
I would advise you not to rely on properties, since they often are OEM specific. Otherwise you may end up with your application working on one Android model, but not another.
Setting up a BOOT_COMPLETED receiver in every application
I guess you mean to say you dont want BOOT_COMPLETED receiver in each activity .
Its very much possible.
You can register BOOT_COMPLETED receiver for Activity A.and once Activity A a gets broadcast it can notify other activities using sendBroadcast (custom broadcast).
To see how to use custom broadcast look here
I started with a standard local android service, and used Binders with Listeners to communicate. Then: I began noticing some serious issues with handling orientation changes, so I decided to skip the whole binder thing, and just go with broadcasting intents (and using startService exclusively) that contain all the data/commands that need to be passed.
My question is: what are some of the pitfalls I have to look out for when using this approach?
Are there any disadvantages?
If you are supporting API Level 4 and above, use setPackage() to make your "broadcast" be a "narrowcast" -- keeping the broadcast within your app. By default, the broadcast is truly broadcast, to all apps, which may or may not be a good thing for your data.
Don't forget to unregister your BroadcastReceiver (i.e., don't register it and forget it). At the same time, you will need to consider what to do if the service wraps up and the activity is long gone (e.g., BACK button). One approach is to use an ordered broadcast with a low-priority manifest-registered receiver that will raise a Notification if no activity handles the broadcast -- this sample app demonstrates what I mean.
You might consider a Messenger instead of the broadcast approach, as it is intrinsically a "narrowcast", probably is a smidge less overhead, and can't be leaked. I am still working through the mechanics of using this with configuration changes, though.
I want to create an application in which
- Create a listener which listens for outgoing/incoming messages and calls
- UI is shown/hide based on listener results
Shrini,
As dds stated, you will definitely need at least two BroadcastReceivers. You will need one BroadcastReceiver for each incoming call and message that you want to respond to, and one for each outgoing one as well. A BroadcastReceiver may only capture one BroadcastMessage at a time. You will specifically need to capture the Intents sent by the operating system and your Application will need to have the appropriate Permissions for each. That's just setting up the listeners.
Once the BroadcastReceiver has been called you will need to start an Activity for you UI and possibly a Service to do any other processing. In the cases of single-point events (like messages) an Activity is often enough. Calls, however, depend largely upon what you are doing. Since a call has two distinct events, in order to tie them together, many people prefer to use a Service just to hold and watch the call.
In order to best help you, I must inform you that your question is remarkably vague as to what you need to do. Does your custom UI display information about the calls? Does it allow the User to respond or change that information? What kind of messages is your app responding to? SMS? Email? IMs? These are important because each one has different considerations.
Given that the limitation of information provided here, I would recommend researching your topic by downloading and viewing some of the open source projects stored on Google. Here is a Here.
Fuzzical Logic
Create a listener which listens for
outgoing/incoming messages and calls -
UI
To achieve this I think you need to use broadcast receivers to catch the broadcast message when any message activity is going on. You may need 2 in BroadcastReceivers , one for incoming and one for outgoing messages.
In the receivers you need to call your related Activity (your UI) to interact with the user. But note that you should not do any time consuming work in BroadcastReceiver since in BroadcastReceivers are expected to be light weight and killed in 10 seconds after they are invoked. See Broadcast receivers at here