On Jun 9, 1:58 pm, "Mark Murphy" <[email protected]> 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!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
