Leigh McRae wrote: > Thing is > that the docs says onSaveInstanceState() will be called before > onPause()
No, it doesn't. In fact, it says just the opposite: "If called, this method will occur before onStop(). There are no guarantees about whether it will occur before or after onPause()." http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle) > but how does the system know at this point whether the > activity will be killed by the system or the user? First, it doesn't matter in most cases. Second, onSaveInstanceState() may be called seconds or days before the process is killed, depending on what the user is doing. Third, the process is not typically killed. Usually, activities will be destroyed gracefully, going through onStop() and onDestroy(). A process termination is required only when there's an emergency need for RAM. Fourth, "the system" knows whether the user pressed the BACK button. > Here is a use case: > > 1) My activity starts up and is running. > 2) At some point I want to show a web page so I use an Intent to start > an activity. > 3) The web browser covers my app/activity so I would expect onPause() > to be called followed by onStop(). Correct. > At this point it's my understanding that all bets are off and I can be > killed at any point without be called. Correct. Unlikely, but correct. > 4) Since the system has enough memory onSaveInstance() doesn't get > called. I have no idea where you came up with this. I would expect onSaveInstanceState() to have been called in this scenario, before onStop(), and around the time of onPause(). > 5) The user presses home and decides to open some app which requires a > lot of memory. > 6) System wants more memory and decides to kill my app but I am > already stopped (onPause() has been called). What happens here? Your app sees a bright light at the end of a tunnel, with the sound of harps in the background. Unless it's malware, in which case there's the strong odor of fire and brimstone. :-) > I am finding this a really serious problem since onPause() pretty much > needs to be treated as onDestory() as far as I can tell. If my app has > to be able to survive being killed without onStop() and onDestory() > being called, why bother having them? Because the process is generally not killed. That's like asking why we bother returning values from methods, because a method might raise a RuntimeException at any point, so why bother returning values? The reason we return values is because it's useful and random RuntimeExceptions are, er, the exception. Also, bear in mind that if your process is killed, a lot of cleanup you might ordinarily do in onStop() or onDestroy() (e.g., unregister listeners, stop threads) is no longer relevant. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android App Developer Books: http://commonsware.com/books -- 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
