i have a round about solution: if u need the application to exit, call system.exit.. so now u know wen its gonna exits and hence now u can write the program accordingly... (wat u wanna do wen the system exits)
but please do tell me if there is a straight forward way! cheers. On Sat, Jun 13, 2009 at 12:18 PM, Doug <dougforp...@gmail.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
