I have an object that implements Parcelable so that when the screen is rotated, the data is deserialized and display on screen. However, when I press the back button and click on activity "A" again, the data isn't there anymore. Why is onSaveInstanceState null after you press back button?
When your activity is destroyed because the user presses Back or the activity finishes itself, the system's concept of that Activity instance is gone forever because the behavior indicates the activity is no longer needed.
onSaveInstaceState will have value only if the activity is Recreated by the system.
Check Recreating an Activity for more info.
When a user knowingly leaves the Activity, the onSaveInstanceState is not called. It is called when the system destroys and recreates the Activity.
For this reason, you are getting null in onRestoreInstanceState.
Refer -
http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState%28android.os.Bundle%29
Related
I've two activities, A and B.
My app goes from A to B. (A -> B).
When I'm on B and press the back button (hardware back button) the state and UI of A is restored successfully (onResume() is being called).
The problem is, when I press the home button (Actionbar arrow) the previous Activity A calls onCreate() so its state and UI won't be restored as with back button press.
Why is this happening? How can I solve it?
It seems you create a new instance of Activity A when you hit the up button on the ActionBar, instead of going back to the already existing Activity A.
You should override the listener that is invoked when you press the button and call finish() on Activity B instead. So the behavior will be the same as pressing the device's back button.
http://developer.android.com/training/basics/activity-lifecycle/recreating.html
Google has a great discussion on the Developers website. Anytime you leave the app you must save information needed to recreate the last state of Activity A because the system can remove your app from the cache at anytime after it closes. So save important db keys etc... into a file on the system with those keys needed to reload the activity. This will also handle orientation changes for you. The important lifecycle methods are onPostResume to restore state and onStop and onDestroy to save state.
Read about activity lifecycle too.
Hello I am just a little confused after reading these materials on Tasks and Back Stack, Android Developer Guide:
It says:
When Activity A starts Activity B, Activity A is stopped, but the system retains its state (such as scroll position and text entered into forms). If the user presses the Back button while in Activity B, Activity A resumes with its state restored.
While in the APIs reference for onSaveInstanceState() method, it says:
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.
The above two situations seem identical to me ("press the Back button to Activity A" and "navigate back from Activity B to Activity A"). But I don't understand why while the former says Activity A resumes with its previous state restored while the latter says the particular instance of Activity B will never be restored. Any explanations?
Thanks in advance!
I think the first one is saying that A will be saved so it can be restored, and the second one is saying that B will not be saved because it can't be restored.
I have two buttons on my application. One button starts a new Game (lets say solitair).
When ever this button is pressed it will always start a new game
My problem is that I would like a second button to go back to the game that has already started if the user clicks back.
How do I go about recalling that activity that has already been created
Thanks
I assume that the game is from a third party. As I see it you don't even need second button. Just click the first one again and you will get back to the game.
If the game intercepts Back it may intentionally destroy it's state so there is no way to jump back to the place that you were before hitting Back.
You have to save the state of the activity
onSaveInstanceState() and onRestoreInstanceState() are used to handle the activity state
onSaveInstanceState() method gets called for an activity when user leaves the activity. Note this method is only called when activity is present in the History state and user can come back to the activity.
onRestoreInstanceState() restores the state of the views.
see the following link
How to manage activity state
You have to read manual about activity stack
Your application can has more than one task and more than one activity back stack
How do you save an instance state of an activity. For instance a user opens up a application and clicks a button. A new view is formed and the user types in some information and moves to the next screen in that activity. After that goes back to the main menu of the app. how do you save where the state was before the user went back to the main menu.
Thanks in advance everyone!
http://developer.android.com/reference/android/app/Activity.html
In addition, the method
onSaveInstanceState(Bundle) is called
before placing the activity in such a
background state, allowing you to save
away any dynamic instance state in
your activity into the given Bundle,
to be later received in
onCreate(Bundle) if the activity needs
to be re-created.
I have an activity that is called at runtime in an Android App. When the user clicks the back button the Activity is destroyed and I overrode the onSaveInstanceState method to save outState to be retrieved in a second time but onSaveInstanceState is never called when the user clicks the back button.
Do you know why this happens?
onSaveInstanceState() is not supposed to be called when the user presses BACK.
It will be called when the user changes configuration (e.g., rotates the screen), if Android believes that the activity is at risk of being destroyed while still being reachable on the stack, and perhaps a few other cases.