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

Reply via email to