On Wed, May 19, 2010 at 5:12 PM, JP <joachim.pfeif...@gmail.com> wrote:
> Like in your case, I have apps that need to keep (hundreds of) objects > and state variables that require retention regardless of what's going > on at the UI level. What I've done in order to pick up where I left > off after a rotation change (or, for that matter, when the user calls > the app from the main screen) is to start and bind a Service that I > bind again when the app comes out at the other end. Implement getters > and setters like you normally would to access the relevant data. The > SDK contains a pretty good example how to do all that which you can > use as a blueprint. > Hi, this doesn't really save you anything. If you are just keeping the service running during the change, then it isn't any better than keeping that stuff in globals. If you are actually keeping the service running all the time just to not have to persist your state... please do not do that, as it harms the overall user experience because you are telling the system your app needs to run all the time and it needs to kill other things to keep you running. (And we are increasingly going to have facilities for users to find out about apps doing this kind of stuff and deal with it in various ways. This is becoming my #1 target for making a better user experience.) If your application is really something that has so much going on that it needs to always be running, then you can make a foreground service with its associated notification. Then the user knows it is running, and knows how to get it to go away if that is not what they want. > The downside is that there's a risk the service gets killed as the > system is scraping for resources, but personally I haven't seen this > happen for a service that's bound to an UI thread. There's people on > the list who know much more about what's going on under the hood in > that regard, perhaps they can chime in. > The service and your activity all run in the same process. If the activity is in the foreground (which is the case during a configuration change), then the process will not be killed. It doesn't matter at all that there is a service there or that you are binding to it or anything like that. If you are using a service to keep yourself around in the background... well, these days we pretty aggressively throw long-running services farther into the background, to basically guarantee they will always eventually get killed (and then restarted in a clean process). -- 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
