Stefan, thanks for pitching in and shedding some light on it.
Also not a deterministic approach, but at least it is not tied to the UI. Anybody else with another apporach? Cheers, Mariano On Sun, Mar 1, 2009 at 4:16 PM, StefanK <[email protected]> wrote: > > I noticed the same thing. I looked at the AlarmManger code and it > stores its data in in-memory arrays that are not persisted (nor > publicly accessible) , even more the pending intents that the > AlarmManager refers to are also lost when the device is restarted or > the application is uninstalled. (This is actually what happens when > you uninstall - it is the pending intent that gets lost not the > AlarmManager registration). > It appears that the only way to deal with pending alarms is to > reschedule them. > > What I did in my application is to register for 3 global events - in > my case Intent.ACTION_TIME_CHANGED (which occurs when the phone time > gets updated to some value manually or by syncing with the cell > tower), Intent.ACTION_TIMEZONE_CHANGED, and > Intent.ACTION_BOOT_COMPLETED. In response to any of the those events I > remove all pending alarms and reschedule them again reading the > schedules from my own storage. > This takes care of the device reboots and when the time zone changes > (for example the user takes a plane from one time zone to another). As > it turns out if your device is set to auto sync its time from the cell > tower (which is the default setting) the autosync occurs many times > during the day (my guess is when switching from cell towers to > another). Responses to the ACTION_TIME_CHANGED will restore the > schedule. > This is not an ideal solution but it is good enough for my case. (The > AlarmClock application that comes with the Android Source uses a > similar approach) > > Stefan > > On Feb 28, 10:58 am, Mariano Kamp <[email protected]> wrote: > > Hi, > > > > as far as I see scheduled alarms are lost when upgrading an > application. > > As this seems to be an un-install and re-install I can understand what. > > > > What is the best way to cope with that? > > > > When an application is upgraded it doesn't need to be launched by the > > user, so it is not the most sensible approach to use the "onCreate" > method > > of the launcher activity. Is there any other life-cycle event I can tap > > into? > > > > If that is not the case, then I would think a not-too-bad-way of > handling > > this is to hook into the onCreate method on my launch activity, an create > a > > PendingIntent with the NO_CREATE [1] flag and schedule it again with the > > AlarmManager. That shouldn't result in any change to the existing > schedule, > > if it exists, and should create the schedule when the application is > > installed for the first time or after an upgrade. > > > > It's not elegant, as it expects the user to open the app after > upgrading. > > It's not a major PITA today as the current Market expects the user to > > upgrade each app by hand and it is not unlikely that the user starts it, > but > > for the future I would expect that the Market makes automatic > mass-upgrades > > possible. > > > > Also it is not too nice to handle this logic in the UI. Furthermore it > > doesn't seem elegant to bother the AlarmManager with a new PendingIntent > > every time the app is launched. Is there anyway to query the AlarmManager > > for scheduled events, like with dumpsys alarm on the command line? > > > > Better ideas? > > > > Cheers, > > Mariano > > > > [1] > http://developer.android.com/reference/android/app/PendingIntent.html... > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
