I have an app which allows users to schedule alarms to sound at certain times, repeating at intervals of their choosing. I am using JSON to persist the alarm details, using SharedPreferences as storage.
I am using AlarmManager to schedule when my app should be notified that an alarm should sound to notify the user. I am currently using the setRepeating() method of AlarmManager, supplying the interval provided by the user. This works well, and in theory the app would never need to update the JSon which stores the next alarm time, as AlarmManager will just reschedule the next alarm time using the interval.
However, my thinking is that when the device is rebooted, I will need to supply a up to date alarm time to AlarmManager to avoid AlarmManager thinking an alarm has been missed as this is not necessarily the case.
So, what's the best way to do this?
update the JSon next alarm time when the alarm is sounded, even though this may not be necessary (setRepeating() handles this as long as there is no reboot)?
register for and listen for shutdown broadcasts and update JSon then (this raises questions - just how long will the app get to calculate and write alarm details to storage given that the phone is shutting down)?
don't update the JSon but add logic to the object which is woken by the AlarmManager to decide if the alarm just broadcast is valid and the user should be alerted?
I'm sure any of the above will work, but I can't decide which is the nicest way to do it.
This seems mostly a matter of choice. The problem you note parallels a general problem seen in Linux laptops and solved by anachrond. In my opinion, I would simply update the time and store it in SharedPreferences every time the event is received. Trying to listen for when the system shuts down might not be entirely reliable (what happens when your users -- probably drunk college students -- drop their device and the battery flies out?). Instead, I believe the best thing to do in this scenario would be to -- each time the alarm fires -- recalculate the time to send the next one, store it somewhere, and upon boot schedule appropriately.
Related
for example,An AlarmManager to count numbers at 7AM using Calendar was set.
But user turns off the android at 6am and turns on 8am.
So program does'nt count.
I dont think i can avoid this situation if i reset AlarmManager on receiver of BOOT COMPLETED.
Please tell me the way to count exact number in this situation.
You'd have to do a bit of work. Save the time of your next alarm in permanent storage (file, shared preference, or database). Whenever an alarm occurs, update this value. Set a BOOT_COMPLETED listener. When the boot completed listener launches, have it get the current time and check if its later than the time of the next alarm you stored. If so, you missed it. If not, you're ok.
Now if you have to worry about missing multiple alarms, it gets more complicated, but the idea is the same.
Hi I need to set AlarmManager to run a reminder for me to take medication. I need to repeat it by custom amount of days and custom amount of times to take in the day.
So is there an efficient way to set the AlarmManager or CommonsWare's Implementation of the AlarmManager to remind me "twice a day starting at 9AM for the next 5 days" to remind me to take medication? Pls advice and tnx in advance for any constructive help in sample code and in relevant tutorials.
I haven't looked into Mark's AlarmManager implementation, but there is no way, in general, to get the bare AlarmManager to do what you are trying to do. You can schedule a single alarm, at a specific time, or a repeating alarm, that repeats at fixed intervals. If you want something that handles complex schedules like the one you describe, you'll have to write or find code that does it.
You want to use a PendingIntent with the AlarmManager. The idea is to schedule the pendingIntent with the alarmManager, have that trigger an intentService or broadcast, setup another pendingIntent with the alarmManager for the next desired event. You want to keep in mind that you'll need the BOOT_RECEIVED permission in case the user reboots their device. I have complex scheduling in Audio Control and this is exactly what I do.
Here is a pretty decent tutorial of what I mean:
http://android-er.blogspot.com/2010/10/simple-example-of-alarm-service-using.html
You need to schedule an alarm to the next time you want to take the medicine - according to your algorithm (for example if its twice a day, and you got to the pending intent callback for the first time today, then schedule the next alarm to start after [6,7,8,9,10...] hours).
You will need to save both last time of the alarm launch and the user settings in shared prefs/file/DB.
You need to handle process down (android killed it or the device was rebooted). In the case of device reboot you should use the boot receiver to start your service, but you need to remember that from android 3.1 the user has to use at least one time the GUI in order for you to intercept the boot completed receiver. The boot completed receiver should look when was the last time that the alarm launched, and according to the user settings set the next alarm launch.
In the case of android killed your service, you will need to make research, i can't help here.
see example
I'm new to Android so I want to make sure that the following solution is the correct one.
The problem:
I want to sync the device's local database with a database on my server, via a webservice, every 10 minutes. I already have a web service call that I can make that returns the new/updated records. What I'm wondering is what is the best way to schedule this task. I want the databases to sync even when the application is not running.
My solution (is this the correct route to go?):
I will have one BroadcastReceiver that listens for android.intent.action.BOOT_COMPLETED, in it's onReceive I will create an AlarmManager that sends a message to MyReceiver (via a PendingIntent) every 10 minutes. Also, in my application's startup I will do the same (create an alarm to send messages to the MyReceiver via a PendingIntent) - Since both alarms are sending messages to MyReceiver and their corresponding PendingIntents are initialized with PendingIntent.FLAG_UPDATE_CURRENT will the new alarm override the old one? (this is what I want to do, in case for some reason the alarm gets cancelled after device boot it should be restarted when the application starts).
In MyReceiver's onReceive() I will create a MyIntentService (this instance will make the webservice call and update the local database).
Is this a good solution? Any suggestions?
Thanks
Solution is fine...Actually all the AlarmManager instances get cleared when device turned off and rebooted.
The simple way is that...
First create AlarmManager when application started.
Second in onReceive of BOOT_COMPLETED BroadcastReceiver.
Its enough, PendingIntent.FLAG_UPDATE_CURRENT will make sure of having only one activated alarm at a time.
In this way, alarm registered when your application started. There will be no issue if its already registered via BOOT_COMPLETED. Activated alarm will deactivated when you turn off your device, but BroadcastReceiver to BOOT_COMPLETED will take care of registration new alarm at next boot.
If you decide that this answers your question, please mark it as "accepted". This will raise both your and my reputation score.
Also you need to review your interval to use network, it might be very resource consuming for device and user. One policy might be to have longer period of interval and check for update when user starts your app (this might not be user friendly but can save many system resources and battery power as well). Try to find some better policy according to your needs.
Using FLAG_UPDATE_CURRENT in that manner will override the existing PendingIntent if one exists. I'm not positive but I believe that as soon as you get into onReceive, the PendingIntent is consumed so it's no longer there to be overridden. In either case, it sounds like this is the functionality you are looking for and yes it's a good way to solve this kind of problem. My only other suggestion would be if the 10 minute interval timing is not absolutely critical then use one of the INTERVAL_ schedules (INTERVAL_FIFTEEN_MINUTES for example) in your AlarmManager to help conserve battery life; basically it lets allows all apps that run on intervals to "batch" their work together and wake the device up less frequently.
Is there a way to send a notification to the user that app has been downloaded but a certain task from the app is not yet complete even after certain period - say a month. One way is a background service which should come alive every month in this case, check the app state (in sharedprefs) and then send a notification. Is there some other easier way in Android without writing custom service.
Here's how I would do it. Schedule an alarm using the AlarmManager to go off a month from today. That alarm can trigger some code inside of a Receiver or otherwise to check whether the said event has occured. If it hasn't, you can then show a Dialog or whatever.
In order to wake up your app after some amount of time (in your example a month) you're going to have to set an alarm. You can use AlarmManager for that. If all you're going to do is check SharedPreferences, you can do that in a broadcast receiver. You can send your notification there.
When an app sets a repeating alarm and from the users point of view the phone is in normal mode with an alarm in the notification bar what is happening with the code of the app? I assume the values of all the variables are stored in the phone memory in such a way that when the alarm wakes up the original state is restored. Does setting an alarm impose much more demand on the battery?
When an app sets a repeating alarm and from the users point of view the phone is in normal mode with an alarm in the notification bar what is happening with the code of the app?
AlarmManager has nothing to do with the AlarmClock application. There is no "alarm in the notification bar" unless you put something there yourself, which would be a bit unusual for an app employing AlarmManager.
Assuming you are referring to AlarmManager, "what is happening with the code of the app" is it better be shut down. The point behind AlarmManager is so you do not have to keep any code in memory just to watch the clock tick by.
I assume the values of all the variables are stored in the phone memory in such a way that when the alarm wakes up the original state is restored.
That is absolutely incorrect. AlarmManager does nothing of the sort. And, a well-written app using AlarmManager will get the heck out of memory when it is not delivering any immediate value. If you need data to persist between alarms, use databases or files.
Does setting an alarm impose much more demand on the battery?
A _WAKEUP alarm will have an impact on the battery proportional to the frequency with which the alarm goes off. If the alarm is nice and infrequent (e.g., user configured to every 15 minutes), the alarm itself will have little impact, but what you do when the alarm goes off might.