Android broadcast is a good IPC mechanism, but sometimes i only need broadcast or event notification within a process. I want to know if there's something like in-process broadcast?
Use LocalBroadcastManager, found in the Android Support package. Here is a sample application demonstrating its use. Mostly it involves calling methods like registerReceiver() and sendBroadcast() on LocalBroadcastManager.getInstance(this) instead of directly on a Context.
You may be interested in Otto. It's a publish subscribe library based on Google Guava, and made specifically for Android.
Related
I want to use android broadcast receiver in my application but I don't know exactly how to use the android broadcast receiver and how it is work in an android application.I found the many definition for this in Google but I didn't know exactly what did they mean.
With broadcast receivers you can either hook into system broadcast such as Intent.ACTION_BATTERY_LOW or you can create your own broadcasts. Why would you want to do this? Because broadcasts allow you to exchange information between your component and to have a loose coupling between them at the same time. A component which broadcasts a message does not need to know about the listeners and no registering of the listener is required. This allows you to implement the message passing pattern in your Android application.
You can create your own broadcasts either for interprocess communication, or you can use an optimized version for communicating inside the current process through the LocalBroadcastManager class.
The link given by Tim Castelijns will give you some examples.
This is a follow up from this post
How to use GreenRobot's EventBus in broadcasting events from Service to Activity?
my use case revolves around a service and an Activity.
Service is used for tracking the changes in the BLE connection.
Activity is used for reporting that connection state to the UI.
Existing scenario. Service is using broadcast for sending the events (via sendBroadcast() method) of each state revolving around BLE
(connected/Disconnected, Data available, etc..)
My Doubt: Can I make use of this GreenRobot's EventBus Library to control (send and receive events) in same way as broadcast does? If so, Is there anything I should consider (about thread safety) or to be must known, while replacing the broadcast control (send and receive) paradigm completely.
I'm currently using Otto (very similar to EventBus) to accomplish what you're wanting to do.
I have a service which holds a timer, and shows a persistent notification. Each update of the notification also publishes the newest information for the Activity to receive and then update the UI.
It's ALOT easier to implement with Otto (and possibly also EventBus, i haven't used that particular library) as i needed to send 4 pieces of information each time i published some information, and it grew tiresome to add extras to intents each time with the regular sendBroadcast() system.
I haven't had any issues after switching to Otto, and it helped me clean up alot of my code.
One thing to note (with Otto atleast) is that it's setup by default to only allow publishing/subscribing on the main thread, and as you're using a service, you'll have to edit this. I'm not sure whether or not EventBus has the same, but look out for it in their documentation.
In Android, given a specific Service, how many methods exist for that Service to communicate with other components (activity, content provider, receiver, other services)?
As far as I know, there are at least 7 methods:
startService
AIDL/bindService
sendBroadcast
startActivity
notification
messenger mechanism
Ashmem
Are there any others?
Thanks.
Like gunar said, you can also use an Event Bus.
The most popular are:
Otto (square)
EventBus (greenrobot)
The documentation it's self explanatory but if you need help to get started let me know.
Regards,
Ryan
If you want to classify them, then I would do it as following.
Communication using Intents
Broadcast intents (global and local)
Component intents (start activity, start service)
System notifications
Interprocess communication (IPC), can be used for in-process too.
Bound services
Using Messenger
Communication via shared objects.
Using Singleton (e.g. application or other singleton classes)
Using event bus (EventBus, TinyBus, Otto)
I understand how to use Intents to communicate with the system/other apps. I understand how to use Intents within the same App. I also understand how to use Otto to communicate within the same App.
What are the Pro/Cons of using Otto vs. Intents to communicate between my Activities/Services?
Pros for using Otto:
You get to design your own event types, versus having to use custom actions or something to distinguish one Intent from another
Everything is within your own process (contrast with startActivity() and kin, which always involve IPC, even if the activity you are starting is in your own app), for speed and security
A bit less coding, as you aren't having to instantiate IntentFilter or BroadcastReceiver objects
It offers the producer pattern (as a quasi-replacement for sticky broadcasts)
Being not part of the OS, it has the potential to be updated more frequently
Cons for using Otto:
It cannot start an activity
It cannot start a service
It cannot bind to a service
It cannot send a broadcast
It cannot be used in a PendingIntent or for any true IPC
IOW, the true comparison for Otto is with LocalBroadcastManager, not with the general use of Intents.
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.