So, given that the functionality should be there,
why is the AlarmClock App (from Google!) not working yet?
http://code.google.com/p/android/issues/detail?id=1942
Is that a bug in the application, in the system, in the hardware or
something else?
Thanks
M
On Mar 30, 11:09 am, Dianne Hackborn
On Sun, Mar 29, 2009 at 5:58 PM, gjs garyjamessi...@gmail.com wrote:
(1) Is it recommended that a Service which runs for more than a few
seconds always use a wake lock in an attempt to ensure it completes ?
It's not really a matter of how long you run. If you want to run at all,
and don't
Dianne and Mark,
I just wanted to thank the both of you for your help on this. Your
suggestions worked beautifully. My application has been running
several hours on two different phones and it has not missed a
scheduled event yet.
Just in case the two of you don't hear this enough, I for one,
Hi,
Great thread, one of the best I've read here in a long time.
A few related questions -
(1) Is it recommended that a Service which runs for more than a few
seconds always use a wake lock in an attempt to ensure it completes ?
My limited tests on a G1 seem to show that a Service that runs
I am very much looking forward to Mark's writeup. I think that the theory is
sound, but that it is ugly to pass in the wake lock in practice. I use a
static member for that and it makes my eyes bleed. And it makes it harder to
handle cases where start is called more than once.
On Sat, Mar 28,
Mariano Kamp wrote:
I use a static member for that and it makes my eyes bleed.
Umm...hmm...well...er...
If you want your service to completely go away between alarms, you need
your BroadcastReceiver to be registered via the manifest, rather than
tied into the system via registerReceiver() in
There is one more thing I'd like to add that I think you haven't covered yet
... and probably don't need to, but I want you to be aware of that.
I have an app that synchronizes with Google Reader every hour (alarm) and
also the user can run a sync manually. So both need the background service
to
Mariano Kamp wrote:
Now you would have two active wake locks and actually when using a naive
approach to a static variable you would have overwritten the old wake
lock, which would lead to the old lock not being releases which would
lead to the phone not shutting down.
Have you tried using
On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy mmur...@commonsware.comwrote:
Have you tried using setReferenceCounted(true) on the WakeLock?
No, I didn't know about that. Sounds interesting. Thanks for the pointer.
In the scenario you described:
-- The activity tells the service, yo! sync
Mariano Kamp wrote:
On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy mmur...@commonsware.com
mailto:mmur...@commonsware.com wrote:
Have you tried using setReferenceCounted(true) on the WakeLock?
No, I didn't know about that. Sounds interesting. Thanks for the pointer.
In the
Sorry this is currently such a pain.
First, don't use registerReceiver(). Having a service always running is a
-huge- waste of resources. In fact this will probably be
counter-productive, because as the system gets low on resource and starts
struggling to see what it can free up, it will see
Dianne Hackborn wrote:
Yes you need to use a global variable for the wake lock. Gross, but it
works.
OK, here's a cut at a sample app:
http://groups.google.com/group/cw-android/web/Alarm.zip
[NOTE: If you found this message in the archives and are reading it
after June 1, 2009, please visit
clarkbriancarl wrote:
The best I can get in a 24 our period for an
alarm scheduled every 10 miutes is about 75% (110 out of 144 repeating
alarms). I have tried varying this interval from 1 minute to 30
minutes with the same result. I have tested on a non-rooted T-Mobile
both 1.0 and 1.1
Hi Mark,
THanks for the reply. I use your book as a reference from time to
time. I would recommend it to anyone reading this.
Before I open an issue, I would like to hear from other developers to
see if their experiences have been similar, and if not, do some code
comparison to see what they
clarkbriancarl wrote:
THanks for the reply. I use your book as a reference from time to
time. I would recommend it to anyone reading this.
Thanks!
Before I open an issue, I would like to hear from other developers to
see if their experiences have been similar, and if not, do some code
Hard to judge without any code.
Do you use AlarmManager.RTC_WAKEUP?
On Fri, Mar 27, 2009 at 5:45 PM, Mark Murphy mmur...@commonsware.comwrote:
clarkbriancarl wrote:
THanks for the reply. I use your book as a reference from time to
time. I would recommend it to anyone reading this.
And are you using a partial wake lock? Note that if you absolutely need to
run even when the device is asleep, this can be a little tricky -- you need
to deliver the alarm to a broadcast receive (the alarm manager holds a wake
lock during this time), acquire a partial wake lock there and start
Dianne,
I have used both AlarmManager.ELAPSED_REALTIME_WAKEUP and
AlarmManager.RTC_WAKEUP.
I am currently setting a repeating alarm attached to a pending
intent in the GUI portion of the application. The pending intent
starts the service.
objPendingIntent =
Please read again my explanation about what you need to do to keep the
device from going to sleep -- you need to have the alarm sent to a broadcast
receiver, which immediately acquires a partial wake lock, which then starts
the service, and the partial wake lock is not released until the service
Dianne Hackborn wrote:
This is unfortunately tricky to do right now; in the future we would
really like to make wakelock management easier for these situations.
You ain't just whistlin' Dixie -- it took me a while to figure out how
to implement it, and that was even *after* you described the
On Fri, Mar 27, 2009 at 5:03 PM, Mark Murphy mmur...@commonsware.comwrote:
You ain't just whistlin' Dixie -- it took me a while to figure out how
to implement it, and that was even *after* you described the pattern.
Heaven help me if I'd've been trying to noodle that out independently.
Yeah
21 matches
Mail list logo
