All you need to do is to set different request codes in your pending intent parameters to avoid this situation: "The setting of this new alarm, and the throwing out of the existing alarm is what I want to avoid."
A correction to one line of code would let you use the alarm manager (sorry if my earlier post was unclear). You might further improve by using a Handler, thread or Async Task to collect your second sample after a 15s sleep and then trigger a repeating alarm every ten minutes thereafter. To be clear, a phone reboot will cancel the repeating alarm but you can catch the event and restart. Good luck! On Sep 15, 10:31 pm, Walles <johan.wal...@gmail.com> wrote: > The race is on then, we'll see who's the first to market! Cheers :-) / > J > > On 16 Sep, 06:44, Dianne Hackborn <hack...@android.com> wrote: > > > Um, 1.6 will do this, and is probably what I would say is the "right" way in > > that the implementation is very closely integrated into the system to > > monitor CPU usage, network usage, wakelock usage, screen usage, etc, etc. > > > On Tue, Sep 15, 2009 at 5:02 AM, Walles <johan.wal...@gmail.com> wrote: > > > > Good point :-), here's the plan: > > > > I'm writing an app to find out what apps are using the most CPU time > > > (which I hope will correlate with battery drain). It's possible to > > > get a snapshot picture of this by looking at /proc: > > > >http://bazaar.launchpad.net/~walles/drain-o-meter/trunk/annotate/head...<http://bazaar.launchpad.net/%7Ewalles/drain-o-meter/trunk/annotate/he...> > > > > A single snapshot picture will however miss apps that start, run for > > > some time and then exit. > > > > So what I want to do is to take *regular* snapshots. I take the > > > difference between the last two snapshots and add the difference to a > > > process name -> number of ticks Map. > > > > Snapshotting rules are: > > > * Snapshots should be taken at regular intervals. > > > * The first two snapshots should be taken in quick succession to be > > > able to quickly present the first measurement to the user. > > > * It must be possible for an UI app to look at the result of the > > > snapshotting. > > > > To get the whole thing going, I'm letting the UI part of the > > > application start the sampler in the background. When the sampling is > > > first started it needs to take two snapshots quickly (see above). The > > > rest of the samples should be taken at longer intervals. > > > > I first tried to do this using alarms, but I didn't manage to get the > > > "two quick samples first and the rest further apart" behavior with > > > alarms: > > >http://bazaar.launchpad.net/~walles/drain-o-meter/trunk/files/39<http://bazaar.launchpad.net/%7Ewalles/drain-o-meter/trunk/files/39> > > > > I now have a working implementation with a background service: > > >http://bazaar.launchpad.net/~walles/drain-o-meter/trunk/files/57<http://bazaar.launchpad.net/%7Ewalles/drain-o-meter/trunk/files/57> > > > > Suggestions on how I should *really* be doing welcome :-). > > > > Cheers //Johan > > > > On 9 Sep, 16:47, Mark Murphy <mmur...@commonsware.com> wrote: > > > > Walleswrote: > > > > > I'll use a Service instead of an Alarm and keep it running in the > > > > > background. That way I can keep track of it myself. > > > > > Please don't. For starters, it won't work, since the service may get > > > > killed off by the user or the system. Also, while the service is in > > > > memory, you are taking up one process' worth of RAM. > > > > > If you could explain to us what the effect is you are trying to achieve > > > > (versus low-level technical statements, like "not to overwrite an > > > > existing alarm with a new one"), we might be able to suggest alternative > > > > patterns. > > > > > -- > > > > Mark Murphy (a Commons Guy)http://commonsware.com| > > >http://twitter.com/commonsguy > > > > > _Android Programming Tutorials_ Version 1.0 In Print! > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see and > > answer them. > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
