I'm not a big fan of doing double bookkeeping like this, but it should be doable here if I have a Preference stored with the time at which I expect the next alarm to trigger. Then I could just unconditionally re-trigger that alarm both from the UI and from the sampler.
That said, I still feel that I'm trying to duplicate the AlarmManager's bookkeeping here, and just being able to ask it about its state would feel cleaner. Thanks for all your feedback! Regards //Johan On 16 Sep, 18:33, Dianne Hackborn <[email protected]> wrote: > You have to be receiving BOOT_COMPLETED to get your initial alarm. When you > get BOOT_COMPLETED, you know that you are at the initial boot of the system. > You can set up for whatever initial behavior you want at that point. > Also, you could simply have some persistent data about the alarms you have > scheduled and look at that. You are the ONLY one scheduling your own > alarms. Nobody is changing them behind your back. You know exactly what > you are doing. So just write it to do exactly what you want. > > > > On Wed, Sep 16, 2009 at 4:43 AM, Walles <[email protected]> wrote: > > > 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. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
