[android-developers] Re: Widget process lifetime: Why not stop the service?
On Sat, May 23, 2009 at 12:50 PM, Michael Elsdörfer mich...@elsdoerfer.info wrote: From what I understand, a service must be used in any case to avoid ANR when processing the request might take a bit longer. Oh sure, if you are going to do some longer-running -continuous- work then use a service. Don't use a service to sit there and do nothing but schedule future work (which is what you seemed to be describing in your first post). The widget example on the developer blog uses a service as well, but does not call Service.stopSelf() when done. Hm. Bad sample code! No cookie! I'll see about getting that fixed. In the meantime, consider stopping a service when it is done with its work to be a Good Thing. :} -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Widget process lifetime: Why not stop the service?
Don't use a service; use the alarm manager to schedule your wakeup/work. On Sat, May 23, 2009 at 9:38 AM, Michael Elsdörfer mich...@elsdoerfer.infowrote: I'm writing a widget that needs to update rather infrequently (say multiple hours). Following the source examples out there, it seems the common solution is to use a service to prepare the updates. However, after I am done, my process is still running on service level, it looks like it's not being killed by Android in low memory conditions, and killing it manually causes it to restart. The same seems to be true for all other widgets I have installed so far - they stay in memory. Wouldn't it be better to have to service call this.stop() when it is done, at least if the widget knows it probably won't need to do another update any time soon? I'm doing this now, and it seem to work fine - my process is being killed when Android needs memory. I'm confused though as to why this wouldn't be the encouraged behaviour then (it's not like the G1 has an aweful lot of memory to spare). Should or shouldn't I be doing this? -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Widget process lifetime: Why not stop the service?
Don't use a service; use the alarm manager to schedule your wakeup/work. Currently I'm actually using the widget framework's update mechanism. From what I understand, a service must be used in any case to avoid ANR when processing the request might take a bit longer. The widget example on the developer blog uses a service as well, but does not call Service.stopSelf() when done. Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
