I was actually referring to the "android.app.Application" object
http://developer.android.com/reference/android/app/Application.html Obviously there are no guarantees, but this might be a better way for Max to *try* to determine whether the application is shutting down or an Activity is merely being closed. On Jun 11, 10:35 am, Streets Of Boston <flyingdutc...@gmail.com> wrote: > Note that the onDestroy (or the onStop) are not always called when > your activity exits/ends. > Read the info on developer.android.com and look at activities' life- > cycle events. > A process can be killed, and the only thing guaranteed to be called in > your activities is onPause, and possible onSaveInstanceStatie() > > On Jun 11, 12:43 pm, Doug <dougforp...@gmail.com> wrote: > > > Max, > > > Take a look at the application object that your app can optionally > > have. It is creaated (and has onCreate called) before any of your > > other activities or services even get out of the gate. > > > It also has onDestroy method that is called when Android shuts your > > app down (unrelated to activities coming and going). > > > Hope this proves useful. > > > Doug > > > On Jun 9, 10:58 am, "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"? > > > > 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. > > > > -- > > > 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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
