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.
Related
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
Is there a way to tack the Alarm to the minute (or hour etc.?)
I know how to set an alarm that runs every n milliseconds, but I'm unclear on how to set it so that it's tacked to the clock tick... meaning, I want to set an alarm for every 120,000ms (every other minute) but I want it invoked ON the minute (not somewhere in between minutes).
You would want to use the RTC_WAKEUP option when creating an Alarm. Here is the related document describing this process.
I am creating small Alarm project which has week days option. (I am using alarm manager).
The alarm triggers perfectly on given time and day but the problem is that it also triggers any previous alarm if I change the day or time after to the given alarm time.
For eg.
If the alarm is set to ring at 5:00 AM Monday Wednesday Friday. - And the current time is 6:00PM Sunday.
And another alarm set for for 4:00PM Monday Wednesday Friday - The current time is 6:30PM Sunday.
For testing I changed the day to Tuesday 6:00PM - Immediately the two alarm triggers one by one for Monday's schedule.
How do I stop this specific alarm and trigger only next Monday rather immediately? Do I need to check the dates also???
Let me know!
You can't really. The alarm manager bases everything off of the system time. If you change the system time manually it is going to act just as if all the time had passed between now and whenever you set it for.
Edit: You can find the source code for the stock alarm application. Here is a link to one of the relavent objects Alarms.
I didn't test it any to ensure but from what I can tell they are storing the time the event is supposed to fire, and if it suddenly finds that it is in the past it ignores the alarm instead of letting it trigger. Some other relavent classes to check out are SetAlarm and AlarmClock, search for them on grepcode if you want to follow the way they set and react to the alarms in the stock app.
But it is still important to point out that manually changing the system time can still be used to manipulate the alarms. If for instance you set an alarm for 10:00pm tomorrow, then manually jump the time to 9:59pm tomorrow. The alarm will fire after 1 minute.
compare your alarm time with System.currentTimeMillis()
if your alarm time is smaller then the current time, than no need to set the alarm
I need to create a timeout feature when my app goes to the background for 5 minutes(anything that fires up onPause() except when activity is finishing). If the user goes back to the application then the timer should be cancelled.
Also, I need the timer to be not dependent on the time set in the phone meaning when the app goes to the background and then the user changes the time the application will still timeout within 5 minutes.
Checking out the documentation of the AlarmManager it states the following:
Note: 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.
Alternatively, you could try setting up bound service - these can operate in background even if user toggles frontmost application. you can communicate with the service using Handler, just as you would do with threads.
the easiest would be to use sendEmptyMessageDelayed of predefined type and use call to removeMessages() once your app is back on top.
You should take a look at the AlarmManager. You can easily program your app to run at a specific time or every 5 minutes with a PendingIntent. You can cancel it with the same PendingIntent.
I don't know about the time dependency but it's easy to test.
in onPause() set an alarm using AlarmManager, like this:
AlarmManager alarmManager = getSystemService(Context.ALARM_SERVICE);
// Alarm time is elapsed time since boot (including sleep) plus 5 minutes
long alarmTime = SystemClock.elapsedRealtime() + 5 * 60 * 1000;
alarmManager.set(AlarmManager.ELAPSED_REALTIME, alarmTime, pendingIntent);
For the pendingIntent() you can use either a broadcast Intent or you can have it start one of your activities. Depends what you want to do when the alarm goes off.
NOTE: Using AlarmManager.ELAPSED_REALTIME ensures that changes the user makes to his date/time settings won't have any effect on your 5 minute timeout.
Make sure to cancel the alarm when your app resumes (in onResume()) and when it finishes (in onDestroy())
I wonder if the easiest solution wouldn't be to just set a value in sharedPreferences when your activity pauses and test this value again onResume. To avoid the value being corrupted by the user changing the clock you could employ SystemClock.elapsedRealtime() or SystemClock.uptimeMillis()
I want to set a repeating alarm monthly; but my app resets the alarm everytime it boots up. So is it bad practice to do it this way rather than setting a repeating alarm?
(The Alarm is set for a specific day of the month. (e.g. The 8th, 16th, 21st, etc). So if it is past that day, it simply +1's on the total the current month.)
I also run a service on boot up to set any alarms so even if they don't go into the app for a month, it will be reset again.
Again, is this the best way of doing this or is this bad practice?
So is it bad practice to do it this way rather than setting a repeating alarm?
If it works for you, it is probably fine.
I also run a service on boot up to set any alarms so even if they don't go into the app for a month, it will be reset again.
That is a little odd. Getting control at boot time to re-establish alarms is fine, but you should not need a service for that.