Android recreate all activities

Recreating an Activity

This lesson teaches you to

You should also read

There are a few scenarios in which your activity is destroyed due to normal app behavior, such as when the user presses the Back button or your activity signals its own destruction by calling finish() . The system may also destroy your activity if it’s currently stopped and hasn’t been used in a long time or the foreground activity requires more resources so the system must shut down background processes to recover memory.

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. However, if the system destroys the activity due to system constraints (rather than normal app behavior), then although the actual Activity instance is gone, the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the «instance state» and is a collection of key-value pairs stored in a Bundle object.

Caution: Your activity will be destroyed and recreated each time the user rotates the screen. When the screen changes orientation, the system destroys and recreates the foreground activity because the screen configuration has changed and your activity might need to load alternative resources (such as the layout).

By default, the system uses the Bundle instance state to save information about each View object in your activity layout (such as the text value entered into an EditText object). So, if your activity instance is destroyed and recreated, the state of the layout is restored to its previous state with no code required by you. However, your activity might have more state information that you’d like to restore, such as member variables that track the user’s progress in the activity.

Note: In order for the Android system to restore the state of the views in your activity, each view must have a unique ID, supplied by the android:id attribute.

To save additional data about the activity state, you must override the onSaveInstanceState() callback method. The system calls this method when the user is leaving your activity and passes it the Bundle object that will be saved in the event that your activity is destroyed unexpectedly. If the system must recreate the activity instance later, it passes the same Bundle object to both the onRestoreInstanceState() and onCreate() methods.

Figure 2. As the system begins to stop your activity, it calls onSaveInstanceState() (1) so you can specify additional state data you’d like to save in case the Activity instance must be recreated. If the activity is destroyed and the same instance must be recreated, the system passes the state data defined at (1) to both the onCreate() method (2) and the onRestoreInstanceState() method (3).

Save Your Activity State

As your activity begins to stop, the system calls onSaveInstanceState() so your activity can save state information with a collection of key-value pairs. The default implementation of this method saves information about the state of the activity’s view hierarchy, such as the text in an EditText widget or the scroll position of a ListView .

To save additional state information for your activity, you must implement onSaveInstanceState() and add key-value pairs to the Bundle object. For example:

Caution: Always call the superclass implementation of onSaveInstanceState() so the default implementation can save the state of the view hierarchy.

Restore Your Activity State

When your activity is recreated after it was previously destroyed, you can recover your saved state from the Bundle that the system passes your activity. Both the onCreate() and onRestoreInstanceState() callback methods receive the same Bundle that contains the instance state information.

Because the onCreate() method is called whether the system is creating a new instance of your activity or recreating a previous one, you must check whether the state Bundle is null before you attempt to read it. If it is null, then the system is creating a new instance of the activity, instead of restoring a previous one that was destroyed.

For example, here’s how you can restore some state data in onCreate() :

Instead of restoring the state during onCreate() you may choose to implement onRestoreInstanceState() , which the system calls after the onStart() method. The system calls onRestoreInstanceState() only if there is a saved state to restore, so you do not need to check whether the Bundle is null:

Caution: Always call the superclass implementation of onRestoreInstanceState() so the default implementation can restore the state of the view hierarchy.

To learn more about recreating your activity due to a restart event at runtime (such as when the screen rotates), read Handling Runtime Changes.

Источник

Activity Recreating in android

In this blog,
I have talked about activity recreating in android. And will give the some facts related to save the Activity State.

There are a few scenarios in which your activity is destroyed due to normal app behavior, such as

• When the user presses the Back button or your activity signals its own destruction by calling finish().
• The system may also destroy your activity if it’s currently stopped and hasn’t been used in a long time.
• The foreground activity requires more resources so the system must shut down background processes to recover memory.

However, if the system destroys the activity due to system constraints, then although the actual Activity instance is gone,

The system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the “instance state” and is a collection of key-value pairs stored in a Bundle object.

Note: Your activity will be destroyed and recreated each time the user rotates the screen.

How to re-opening the activity

For recreating the activity, you can use the simple recreate() or startActivity(intent).

While using the recreate method works by doing,

Источник

Recreating an Activity

This lesson teaches you to

You should also read

There are a few scenarios in which your activity is destroyed due to normal app behavior, such as when the user presses the Back button or your activity signals its own destruction by calling finish() . The system may also destroy your activity if it’s currently stopped and hasn’t been used in a long time or the foreground activity requires more resources so the system must shut down background processes to recover memory.

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. However, if the system destroys the activity due to system constraints (rather than normal app behavior), then although the actual Activity instance is gone, the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the «instance state» and is a collection of key-value pairs stored in a Bundle object.

