Various Android system operations can affect the state of your fragment. To ensure the user's state is saved, the Android framework automatically saves and restores the fragments and the back stack. Therefore, you need to ensure that any data in your fragment is saved and restored as well.

The following table outlines the operations that cause your fragment to lose state, along with whether the various types of state persist through those changes. The state types mentioned in the table are as follows:

- Variables: local variables in the fragment.
- View State: any data that is**owned by one or more views**in the fragment.
- SavedState: data inherent to this fragment instance that should be saved in`onSaveInstanceState()`.
- NonConfig: data pulled from an external source, such as a server or local repository, or user-created data that is sent to a server once committed.

Oftentimes*Variables* are treated the same as*SavedState*, but the following table distinguishes between the two to demonstrate the effect of the various operations on each.

|            Operation            | Variables | View State | SavedState | NonConfig |
|---------------------------------|-----------|------------|------------|-----------|
| Added to back stack             | ✓         | ✓          | x          | ✓         |
| Config Change                   | x         | ✓          | ✓          | ✓         |
| Process Death/Recreation        | x         | ✓          | ✓          | ✓\*       |
| Removed not added to back stack | x         | x          | x          | x         |
| Host finished                   | x         | x          | x          | x         |

*\* NonConfig state can be retained across process death using the[Saved State module for ViewModel](https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate).*

**Table 1:**Various fragment destructive operations and the effects they have on different state types.

