I have a repeating AlarmManager that calls a Service to perform some background updates. I read somewhere that I need to cancel the AlarmManager in the service's onDestroy, but this doesn't seem to make sense to me. It seems to be me you'd only want to cancel the Alarm if you don't want it to fire again.
You might want to provide a link, or a more detailed explanation/argument. You might want to
cancel background threads onDestroy(), but alarms are independent of the activity, and will fire (and create a process if necessary) even if your activity is not running. Once you cancel it, it will be gone, so you will not get those updates. You should only cancel if you don't need them anymore, e.g., an preferences option to cancel automatic updates to save battery, etc.
Related
I am in the process of making an app that will be triggered by a system broadcast and would take time input from the user, after which the app should just run a timer and do a task after the timer is over. My questions are as follows:
Do I need to use a background task for this, or is this possible to be achieved without it, because I need the timer to run even if the app is closed in the app drawer.
If I do need to use a background task, what should I use, an AsyncTask, a Service or a JobScheduler?
I understand that a BroadcastReceiver will listen to any system broadcasts, and since I have registered in the Manifest, the app will start on any such system broadcasts. However, as soon as the app is started due to the system change, I need it to popup a dialog box which takes input in the form of time (HH:MM:SS), and after that a timer begins which runs for that amount of time and as soon as the timer stops, another task is done.
I also don't want the task to be a one-up, meaning that I want it to be to done every time the system receives the system change broadcast.
For what you want to do, you basically need three things.
A BroadcastReceiver for receiving a system broadcast. This component is essential. Also, you don't have to worry about it being a one-up thing. A registered BroadcastReceiver will continue to run it's onReceive() method until the BroadcastReceiver is unregistered by you or the system, or if you intentionally place code in to block it from activating.
An Activity to display the Dialog. Technically, a BroadcastReceiver can also display a Dialog, but BroadcastReceivers are meant for short and quick tasks, so it's not a good place for this. An Activity where you show a DialogFragment is the better option because compared to a Service, an Activity is really the component meant to display a UI.
An AlarmManager for counting down the time. Rather than creating a Service yourself to handle the timer, you should use the AlarmManager with exact time to help you respond to the amount of time that passed. You can also use a JobScheduler as an alternative to AlarmManager, since both are meant for executing code at a later time. Which one you choose depends on the task you want to do later on. Personally, you should also consider the new WorkManager, which is the better option in my opinion. Depending on what you need to do, it will internally use a JobScheduler or AlarmManager, which helps get rid of the deciding process for you.
I need to request a url every 5 seconds.So I used AlarmManager to send a intent by call setRepeating.but when I long click HOME hardware button to kill it, AlarmManager doesn't work. How to solve that? :)
Usually if you don't kill your Alarm when you call the onDestroy(), the Alarm should still be running on background even after application exit. Are you sure that you are not terminating it somewhere inside your onDestroy() method?
If you give a look here :
http://developer.android.com/reference/android/app/AlarmManager.html
The docs says : "The Alarm Manager is intended for cases where you want to have your application code run at a specific time, even if your application is not currently running. For normal timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Handler."
Remember that if your phone is in stand-by it might not be able to execute the code you want to, you need to wake it up properly.
I want to start a service every 15 minutes. Most of the time it will quit in about 30 seconds, but there will be times the service lasts longer than 15 minutes. I don't think it would be good for the alarmmanager to start the service if the previous service call is still running. I was considering setting up a flag in onStartCommand to have it simply return without doing anything if the service is running. But I'm not sure if this is the best way to handle it, as onStartCommand returns an int and I don't know what the system needs for this value. Is there a best way to do this?
But I heard from CommonsWare this: "No, it will not create a new service. If the service is already running, it will be called with onStartCommand() again, to deliver the new Intent, but a second copy is not created."
Yeah, that CommonsWare guy, he sure does write a lot... :-)
I don't think it would be good for the alarmmanager to start the service if the previous service call is still running.
If you are using IntentService, this will not be an issue. The command from your second alarm will be enqueued, awaiting onHandleIntent() to wrap up from the first alarm.
If you are not using IntentService, you will need to have smarts in onStartCommand() to determine that your own thread is still chugging along, and therefore you want to skip the command.
But I'm not sure if this is the best way to handle it, as onStartCommand returns an int and I don't know what the system needs for this value.
That doesn't really have anything to do with your problem. Just return super.onStartCommand(), or whatever your current onStartCommand() method is returning.
But what if I don't want the service to start again until the next time its supposed to be called?
Well, you could replace the repeating alarm with one-shot alarms (use set()) and then set up the next alarm as part of wrapping up the work from the previous alarm.
Im trying to make a countdown timer run in the background of my activity, it needs to run constantly until it finishes, but not sure how to make it work with a service. I also need to update the display on my main activity
Uh, not all services run 100% of the time. Nothing is a battery drain unless it's executing at 100%. If you look at the actual battery consumption of an Android device, you'll see that the largest percentage comes from the screen. The next comes from radios. Running a process costs very little.
You can use an IntentService to fire off an alarm at regular intervals. The service can send intents to itself. Have one intent action to start the service, and one to turn off the alarm. Make a third action for resetting the alarm.
To start the service, send a "start" intent to the IntentService using startService(intent). This should trigger a method that creates an intent with action "cycle", puts the intent in a PendingIntent, and schedules a repeating alarm with AlarmManager.setRepeating().
After the interval that you set for the alarm, the AlarmManager will take the "cycle" intent out of the PendingIntent and send it back to your service. Your service should handle "cycle" by rebuilding the PendingIntent and restarting the alarm. This goes on indefinitely. You can put anything else you want to do when the alarm goes off in the handling for the "cycle" action.
When you want the alarm to stop, send the "stop" intent. In response, your service should cancel the alarm by reconstructing the PendingIntent and then calling AlarmManager.cancel().
Notes: The main entry point for an IntentService is onHandleIntent(). You call everything else from there. When that method finishes, the service goes inactive until it receives another intent. The only place you can "see" it is in cached processes. Once you stop the alarm, the system will eventually figure out that the service isn't being used, and garbage-collect it.
Services are the way to do background work. I suppose you can run some AsyncTask or a thread, but you still want to run them in a Service, otherwise you've linked them to something that's running in the foreground. If the task doesn't need to interact with the user, particularly if it can work asynchronously to your activity, then use a service.
I need to cancel a repeating alarm when my app terminates. The problem is I have several activities and since they can be killed at any time, how can I determine when the last activity is being shutdown so I can call my alarm canceling method?
There's no 100% reliable way. The best thing you can do is subclass Application and override onTerminate().