Im confused with Service and Broadcast receiver.what is the relationship between these two?why we have to call broadcast receiver when we start a service.Can anyone kindly explain the concept between these two elements
You don't have to register a BroadcastRecevier when you start a Service. That is, even if you don't register a BroadcastReceiver, our Service will work as expected. There is no must have dependency between the two.
As explained by Gridtestmail, a Service is a process you want to run in the background, without having an interface to the user.
A BroadcastReceiver is registered, when you want to be notified about certain events happening - for example, discovering a new bluetooth device or receiving an incoming call.
If you register a BroadcastReceiver for receiving incoming calls , then your Receiver's onReceive() method is called whenever there is an incoming all, so you can process it.
Similarly, for other event detection stuff.
I hope the concept is clear to you now.
Service: If you want to do something in background , this will be running always in background even if the application closed. You can create this in separate process and also you can give your service to other app if you want. Downloading any content or Music is good example
Broadcast Reciever: Usually system will send some info which can be recieved by your app if you would wish to ,by registering. And you can do something what you want when that thing happens by using onReceive method. Example is the system will send BroadcastReceiver when new sms arrives or Booting done
Example : Service and BroadcastReceiver
Related
I have to schedule an event in Android. My event is starting a service and just doing the work in background even when the application is not running.
Can I do this even without Broadcast Receiver?
For starting the service, do I need Broadcast Receiver?
I saw some posts, only some of them used Broadcast Receiver :
How to start Service using Alarm Manager in Android?
Scheduling an event in Android
http://www.learn-android-easily.com/2013/05/android-alarm-manager_31.html
http://justcallmebrian.com/2010/04/27/using-alarmmanager-to-schedule-activities-on-android/
UPDATE:
From the posts that I read further, I realize that I have to use Broadcast Receiver if the app is not running at the time of event, but I don't need Broadcast Receiver if my application is running at the time of event. Please let me know if I have reached the right conclusion.
You can use JobScheduler to achieve your requirements .
I have a service that gets start when push notifications are received. Based on a certain push notification, I would like to do bluetooth work (discovery and other things). So once the Service receive push notification, I have 2 possible solution ( given the app is not opened):
1- Call static method that will start doing the work
2- Send a broadcast. On the other hand , I will have the receiver registered through xml (so it can always receives broadcasts).
Which way should I do and why ?
Thank you
Always use Broadcast Receiver not any static methods ...Because static methods stores in heap and doesn't guarantee to garbage..While broadcast receiver is well documented with android system and also garbage collected.
I need to be able to have a service "tell" a BroadcastReceiver to do some work, and then wait until that work is done, and once it's finished, the BroadcastReceiver needs to send the result back to the service. And at that point, the service can continue execution.
So, "sending" the work from the service to the BroadcastReceiver is easy -- I just send a broadcast with the intent using extras for the work that needs to be done. But I don't know how to have the BroadcastReceiver then send the results back to the service. What's the best way to do this?
Edit:
I should have mentioned that the service in question is actually a contact sync adapter service. I'm not sure if that makes a difference, but maybe it does. Some of the work can't be done in the scope of the sync adapter, and that's why I'm offloading it to be done by the broadcastreceiver.
Register a Second inline Broadcast Receiver from the Service just to receive the results from the First Broadcast receiver. Pass the data via Intent. In the Second Broadcast receivers onReceive() do whatever you want.
Unregister the Second Broadcast Receiver in onDestroy of the Service.
this is what I've gotten so far:
Service running which is keeping up two connections (to two different servers), registering a BroadcastReceiver. The BroadcastReceiver is receiving my commands, which I want to send through the sockets. Working so far.
But: If I send "more" commands in a short time span (eg multiple commands in 1 sec) the BroadcastReceiver does not receive them - is the broadcast receiver too slow? Would it help to start a different thread in onReceive for handling the extra data?
Or should I go back to binding the service and passing direct commands to that object?
Would this be possible? -> Service running in background, registering a BroadcastReceiver, but also bound to an activity - it should still be the same service "object", right?
Thank you for your help.
I'm not 100% sure but instead of registering the broadcast receiver within the service code, it may be worth registering it within the Android Manifest may make it a bit quicker. This is how I usually do it and never find the broadcast to be slow or not received.
What is difference between BroadcastReceiver and ResultReceiver in android?
Result Receiver:
Generic interface for receiving a callback result from someone.
Broadcast Receiver:
Base class for code that will receive intents sent by sendBroadcast().
EDIT:
Background: All networking operations/long running operations should take place away from the main thread. Two ways to do this :
Async task - For Simple networking like say retreive an image/ do db
processing
Service - For Complex long running background process
If you need to perform work outside your main thread, but only while the user is interacting with your application, then you should probably instead create a new thread and not a service. For example, if you want to play some music, but only while your activity is running, you might create an Async Thread. But if you want the process to continue even after the user exits the app (say a download) then use a service
Lets say you pick 2. Now
You activity sends a web request to your service
Your service executes that using say DefaultHttpClient
It sends back data to your activity.
The third step of receiving data here can be done in two ways
1.) Broadcast receiver: Multiple receivers can receive your data. Used if you want to send data/notifications across applications(say you are also interacting with fb and twitter, multiple receivers for your web broadcast),
whenever you send broadcast its sent system wide.
2.) Result receiver: Your application is the only receiver of the data. It is an Interface you implement and pass it to the intentService through putExtra. IntentService will then fetch this object
and call its receiver.send function to send anything (in bundle) to
calling activity. Result receiver has
preference over broadcast receivers if your all communication is
internal to your application
EDIT: I should also mention this caution
Caution: A service runs in the main thread of its hosting process—the
service does not create its own thread and does not run in a separate
process (unless you specify otherwise). This means that, if your
service is going to do any CPU intensive work or blocking operations
(such as MP3 playback or networking), you should create a new thread
within the service to do that work. By using a separate thread, you
will reduce the risk of Application Not Responding (ANR) errors and
the application's main thread can remain dedicated to user interaction
with your activities.
A BroadcastReceiver is a receiver receiving broadcasts. Those are sent by someone in the intention that there can be many receivers receiving them (like radio broadcasts).
A ResultReceiver on the other hand is intended to receive a callback result from someone. So this could be compared with a walkie talkie, where you call someone and then are going to receive an answer (a result) from the one you called.
These two classes are completely different. It's actually quite the same difference as between Broadcast and Result.
what it Broadcast? In simple words it's some message which is visible to whole system and it can be consumed by every part of the system (which knows the contract), it wasn't originated by smb reuest;
what is Result? It's something we're expecting to receive from another part of the system. Usually there's only one receiver for result and usually that receiver has requested processing to obtain result (feel the difference - for broadcast nobody needs to do any 'request' to let it originated);
That was explanation from logic point of view. From the code perspective if You would compare BroadcastReceiver and ResultReceiver You could observe huge difference. Basically both classes are built on top of IPC but BroadcastReceiver is much more complex because of it's different nature (which I've tried to explain in first part).
Broadcast Receiver
A broadcast receiver is a component that responds to system-wide broadcast announcements. example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Applications can also initiate broadcasts—for example, to let other applications know that some data has been downloaded to the device and is available for them to use. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event.
Result Receiver
If your service is going to be part of you application then you are making it way more complex than it needs to be. Since you have a simple use case of getting some data from a Restful Web Service, you should look into ResultReceiver and IntentService.
This Service + ResultReceiver pattern works by starting or binding to the service with startService() when you want to do some action. You can specify the operation to perform and pass in your ResultReceiver (the activity) through the extras in the Intent.