What is maximum acceptable frequency from your point of view or experience of sending broadcasts in Android to be received by BroadcastReceivers without performance impact?
Let's say we send only basic data in a Bundle without need for long deserialization.
I am going to send broadcasts only inside my app with LocalBroadcastManager.
In other words this question is about when you should stop using broadcasters and write you own implementation for faster usage and when you should not do it.
First of all, if you send data inside one app, I would advise you, instead of BroadcastReceiver use LocalBroadcastManager or even not use any type of broadcast receivers at all - just Observer Pattern (here good article on this topic).
Related
I'm an Android newbie. I'm trying to send and receive messages between process. One thing which I'm aware of is communicating via binder calls by implementing a Service. The other message transferring mechanism which I've seen so far is
Broadcast (Not reliable though) - which can be missed
Event bus (Not sure IPC is possible with greenrobot's event bus - this SO link says it's not possible and suggested for alternatives
Registering a ContentObserver so that I can update my content at one process and the other process can get notified of the content change (Not sure this is reliable)
All I mean by reliable is that it can be missed at rare cases. Is there any alternative reliable and ordered (delivered in the same order in which it's published) - message exchanging mechanism between processes in Android?
EDIT: Though there are many ways discussed in this SO Link I would like to maintain the message order and guaranteed delivery of message.
What would be good approach to establish communication between different APKs? One app can send request to other apps and wait for response.
I can think of:
1. using BroadCast receivers: send "request" broadcast and receive returned broadcasts (results). This seems nice clean solution, no security problems, but how to get all results back as "one" - usually I will want to send out broadcast to collect app identifications, and get result like array.
2. use sharedUserId between all these apps and gather or execute whatever I need directly on the apps. But here are have couple of more loose ends:
- how do I get list of apps (through list of installed packages?)
- is with sharedUserId and same signature possible to access other app internals? like register/unregister component, etc.?
Thanks!
EDIT:
Have been reading more about ordered broadcasts and so far this seems good way to go. Using order broadcast each of other apps will fill in its own data part and result will be returned back to supplied "final" receiver.
I am using ordered broadcasts. When broadcast is send out, each receiver adds its information and last receiver calls resultReceiver.
I am writing an application that shows "Japanese Traditional Time" (JTT for short). There are several components (notification, widgets, application itself, alarms) which all use the same data - current JTT.
My current version uses a single service that does all the calculation and uses a Handler to notify everyone about "ticking", mimicking ACTION_TIME_TICK.
However with alarms I need to also have a way to translate "usual time" to JTT and vice versa. The calculations are quite CPU-heavy (it's all based on sunrises and sunsets) and thus I prefer having it all done in a single place and then cached (calculating stuff knowing sunrise and sunset times is not as heavy).
So I have several ways to do that now:
Keep it all in Service
And use binding to request the data I need. It's actually already done in one case and seems a bit cumbersome since I have to handle asynchronous responses
Move to content provider
And use content observers instead of broadcasting
Or send broadcasts from provider
Combine both ways
Use content provider to calculate the data for service which in turn will broadcast it when needed
Which would be better? Maybe something else?
Content providers are for structured data, so it doesn't really fit your use case. Not sure what you mean by 'asynchronous responses'? Calling a remote service is usually just like a local function call, it will block and return a value when done. If you have to notify multiple components a broadcast is the way to go. Explore using a LocalBroadcast if all components are in the same process (check Android support library source), or set a permission on it to make sure other apps cannot get it if you need to send a system-wide (regular) one.
I'm sticking with "just service" - I have discovered Sticky Broadcasts which actually cover the problem I had with common Broadcasts (having to request latest data from service after registering but before getting the first "tick") and that leaves me with much less cases where I need actual service connection.
My app is design to get messages from an embedded Bluetooth device. While I was working with sensors which sends data each second or more, it was not such a big deal to broadcast intents to activities. The only visible slow down was when the Bluetooth device flushed its buffer.
Now I need to deal with high refresh rate sensors (such as ECG, every 2ms) so I have to be little more cleaver because the number of intents makes visualization not in real time (there is more measures incoming than displayed).
I try to work with putIntegerArrayListExtra() to send data each 2 seconds but now I get a A.N.R.
Is someone can advise me to deal with lot of intents? (It seems my service memory also grow up to much).
To bypass intents, I have to send an object from a service to an activity. As far I now this is impossible and the reason of Intent.
EDIT:
I had underestimate binding. In fact it enables activities to get from the service an instance of a "DeviceDriver" which register listeners to perform callback. As I can retrieve the instance of the driver in the activity, I can register it as a listener and cut down all intents between service and activities (At least for data exchange).
You can also use binding to pass data from service to intent:
http://developer.android.com/guide/components/bound-services.html
In your case I advice you to not use intents. Try to use thread inside activity or shared memory and synchronization.
How much performance does it costs to broadcast intents?
Is it okay to broadcast multiple per second or are intents expensive?
Intents are meant to launch different activities within the Android OS or to inform about basic actions. It seems like a bad design pattern to use them otherwise. As they travel between different processes and therefore implement the Parcelable interface, they are not the most light-weight.
If you are looking to update different activities at the same time you might consider using a common service.
According to this blog post, intents are 10 times slower than direct function calls
http://andytsui.wordpress.com/2010/09/14/android-intent-performance/
It doesn't cost THAT much, but think of it the same way as you would a broadcast in a network environment. If you want to continually send a message to a device, you wouldn't send broadcasts every 100ms. That would just flood the network. Sending a broadcast once every, say, 10 seconds might be appropriate though.
What exactly the best implementation is entirely depends on what you're doing. In certain circumstances, if you have several services running that need to be run independently, and you're only broadcasting these intents that fast for say, 10 or 15 seconds. That might be ok.
But we can't really say.