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 <johan.wal...@gmail.com> 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 <emez...@gmail.com> 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 <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. > > > -- 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 -~----------~----~----~----~------~----~------~--~---
