Hi Mark,
The application schedules wall-paper changes, originally I was using
Timers, but this meant the application had to be resident all the time,
now I'm using the AlarmManager to schedule rotations, I've limited the
maximum rotation to 1 second, although in reality I wouldn't expect
anyone to set it that low.
Regards,
Simon
On 14/06/2011 8:29 PM, Mark Murphy wrote:
On Tue, Jun 14, 2011 at 3:23 PM, Mark Murphy<[email protected]> wrote:
On Tue, Jun 14, 2011 at 3:16 PM, Simon Platten
<[email protected]> wrote:
In my activity I let the user change the alarm time interval, this is then
applied to the alarm manager, but if I set one alarm running at 1000 ms,
then cancel it and set again to be 60000ms, the previous alarm still fires,
Do not use AlarmManager for things to be invoked every second. What
exactly is this application supposed to be doing?
To elaborate, there's a point at which the churn that AlarmManager can
cause may be more abusive on the device than simply keeping the
service running all the time and using a Handler and postDelayed, or
Timer/TimerTask, to get control again every so often. I don't know
exactly where the break-even point is, but I suspect that is is more
than one second.
So long as your service is designed to only be used occasionally on
demand (e.g., user starts it, you run for a while polling along, then
the user stops it), fast polling can be OK. If, however, you are
anticipating doing something every second indefinitely... well, that's
why users task-kill and force-close services.
That's why I'm asking what the application is supposed to do -- to try
to give you some advice for how to address all this.
--
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