Caution: Your activity will be destroyed and recreated each time the user rotates the screen. When the screen changes orientation, the system destroys and recreates the foreground activity because the screen configuration has changed and your activity might need to load alternative resources (such as the layout).

By default, the system uses the Bundle instance state to save information about each View object in your activity layout (such as the text value entered into an EditText object). So, if your activity instance is destroyed and recreated, the state of the layout is restored to its previous state with no code required by you. However, your activity might have more state information that you’d like to restore, such as member variables that track the user’s progress in the activity.

Note: In order for the Android system to restore the state of the views in your activity, each view must have a unique ID, supplied by the android:id attribute.

To save additional data about the activity state, you must override the onSaveInstanceState() callback method. The system calls this method when the user is leaving your activity and passes it the Bundle object that will be saved in the event that your activity is destroyed unexpectedly. If the system must recreate the activity instance later, it passes the same Bundle object to both the onRestoreInstanceState() and onCreate() methods.

Figure 2. As the system begins to stop your activity, it calls onSaveInstanceState() (1) so you can specify additional state data you’d like to save in case the Activity instance must be recreated. If the activity is destroyed and the same instance must be recreated, the system passes the state data defined at (1) to both the onCreate() method (2) and the onRestoreInstanceState() method (3).

Save Your Activity State

As your activity begins to stop, the system calls onSaveInstanceState() so your activity can save state information with a collection of key-value pairs. The default implementation of this method saves information about the state of the activity’s view hierarchy, such as the text in an EditText widget or the scroll position of a ListView .

To save additional state information for your activity, you must implement onSaveInstanceState() and add key-value pairs to the Bundle object. For example:

Caution: Always call the superclass implementation of onSaveInstanceState() so the default implementation can save the state of the view hierarchy.

Restore Your Activity State

When your activity is recreated after it was previously destroyed, you can recover your saved state from the Bundle that the system passes your activity. Both the onCreate() and onRestoreInstanceState() callback methods receive the same Bundle that contains the instance state information.

Because the onCreate() method is called whether the system is creating a new instance of your activity or recreating a previous one, you must check whether the state Bundle is null before you attempt to read it. If it is null, then the system is creating a new instance of the activity, instead of restoring a previous one that was destroyed.

For example, here’s how you can restore some state data in onCreate() :

Instead of restoring the state during onCreate() you may choose to implement onRestoreInstanceState() , which the system calls after the onStart() method. The system calls onRestoreInstanceState() only if there is a saved state to restore, so you do not need to check whether the Bundle is null:

Caution: Always call the superclass implementation of onRestoreInstanceState() so the default implementation can restore the state of the view hierarchy.

To learn more about recreating your activity due to a restart event at runtime (such as when the screen rotates), read Handling Runtime Changes.

Источник

The Android Lifecycle cheat sheet — part II: Multiple activities

The diagrams are also available as a cheat sheet in PDF format for quick reference.

Note that, when showing lifecycles for multiple components (activities, fragments, etc) in a diagram, grouped events that appear side by side run in parallel. The execution focus can switch from one parallel group of events to another at any time, so the order of calls among parallel groups of events is not guaranteed. However, order inside a group is guaranteed.

The following scenarios don’t apply to activities and tasks that have a custom launch mode or task affinity defined. For more information, see Tasks And Back Stack on the Android developer website.

Back Stack — Scenario 1: Navigating between activities

In this scenario, when a new activity is started, activity 1 is STOPPED (but not destroyed), similar to a user navigating away (as if “Home” was pressed).

When the Back button is pressed, activity 2 is destroyed and finished.

Managing state

Note that onSaveInstanceState is called, but onRestoreInstanceState is not. If there is a configuration change when the second activity is active, the first activity will be destroyed and recreated only when it’s back in focus. That’s why saving an instance of the state is important.

If the system kills the app process to save resources, this is another scenario in which the state needs to be restored.

Back Stack — Scenario 2: Activities in the back stack with configuration changes

Managing state

Saving state is not only important for the activity in the foreground. All activities in the stack need to restore state after a configuration change to recreate their UI.

Also, the system can kill your app’s process at almost any time so you should be prepared to restore state in any situation.

Back Stack — Scenario 3: App’s process is killed

When the Android operating system needs resources, it kills apps in the background.

Managing state

Note that the state of the full back stack is saved but, in order to efficiently use resources, activities are only restored when they are recreated.

Источник