Let's say I change my code to: Pseudo code for the UI: 1. Set an updating alarm in 15s, request INITIAL. 2. Show UI based on existing data.
Pseudo code for the sampler: 0. If INITIAL, and we have samples in the database, return without doing anything. 1. Take a sample and store it in a database. 2. Schedule a new alarm in 10 minutes, request KEEP_GOING. Was that what you had in mind? Then let's assume i re-start my phone, and launch the UI: 1. UI sets an alarm requesting INITIAL. 2. The sampler receives the alarm, sees that there are already samples in the database, and never initiates the sample-and-set-up-another- alarm chain. So in the above case I still don't see how I can get around not being able to check for pending alarms :-(. Regards //Johan On 16 Sep, 08:14, Beth <[email protected]> wrote: > 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 <[email protected]> wrote: > > > The race is on then, we'll see who's the first to market! Cheers :-) / > > J > > > On 16 Sep, 06:44, Dianne Hackborn <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > > [email protected] > > > > 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 [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 -~----------~----~----~----~------~----~------~--~---
