Could I suggest an update to documentation then? Do you guys need a bug report to be lodged to do this kind of thing? Does this also apply to services? The documentation there also states that the service will be sent a 'courtesy' stop notification... I think things could go quite badly if the code were to just stop in the middle of (say) a database update.
On Jun 12, 6:29 pm, Dianne Hackborn <hack...@android.com> wrote: > Application.onTerminate() is actually never ever called. The only time it > is ever called is when the system is running in single process mode, and > faking processes as multiple threads in one single process. This was the > way the system was running very early in development, and onTerminate() was > needed for applications in that situation to clean up their globals, but > these days it is just old useless cruft. > > And as far as the OS deciding to kill your process... well, you don't care > about that. It killed your process. Everything your process was doing, all > the network connections it had opened, all the threads it had running, are > gone. No effort needed on your part there. :) > > On Fri, Jun 12, 2009 at 11:29 AM, Streets Of Boston <flyingdutc...@gmail.com > > > > > wrote: > > > My solution works fine to check if you have a configuration-change or > > not. > > But it won't work in case the OS decides to kill the process, e.g. > > when memory runs low or when the phone is shut off. The Application's > > onTerminate, as Mark noted, may help a little, but it's not guaranteed > > that this method is called. > > > On Jun 12, 2:16 pm, Max Salley <msalley....@gmail.com> wrote: > > > On Jun 9, 1:58 pm, "Mark Murphy" <mmur...@commonsware.com> wrote: > > > > > > Yes, but when the app closes I want to close the connections (which > > > > > requires sending data - not just releasing the objects) regardless of > > > > > what's holding them. How can I tell when the app exits? > > > > > I think you are attributing too much power to the notion of apps > > exiting. > > > > > Example #1: somebody is using your app. Then a phone call comes in. > > Your > > > > activity is merely stopped, not destroyed. Did your app "exit"? > > > > > Example #2: somebody is using your app. Then a phone call comes in. > > > > Courtesy of a Bluetooth headset, the user yaks on the phone while also > > > > TXTing a few people, then gets a URL in an SMS, which leads to a Web > > site > > > > in the Browser app. All along, your app's activities are back in the > > > > stack, in a stopped state. An hour passes this way. Did your app > > "exit"? > > > > > Example #3: Same as example #2, but the user then had to go to class, > > and > > > > so she thumbs off her phone, sticks it in her purse, and leaves the > > phone > > > > asleep for eight hours. Then, a call comes in. Your app's activities > > are > > > > still back on the stack, in a stopped state. Did your app "exit"? > > > > > Example #4: Same as example #3, but the user responds to enough calls > > and > > > > messages after the 8-hour device sleep that Android closes up your > > > > activities to free up RAM. Placeholders for those activities are still > > > > back on the stack, though, and if the user were to back-button to them, > > > > they would want to pop back up. Did your app "exit"? > > > > Yes, those are all instances in which I would consider the app exited > > > > > You can try things like creating custom Application classes and > > responding > > > > to onTerminate(), but I suspect you have broader problems if you worry > > > > about apps "exiting", since onTerminate() may not be called in any of > > > > those examples. > > > > > Protocols that require you to send network data before closing a > > > > connection will suck mightily in any mobile environment, simply because > > > > the device can and will fall asleep at any point. Android's usage > > model, > > > > whereby users are not concerned with having to specifically "exit" > > apps, > > > > exacerbates that issue. > > > > "required" was the wrong word. It would be insane for an app not to > > > be able to deal with a mobile device dropping off the face of the > > > earth, so to speak. When possible, however, I would like to be able > > > to be able to tear down the connection in a controlled fashion. > > > Boston's solution seems to be what I want > > > > > -- > > > > Mark Murphy (a Commons Guy)http://commonsware.com > > > > _The Busy Coder's Guide to Android Development_ Version 2.0 Available!- > > Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > -- > 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 -~----------~----~----~----~------~----~------~--~---
