the cancel previous alarm strategy is interesting. if I only care that the alarm work if the app has been run at least once, then I could do away with the BOOT_COMPLETED stuff completely and whenever the app was run, just always cancel any alarms with a known pending intent and trigger a new one.
then even if the app is closed, the app is task-killed, the phone is rebooted, etc... as long as the app has been run at least once, the behavior with regards to alarms should be the same (the same as whether or not I have the BOOT_COMPLETED code in there)?? On Jan 11, 11:51 am, Mark Murphy <mmur...@commonsware.com> wrote: > sdphil wrote: > > okay, that seems helpful, but it would be even better to be able to > > ask the alarm manager if I have already registered for an alarm -- or > > there is already an alarm registered at that looks like I did it. > > Agreed. Though there is a trick you can use. > > Back in the day, I wrote apps for OS/2. > > :: insert memory fading/shimmering effect here :: > > OS/2 did not have an API to tell if a process was running. However, if > you called the terminate-process function, you'd get a boolean flag back > indicating if the process had been terminated. As a result, we used to > joke that the only way to know if a process was running was to kill it > -- you'd then know if the process was running...and you'd also know the > process was then no longer running. > > Similarly, AlarmManager has a cancel() method, if you're concerned about > possible duplicate alarms. > > > I think the method you proposed would work for a clean install, but > > things get messy when you start re-installing / installing over an > > older version. the older version may or may not have had the > > BOOT_COMPLETED stuff in there. now I gotta keep track of versions in > > my code to know whether or not I need to register the alarm? > > I don't know if an alarm survives an upgrade by default or not. I'm > thinking that it doesn't, as I think the same API those task-killer apps > use gets called before the upgrade. However, that's just a guess. > Regardless, you can arrange to get control on the upgrade, so you can > always cancel() the existing alarm (if there was one) and reschedule it. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android Consulting/App Development:http://commonsware.com/consulting
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
