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 -~----------~----~----~----~------~----~------~--~---
