"persistent state" vs. "current state"

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 usersaw?
• 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).

Here is answer. You can save state in three different ways.

1) Subclassing app (not a good idea).2) SharedPreferences (good for simple data, quick and reliable)3) SQLite Database (More complex, also reliable).

Now to answer your question. There are really NO guarantees with android. At any time it can and may destroy your application without calling any particular function before it does so. So if there is data that is vital to save, the answer is save it as soon as you get it. There is usually not much advantage to saving something later, if you know you are going to need something save it immediately.

onSaveInstanceState() is just for saving temporary variables related to layout or orientation changes.

In summary persistent state/data (that should survive a crash), should be saved ASAP, don't wait for onPause(), because there are no guarantees. That's the reality.

The case I have is a game, where I want to save persistant data to a gameserver.

As this may take awhile, I find it not a good thing to try and save in onPause, but rather in onStop.

According to the tests I have done, onStop seem to be able to run in the background while onPause blocks, atleast that is the case when I press home (tested with a simple for 1 to 10m loop in onPause and onStop).Can anyone confirm this blocking theory ?

onStop NEEDS Honeycomb up (api11+), because before that version you can get killed before onClose is called.

See here and look for killable in the table - If reality matches the documentation is another question :).