CODEWITHSUNDEEP
androidandroid-activityrestoreandroid-lifecycle
Heimdall
Heimdall

Reputation: 237

Saving the transient state DIY + Has the activity been called or recreated?

In my application, an activity A calls the activity B (via an explicit intent). Lifecycle, B may get killed and recreated etc.

When B is called (from A) it initializes some things. But when recreated it needs to just pick up from where it left. It will finish() some time, then I'm back to A, which might later call B again...

B needs to save a very small amount of data, usually just a few int values. (The rest that I need to restore it is in getIntent() which seems to be still there after the activity has been killed and recreated.) I've heard that onSaveInstanceState and onRestoreInstanceState are expensive and that they are not guaranteed. Plus, I don't need to save the state of views. (For that reason, should I override these two methods with blank ones, preventing the parent ones to get called?)

What's the efficient way to store just a few int values? Should I store the values as static fields of the activity B itself, or of the application itself, or of another class written just for that?

Also, how does the activity B know whether it's been recreated rather than called?

Upvotes: 1

Views: 324

Answers (1)

CommonsWare
CommonsWare

Reputation: 1006869

I've heard that onSaveInstanceState and onRestoreInstanceState are expensive and that they are not guaranteed.

They are not particularly expensive. And, for your scenario, they will be used most of the time. The exception would be if your task is not being restarted, such as:

  • the user got rid of your task by swiping it off the recent-tasks list

  • at least pre-Android 5.0, your app has not be run in ages and falls off the end of the recent-tasks list

  • the user force-stops you from Settings

But in those cases you will not be restarting at B, since I assume B is not your launcher activity.

For that reason, should I override these two methods with blank ones, preventing the parent ones to get called?

Not unless you are experiencing actual problems, not just rumors of hints of potential problems.

What's the efficient way to store just a few int values?

For your case, probably use the saved instance state Bundle.

If you cannot afford to lose those values even if your task goes away (and you will not be restarting at anyway), store them in a file, database, or SharedPreferences.

Should I store the values as static fields of the activity B itself, or of the application itself, or of another class written just for that?

No, because none of those will work. You specifically state that your concern is "Lifecycle, B may get killed and recreated etc.". Part of that lifecycle is that your process may be terminated, and in that case, static data members go "poof".

Also, how does the activity B know whether it's been recreated rather than called?

See if the saved instance state Bundle passed into onCreate() is not null. Or, see if a retained fragment exists, if you're using one of those.

Upvotes: 1

Related Questions