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.
Related
I read this article to understand the difference between implicit and explicit broadcast. After going through this I'm getting confused with the concept of broadcast itself.
In general, the term broadcast means to scatter/announce the information to a wider audience and whoever listens/receives the message can make use of it.
In the case of explicit broadcast when we know the component name (package name according to Java terms) and activity name (corresponding class name in Java terms) why shouldn't we invoke the Class.startActivity() directly instead of configuring it to the manifest - delivering it to aosp and gaining the control of method to be invoked. I feel the purpose of the term broadcast itself is not satisfied here since we know to whom we are going to send (1-1).
Why does AOSP introduced broadcast when we have the direct control of invoking a method in Java? Is this to bring structure to an application - something like this?
EDIT :
I should have asked it more specifically like why do we need a broadcast when we are under the same process.
I feel the purpose of the term broadcast itself is not satisfied here since we know to whom we are going to send (1-1).
The original general case of broadcast Intents (implicit broadcast) was a "true" broadcast, where an arbitrary number of apps can register to listen for the broadcast. The scenario where you specify a ComponentName or package name is a specialized subset of the broadcast IPC mechanism.
Why does AOSP introduced broadcast when we have the direct control of invoking a method in Java?
Broadcasts are one form of IPC for Android. "direct control of invoking a method" is not IPC, as you cannot invoke a method in another app. For communication within your own app, you do not need broadcasts. For communications between apps, you need IPC, and for that, broadcasts are one option.
I have an app with an auto log out feature where I was using a Timer to auto log out the user (where user is a static singleton object).
Recently I realized there were some other activities and I have to implement a global log out feature so I tried to implement different Timers to each Activities and tried to synchronize them, but it wasn't a good approach and it was a pain. Then I turned my face to the services.
What I need to know is a good way to control a single service within different applications. Any ideas will be appreciated.
You can implement bound service, start it, and bind it with two activities.
More information You can find in official developer docs this and this
you can implement a "Bound" service to interact it from different activities.
Here is complete example for Bound service with explanation.
http://developer.android.com/guide/components/bound-services.html
A broadcast is a message that any app can receive. The system delivers
various broadcasts for system events, such as when the system boots up
or the device starts charging. You can deliver a broadcast to other
apps by passing an Intent to sendBroadcast(), sendOrderedBroadcast(),
or sendStickyBroadcast().
All that you need to do is to create BroadcastReceiver. Add IntentFilter for it. Register it in your Service. And than send Intent with action that you add to IntentFilter from any of your Applications.
Go throw this article to get better understanding of Intents
Are there any use cases in which I would want to use a BroadcastReceiver for something other than cross-application communication?
After reading the documentation, it seems like they are targeted at cross-application communication, but the idea of using them with the LocalBroadcastManager is also mentioned. I also read this post, which addresses the general usage of broadcast receivers. Neither seem to hit clearly on why it would be useful to use broadcasts and receivers for anything other than cross-application communication.
Does it have anything to do with their asynchronous nature, or maybe they're just used to move some processing out of the main activity?
Clarification: I guess the term cross-application was too general. I was considering the built-in actions such as
android.hardware.action.NEW_PICTURE
to be coming from applications. What I would like to know is: when is it useful to use a BroadcastReceiver for communication within my app - I guess this would narrow it down to custom intent actions/categories. Sorry if the way I'm asking this is confusing. I've only just recently begun programming with Android and I still don't understand the OS very well.
As it quotes in the post you linked: "A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system."
Therefore, they are useful in "catching" system broadcasts, e.g., when the device has booted up, when the battery level changes, when your Wi-Fi has been turned on, etc.
Personally, I've used a BroadcastReceiver to start my app whenever the device receives a text message. In my case, this is preferred, as my app does not need to be running when the text message is received. Upon receipt, the system will broadcast an intent with an SMS_RECEIVED action. My BroadcastReceiver component, registered to accept this particular type ofbroadcast, will be notified and can then react as needed. In my case, it launches an Activity to notify the user of the text message and choose a particular reply text message.
This is just a specific example. There are many other broadcasts that the system transmits and your Receiver can get. Check this link and this post for more examples.
Clarification:
A LocalBroadcastManager is preferable in instances when you want rather simple way to communicate between app components without an intent being broadcast system-wide. Knowing this, you would want to go this route when the info you're passing is to be used only by your app. A LocalBroadcastManager is more efficient, generally simpler than using an IBinder interface, and can ensure that information isn't leaving your app.
For an example, suppose you have a Service that runs in the background to track and log some constantly changing data; let's say your battery level. The Service can run on its own without user interaction, saving the battery level to the disk as it changes. When you start your activity to view said data, it would use LocalBroadcastManager to register a receiver to accept the info the Service is sending, and update the Activity's UI in real time to reflect this. Since no other app needs the info from your Service, it's better to do this than broadcasting an intent to which any other app could have access.
To sum up, using a LocalBroadcastManager is:
More efficient.
More secure.
Simpler.
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)
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.