What is the best way to implement repeating alarm in my android application? Every user selects a specific time and I want to notify them when this time approaches on daily bases. I have come across this, but I am wondering whether this is the best way?
The alarm manager should meet your needs. There is no better way except for maybe having a server ping your client.
Since android really doesn't like things that repeat on a predictable interval, and since recent versions don't let you repeat on an exact fixed interval anyway, you'll need to schedule the alarm at the time you want, and then when that alarm fires, schedule a new one for the next day at the time you want.
use
alarmManager.setRepeating(AlarmManager.RTC_WAKEUP, alarm_time,
intervel, pendingIntent);
in your activity
Related
For setAlarm() parameter : Should I use SystemClock.elapsedRealtime(), calander,getTimemillise or something?
Because Alarm is coming fine, but when I manually go to my Android phone date & time settings and change the time (not past, but future time), alarm is not coming and triggers immediately.
This is an intended behaviour as specified in the official Alarm Manager docs for all the set methods.
If the stated trigger time is in the past, the alarm will be triggered immediately.
to manage you can try to cancel such alarms with past trigger time in your reciever .
How to choose between
System.currentTimeMillis() vs SystemClock.elapsedRealtime()
As the link specifies the :-
The first method, will give you the standard "wall" clock (time and date) expressing milliseconds and is affected by and changes in time and date from the settings.
While the second method, return the time in milliseconds since the system was booted, and including sleep time. Hence would not be affected with the changes in the settings so it is the recommend basis for general purpose interval timing.
So if you do not want the time to be dependent on the time-zonal changes , it is better to use the second method.Otherwise you need to handle it as mentioned before.
As compared to other alternatives like Date or Calender , it is better to use currentTimeMillis() due to performance benefits.
Android beginner here:
i'm writing a pills' reminder app using alarmManager, but i was wondering if i need to implement a daily scheduler and a database to store the alarms that don't need to set off today, or does the alarmManager do everything by itself, avoiding excessive performance issues and battery drain? i'm asking it because, let's say that we have 30 alarms per 30 pills every week, i think that having all the alarms "ticking" when i only need to take a couple of pills a day is very expensive.
I tried to read the documentation but it's seem very generic.
thank you
If you really want to use AlarmManager to set repeating reminders, the Android Developer Docs recommends AlarmManager.setInexactRepeating() which allows you to set intervals like AlarmManager.INTERVAL_DAY to repeat everyday and synchronizes repeating alarms from multiple apps to fire at the same time. If you want to consider other options instead of AlarmManager you should watch this talk from Joanna Smith https://www.youtube.com/watch?v=7maNuWjL3Wc
I am implementing a widget that checks on-line train departure times between every minute and every hour, depending on the time of day.
Calling the service with
manager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
SystemClock.elapsedRealtime() - 10000, 60000, pendingIntent)
works fine, but for debugging I would like to reduce the interval to about 10 seconds which cannot be done because of the 1-minute limit in more recent versions of Android. Clearly, I don't care about battery life in the emulator.
As far as I understand, using an Hander/Timer is not an option, because it required the task to be in the foreground. Is a visible widget "in the forground"?
What is the recommended practice in this case?
you actually have to tasks
configure the alarmmanager to add/remove trigger events via intents
interprete the events with intents in a service
If you seperate both you can easily create a very simple gui/activity that does the same as the alarmmanager would do when being triggerd and that you can debug:
* onSendButtonClick: create and send pendingIntent
for the alarmmanager-handling i would implement logging into a text file each time alarmmanager is added/removed/triggered.
Be prepared that newer android versions may postpone alarmmanager events to save energy until the device is already active and that intervals less than 15 minutes may not work.
you may also need on_boot_complete to reconfigure alarmmanager after device-shutdown
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 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.