2

I've just learned about the AlarmManager and tried to play around with it. As I understood the alarms are set by saying that it needs to be called after X miliseconds like in the code below:

am.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + (sec * 1000), pendingIntent);

However, I'm concerned about the performance of system when it comes to long periods of time.

If I need to set alarm that will activate notification say after 10 months, what should I do? Do I need to convert needed period of time into miliseconds and pass it in the same way? Or there are other more efficient ways to work with long periods of time?

Marat
  • 6,142
  • 6
  • 39
  • 67
  • First of all you have to consider that all alarms are canceled upon reboot. Thus It's quite unlikely that this approach will work at all. Does it have to be exactly 10 months? An other approach could be to save the installation time (or which time you want to start from) in e.g. SharedPrefs and upon app start or boot completion you'll check the time accordingly. – Endzeit Jul 10 '16 at 07:18
  • You are right. I've read that all alarms are cancelled when phone is shut down. But, the thing is app needs to make a notification for each events that are registered in apps memory. To solve the problem I have found this answer. What do you think about it? http://stackoverflow.com/questions/9671174/alarmmanager-delete-all-schedules-on-power-off – Marat Jul 10 '16 at 07:26

3 Answers3

2

Yes, you have to pass it as milliseconds. I'm not sure why you're concerned about performance from that, there's no loss in performance form passing a large value instead of a small one. Your only real problem is that doing in X months, the length of a month isn't regular. I'd create a Calendar object for the end time and convert that to milliseconds to get it right.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127
  • Yes, of course I will take the time difference from Calendar objects. But I just needed to make sure that it will not affect on phone much. I didn't have any idea what is happening behind the scene. Thats all) – Marat Jul 10 '16 at 07:19
  • @Marat This may work in theory but as alarms don't survive reboots It's quite unlikely that this alarm will ever be called. I hope you consider any fallback solution for the case of a phone reboot. – Endzeit Jul 10 '16 at 07:22
  • I don't think I've rebooted my phone in months ☺ but yes, you do need to consider reboots. The usual solution is to wow a receiver that catches boot complete and rewrite the alarm in that receiver, so it's refreshed on reboot – Gabe Sechan Jul 10 '16 at 07:24
  • @GabeSechan Do you think this answer may help to overcome alarm deletions? http://stackoverflow.com/questions/9671174/alarmmanager-delete-all-schedules-on-power-off – Marat Jul 10 '16 at 07:27
  • Yes. That receiver is more or less what I mentioned – Gabe Sechan Jul 10 '16 at 07:28
  • Thank you! So, overall I can set any duration and it will not make phone's CPU more loaded? – Marat Jul 10 '16 at 07:32
  • Yes. Timers aren't done by busy loops. You only need to worry about performance if you have a large number going off at once, our very short times set by handlers – Gabe Sechan Jul 10 '16 at 07:35
0

Use like this

int month = 2;
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP,calendar.getTimeInMillis(),AlarmManager.INTERVAL_DAY * 30*month, pendingIntent);
Sohail Zahid
  • 8,099
  • 2
  • 25
  • 41
0

How to set alarm for long duration has already been discusses above. You just need to keep a check that if device gets restarted you reset your alarm because alarms gets canceled once system goes off.

link here

Community
  • 1
  • 1
Nayan Srivastava
  • 3,655
  • 3
  • 27
  • 49