The application is being developed in 2.3.3
In my application, I am starting a service from a broadcast receiver. The service calls the Location Manager and gets latitude and longitude. Is it possible to send the latitude and longitude values back to broadcast receiver from Service?
If Yes? How do we do it?
If No? -> which is my approach as of now... I have used a SharedPreferences object to hold these values and access them in BroadCast Receiver. Will this work?
I do have few more questions on this, will edit my question after the answers...
Thanks..
[Edit] Answer to my above question -> So we can send data from Service to Broadcast Receiver, though it's not a good practice in general.
It is possible to pass the information back to the broadcast receiver by broadcasting a new intent from the service that has the location data. You will need to create a custom action for the intent and have your broadcast receiver register to handle that action. Creating and receiving intents with custom actions is described here.
However, I think in pretty much every case this is a bad approach. In general broadcast receivers should merely parse intents and launch intent services to do all of the work. If something needs to be done with the location then the service should do it not the broadcast receiver. It is also important to note that at the end of onReceive() the broadcast receiver is immediately destroyed so you lose all of its state.
I'd be happy to answer more questions or update my answer to be more specific if you provided more information as to the purpose of lat/long gathering task.
[EDIT] Since I can't comment I'll add my two cents to Kerim's answer. Unless I am missing something huge (if I am please let me know Kerim since you can comment on mine) may not work the way you expect. When the broadcast receiver's onReceive() function finishes the broadcast receiver will be destroyed. The handler you sent will live on but any data in the broadcast receiver will not exist and the handler will not be able to call the broadcast receiver's functions. Since the handler can't access any of the broadcast receiver's data or functions, you might as well do everything that needs to be done in the service.
You can use Messenger class to communicate accross processes.
When you start a Service, pass a Messenger object as an extra. Then service after completing its job, can send latitude and longitude values back by calling messenger.send(message);
Messenger class takes a Handler object in its constructor. Any Message objects sent through this Messenger will appear in the Handler as if Handler.sendMessage(message) had been called directly.
Here is nice tutorial that explains in detail: http://www.vogella.com/articles/AndroidServices/article.html#servicecommunication_handler
Related
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.
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.
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
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.
I get an error message when I attempt to bind from the onReceive() of a receiver to a local service before I drive a bespoke API on it.
"IntentReceiver components are not allowed to bind to services"
What is the best way of getting a piece of data from a service while in a broadcast reciever.
Many thanks.
P.S. I need to get the answer synchronously i.e. I have wait on the answer from the service so a callback may not be possible.
What is the best way of getting a piece of data from a service while in a broadcast reciever.
If the BroadcastReceiver is created from something else (e.g., an activity) and set up with registerReceiver(), then the "something else" is what should be binding to the service and doing the work.
If the BroadcastReceiver is a component registered in the manifest, then you need to rethink your approach to whatever problem you are trying to solve. These sorts of BroadcastReceivers cannot bind to services and cannot spend much time doing work. If the BroadcastReceiver cannot do its work in less than, say, 10ms, it should delegate control to a service via startService(). That service can then do the work on a background thread.
P.S. I need to get the answer synchronously i.e. I have wait on the answer from the service
See above.