Question

Attempting to decide (for my application) what to save in onPause() and what to save in onSaveInstanceState(), I combed the entire SO for hints and clear guidelines.

If I understand correctly, onSaveInstanceState() is best for saving “runtime changes” or “current state” (whatever that means), while onPause() is best for saving “persistent state” (whatever that means).

I am still having difficulty deciding what in my application constitutes “persistent state” vs. “current state”. For example, while user preferences are clearly persistent, do I need to save them in onPause() when they are always saved automatically by the Android UI framework when the user changes them?

Do class data members need to be saved in onSaveInstanceState()? Do I need to do that for every class in my application?

I am confused.

Can you bring real-world examples of what must be saved in onPause() and what must be saved in onSaveInstanceState()? Except for device configuration changes, that is.

—

Some new insights, after my question has been answered:

• onSaveInstanceState’s Bundle is not written to anything, and it’s not persistent in any way.
• onSaveInstanceState’s Bundle data will only be held in memory until the application is closed.

Answer 1

You do not need to store user preferences in onPause because as you say, the framework does that for you.

To distinguish between persistent data vs state information, think of a text editor application.

Persistent data

Let’s say the user has typed a couple words and then exits the app. The user didn’t explicitly tell us to save that data to a file, but it sure would be nice to store that data away for when they come back. This is persistent data and you want to store it away in onPause().

State data

Similarly, say you have 2 tabs and a variable that tracks which tab is currently selected. This is state data that you’d store in onSaveInstanceState().

Gray matter

Finally imagine you have a class in the editor that keeps track of the number of characters and number of lines in the editor. This is state data, you could store it in onSaveInstanceState() or you can throw it away and simply recalculate it when you start up again. Whether you throw it away might depend on how long it takes to calculate, for instance if you could prevent a network request by storing data, do so.

Further thoughts

By playing with your app it should be obvious if there’s an area where you failed to squirrel the right data away. Be sure to do things like hit the home button and then close out your app from the device manager. This will let you hit the corner cases where your app is shut down rather than just paused.

If your UI state is consistent across lifecycle events and your user data remains, good job.

Edit based on comment

I think there are 2 pieces of criteria here to determine when/what to save.

The first is quite subjective – Do you want to save data at all? There’s truly nothing forcing you to save state or data. Will saving this information make for a better user experience? If you are writing an email and trying to copy/paste text from another app, losing your half typed email every time the app gets closed would be frustrating.

The second piece, determining what to save depends on whether you can reconstruct your UI state based on the data that you have. For instance, if you have saved text data then that must mean that the user was editing text. So now we know to switch to the edit text tab and fill in the saved text.

Generally speaking, if the desire is that you want to return the user to the same place they left off then you need to think about the state data required to get back to that point. Imagine a pristine loaded version of your app

• what data needs to change to turn that into the last state the user
  saw?
• what data do you need to store to get back here?

This is really how android works, your activity is destroyed and recreated and it is your job to set the pieces in motion again (if you choose to do so).