I have a broadcast receiver that listens for an sms or call from a specific number. when it triggers it starts a location service which runs from that point on.
I need to be able to stop this service once it is no longer needed from my app.
My app does not need to be running for this broadcast receiver to trigger the service.
Any advice would be very much appreciated
Thank You
Related
I want a broadcast receiver to be listening all the time, as long as the app is downloaded the receiver should always be listening, so how do I achieve this?
My current method is to use a foreground service to keep the receiver alive, but is this recommended?
In all the articles I've read no one mentioned infinitely running service, so should I avoid using a service in this case?
If not then how do I do it? I have some app which I'm pretty sure that they use infinitely running broadcast receivers.
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 working well in a running process. It controls a specific broadcast receiver even when the main activity isn't shown. It also starts up at a certain interval on its own to check some parameters. On detection that no broadcast receivers exist, I can stop the service outright until one is registered or it restarts itself at the interval. In the meantime, the service will be running in START_NOT_STICKY mode.
However, when I do connect to the service and register a receiver, is there a way to change its running state from START_NOT_STICKY to START_STICKY from within it? Or will I simply have to use a isRegistered flag in the receiver, stop and restart the service and check its value within onStartCommand? Is this a good pattern to use or are there any better?
The main reason for doing this is so to not have a process running in the background when it isn't required by the app.
From android dev website Services, START_STICKY means the service will hang around after it is done running its commands, START_NOT_STICKY will end after running its commands.
From your description you keep saying you are running services and adding a broadcast receiver to it? Broadcast receivers are actually used to receive external requests regardless of any other services. The broadcast receiver will actually be the first point of contact for the app to receive external requests, then it would be responsible for starting a service to run any needed commands. As far as your services you need for running commands periodically those should just be started and ended as needed based off of the above defenition of service flags.
Example flow for GCM (Google cloud messaging).
Cloud server send a message to a registered device.
Going through the google play services on the registered the device, an intent is sent to the Broadcast receiver for the registered app.
Broad-cast receiver receives intent, hands it off to a service which performs any further commands necessary for processing (I.E. showing notifications etc..).
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
I want to send an intent to my service everytime the state of Wifi connectivity changes.
So when I currently use a broadcast receiver to listen for the state changes in Wifi, so when this recieves an intent I want to be able to send this info on to my service.
Is this possible and if so the correct way to do it?
If the service is going to be running at the time, you could just register a BroadcastReceiver in the Service directly via registerReceiver().
Otherwise, call startService() from the BroadcastReceiver to let the Service know of the event, starting up the Service if it is not running. Be sure to shut down that Service at some point (e.g., use IntentService, which will automatically shut itself down when there is no more work to do).