The documentation on onSaveInstanceState() states:
If the method is called, it is always called before onStop() and possibly before onPause().
But, I notice, consistently, from log messages that onPause() is ALWAYS CALLED BEFORE onSaveInstanceState(). I had put log messages in these two methods. Please help me understand in what circumstances does onSaveInstanceState() is called before onPause().
Environment: Android v4.0 (API 14) + Eclipse v3.7.1 - Indigo.
You can read about that here.
In a nutshell you can't never know about time when onSaveInstanceState will be run.
Please help me understand in what circumstances does
onSaveInstanceState() is called before onPause()
There is a difference in the Activity lifecycle between the pre-HONEYCOMB and the other platforms (since HONEYCOMB onwards):
API level >= 11: when onPause() is called, the process is in a safe state, it can't be killed.
API level < 11 : when onPause() is called, the process that hosts the Activity becomes killable. It means that the system can kill the process, that contains the activity, without executing any other line of code. So if this happens the onSaveInstanceState() may never be called. In order to avoid this, the system should call onSaveInstanceState() before onPause(), otherwise you will not able to save the user state.
onSaveInstanceState() is nice, but only guaranted callback is onPause(), called when your activity loses focus. So, save your state there
Related
I'm testing that my app is able to recover from unexpected situations that lead the OS to kill my app's process due to different circumstances like low memory. To do this, I've enabled "Don't Keep Activities" in Developer Options.
I'm attempting to restore the app's state by saving state values in the Activity's Bundle through the lifecycle method onSaveInstanceState, but after setting breakpoints I've noticed that onSaveInstanceState does not get called.
Question:
Am I wrong in expecting onSaveInstanceState to be called in this scenario or might there be other factors that are preventing the method to fire? If neither, what else can I do to recover the state in this scenario?
I think two possibilities are supposed.
Your scenario is wrong
The official reference says:
Do not confuse this method with activity lifecycle callbacks such as
onPause(), which is always called when the user no longer actively
interacts with an activity, or onStop() which is called when activity
becomes invisible. One example of when onPause() and onStop() is
called and not this method is when a user navigates back from activity
B to activity A: there is no need to call onSaveInstanceState(Bundle)
on B because that particular instance will never be restored, so the
system avoids calling it. An example when onPause() is called and not
onSaveInstanceState(Bundle) is when activity B is launched in front of
activity A: the system may avoid calling onSaveInstanceState(Bundle)
on activity A if it isn't killed during the lifetime of B since the
state of the user interface of A will stay intact.
If your scenario is a 'no need to call' case, onSaveInstanceState won't be called.
Your breakpoints are wrong
If called, this method will occur after onStop() for applications
targeting platforms starting with Build.VERSION_CODES.P. For
applications targeting earlier platform versions this method will
occur before onStop() and there are no guarantees about whether it
will occur before or after onPause().
So the timing of onSaveInstanceState called depends on your targeting platform.
An easy workaround is to backup data with SharedPreference, etc. in onPause.
Through Android's Activities doc, it is said that the methods onStop() and onDestroy() are not guaranteed to be called.
[...] once the activity is created, onPause() is the last method that's guaranteed to be called before the process can be killed—if the system must recover memory in an emergency, then onStop() and onDestroy() might not be called [...]
I would like to know, when this situation occurs, is the app also killed within the activities or just the activity itself is killed?
Answer is app process is also get killed and can be recreated.
https://developer.android.com/training/basics/activity-lifecycle/recreating.html
Please check http://www.vogella.com/tutorials/AndroidLifeCycle/article.html
Application with only stopped activities and without a service or executing receiver. Android keeps them in a least recent used (LRU) list and if requires terminates the one which was least used.
I read all about the activity lifecycle and it's methods.
I still couldt find an answer:
When I close my app, from the "open apps" menu (in galaxy4 it's a long press on the home button, in nexus5 it's the right button ...) what method is being called? if any?
In other words, my activity is launching a service.
I want to terminate the service if the app (activity) is being closed.
(onDestory is not reliable at all as said many times here before)
Thanks in advance!
onPause() is the only method that is called always. From onPause() state Android OS can kill this app for many reasons bypassing onStop and onDestroy. I don't think we can control this behavior of unexpected termination smoothly. Service can check for the state of the application periodically.
You will go through onPause() then onStop(). On pre-Honeycomb (API 11) devices, your app can be killed at any time after onPause() returns. No more methods called, period. Post-Honeycomb you will at least get onStop().
Locate with life cycle activity, one sugestion: http://developer.android.com/training/basics/activity-lifecycle/stopping.html
The system call the onPause(), after onStop() and last onDestroy(). You must analyze the best form for include your method. Pay attention in this moment.
I have an activity and I have a fragment stack in it and sometimes, this stack get's lost... Although I save and restore it...
I know following:
onSaveInstanceState is not called:
a) if the user navigates back, which makes sense...
b) if the activity is finished
onSaveInstanceState is called:
a) on screen rotation
I discovered through debugging, that I can't be sure, if onSaveInstanceState is called, if screen turns black...
My app is an app, that you use for logging, meaning, you put your phone aside and come back every now and then and fill out your log... So sometimes, my activity is recreated with an empty bundle and onSaveInstanceState was not called, although my app was in the foreground and only the screen turned off...
Questions
1) what can I do to solve that problem? Do I really have to save my fragment states and the stack persistantly?
2) on screen rotation, I can be SURE that onSaveInstanceState is called, can I? Are there any other circumstances, where I can rely on onSaveInstanceState?
1) Im reffering to this thread: android life cycle you should use onPause() because you can't be sure if the app is just paused or beeing killed.
2) from developer.android.com ( Activity)
Be aware that these semantics will change slightly between
applications targeting platforms starting with HONEYCOMB vs. those
targeting prior platforms. Starting with Honeycomb, an application is
not in the killable state until its onStop() has returned. This
impacts when onSaveInstanceState(Bundle) may be called (it may be
safely called after onPause() and allows and application to safely
wait until onStop() to save persistent state.
I seem to have the opposite problem to everyone else. :)
My onSaveInstanceState is getting called whenever I navigate from one activity to the next.
I checked in LogCat and it is definitely NOT killing the activity.
Also, I see that the onRestoreInstanceState is not called when returning so it must have still been in memory.
I thought it was only called when freeing up memory or during orientation changes.
Yes, onSaveInstanceState() is called when the activity is paused. This is because once the activity is paused, Android can kill the process at any time time (without calling any other lifecycle methods). If the activity is resumed before the process is killed, Android realizes that it doesn't need to call onRestoreInstanceState() so it doesn't make that call (this is an optimization).
What about the doc saying;
"If called, this method will occur before onStop(). There are no guarantees about whether it will occur before or after onPause()."