Let's look at a specific example. Consider a screen that generates a random string, displays it in a`TextView`, and provides an option to edit the string before sending it to a friend:
![random text generator app that demonstrates various types of state](https://developer.android.com/static/images/guide/fragments/text-generator-app.png)**Figure 1.**Random text generator app that demonstrates various types of state.

For this example, assume that once the user presses the edit button, the app displays an`EditText`view where the user can edit the message. If the user clicks on**CANCEL** , the`EditText`view should be cleared and it's visibility set to[`View.GONE`](https://developer.android.com/reference/android/view/View#GONE). Such a screen might require managing four pieces of data to ensure a seamless experience:

|       Data       |    Type    |           State type            |                                                                                     Description                                                                                     |
|------------------|------------|---------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `seed`           | `Long`     | NonConfig                       | Seed used for randomly generating a new good deed. Generated when the`ViewModel`is created.                                                                                         |
| `randomGoodDeed` | `String`   | SavedState + Variable           | Generated when the fragment is created for the very first time.`randomGoodDeed`is saved to ensure that users see the same random good deed even after process death and recreation. |
| `isEditing`      | `Boolean`  | SavedState + Variable           | Boolean flag set to`true`when the user begins editing.`isEditing`is saved to ensure that the editing portion of the screen remains visible when the fragment is recreated.          |
| Edited text      | `Editable` | View State (owned by`EditText`) | The edited text in the`EditText`view. The`EditText`view saves this text to ensure that the user's in-progress changes are not lost.                                                 |

**Table 2:**States that the random text generator app must manage.

The following sections describe how to properly manage the state of your data through destructive operations.

## View state

Views are responsible for managing their own state. For example, when a view accepts user input, it is the view's responsibility to save and restore that input to handle configuration changes. All Android framework-provided views have their own implementation of`onSaveInstanceState()`and`onRestoreInstanceState()`, so you don't have to manage view state within your fragment.
| **Note:** To ensure proper handling during configuration changes, you should implement`onSaveInstanceState()`and`onRestoreInstanceState()`for any custom views that you create.

For example, in the previous scenario, the edited string is held in an[`EditText`](https://developer.android.com/reference/android/widget/EditText). An`EditText`knows the value of the text it's displaying, as well as other details, such as the beginning and end of any selected text.

A view needs an ID to retain its state. This ID must be unique within the fragment and its view hierarchy.**Views without an ID cannot retain their state.**  

```xml
<EditText
    android:id="@+id/good_deed_edit_text"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />
```

As mentioned in table 1, views save and restore their`ViewState`through all operations that don't remove the fragment or destroy the host.

## `SavedState`

Your fragment is responsible for managing small amounts of dynamic state that are integral to how the fragment functions. You can retain easily-serialized data using[`Fragment.onSaveInstanceState(Bundle)`](https://developer.android.com/reference/kotlin/androidx/fragment/app/Fragment#onsaveinstancestate). Similar to[`Activity.onSaveInstanceState(Bundle)`](https://developer.android.com/reference/android/app/Activity#onSaveInstanceState(android.os.Bundle)), the data you place in the bundle is retained through configuration changes and process death and recreation and is available in your fragment's[`onCreate(Bundle)`](https://developer.android.com/reference/kotlin/androidx/fragment/app/Fragment#onCreate(android.os.Bundle)),[`onCreateView(LayoutInflater, ViewGroup, Bundle)`](https://developer.android.com/reference/kotlin/androidx/fragment/app/Fragment#onCreateView(android.view.LayoutInflater,%20android.view.ViewGroup,%20android.os.Bundle)), and[`onViewCreated(View, Bundle)`](https://developer.android.com/reference/kotlin/androidx/fragment/app/Fragment#onViewCreated(android.view.View,%20android.os.Bundle))methods.
| **Caution:** `onSaveInstanceState(Bundle)`is called only when the fragment's host activity calls its own`onSaveInstanceState(Bundle)`.
| **Tip:** When using a`ViewModel`, you can save state directly within the`ViewModel`using a`SavedStateHandle`. For more information, see[Saved State module for ViewModel](https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate).

Continuing with the previous example,`randomGoodDeed`is the deed that's displayed to the user, and`isEditing`is a flag to determine whether the fragment shows or hides the`EditText`. This saved state should be persisted using`onSaveInstanceState(Bundle)`, as shown in the following example:  

### Kotlin

```kotlin
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putBoolean(IS_EDITING_KEY, isEditing)
    outState.putString(RANDOM_GOOD_DEED_KEY, randomGoodDeed)
}
```

### Java

```java
@Override
public void onSaveInstanceState(@NonNull Bundle outState) {
    super.onSaveInstanceState(outState);
    outState.putBoolean(IS_EDITING_KEY, isEditing);
    outState.putString(RANDOM_GOOD_DEED_KEY, randomGoodDeed);
}
```

To restore the state in`onCreate(Bundle)`retrieve the stored value from the bundle:  

### Kotlin

```kotlin
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    isEditing = savedInstanceState?.getBoolean(IS_EDITING_KEY, false)
    randomGoodDeed = savedInstanceState?.getString(RANDOM_GOOD_DEED_KEY)
            ?: viewModel.generateRandomGoodDeed()
}
```

### Java

```java
@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if (savedInstanceState != null) {
        isEditing = savedInstanceState.getBoolean(IS_EDITING_KEY, false);
        randomGoodDeed = savedInstanceState.getString(RANDOM_GOOD_DEED_KEY);
    } else {
        randomGoodDeed = viewModel.generateRandomGoodDeed();
    }
}
```

As mentioned in table 1, note that the variables are retained when the fragment is placed on the backstack. Treating them as saved state ensures they persist through all destructive operations.

## NonConfig

NonConfig data should be placed outside of your fragment, such as in a[`ViewModel`](https://developer.android.com/reference/androidx/lifecycle/ViewModel). In the previous example above,`seed`(our NonConfig state) is generated in the`ViewModel`. The logic to maintain its state is owned by the`ViewModel`.  

### Kotlin

```kotlin
public class RandomGoodDeedViewModel : ViewModel() {
    private val seed = ... // Generate the seed

    private fun generateRandomGoodDeed(): String {
        val goodDeed = ... // Generate a random good deed using the seed
        return goodDeed
    }
}
```

### Java

```java
public class RandomGoodDeedViewModel extends ViewModel {
    private Long seed = ... // Generate the seed

    private String generateRandomGoodDeed() {
        String goodDeed = ... // Generate a random good deed using the seed
        return goodDeed;
    }
}
```

The`ViewModel`class inherently allows data to survive configuration changes, such as screen rotations, and remains in memory when the fragment is placed on the back stack. After process death and recreation, the`ViewModel`is recreated, and a new`seed`is generated. Adding a[`SavedState`](https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate)module to your`ViewModel`allows the`ViewModel`to retain simple state through process death and recreation.

## Additional resources

For more information about managing fragment state, see the following additional resources.

### Codelabs

- [Lifecycle-Aware Components](https://codelabs.developers.google.com/codelabs/android-lifecycles/#0)codelab

### Guides

- [Saved State Module for View Model](https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate)
- [Saving UI States](https://developer.android.com/topic/libraries/architecture/saving-states)