Do I Need To Restore All Variables Onresume?

I had bad experience with static class variables since their values are lost when the class unloads. Therefore I avoid them alltogether. Now I am (probably overly) worried even wi

Solution 1:

I had bad experience with static class variables since their values are lost when the class unloads.

Classes do not "unload". Your process will be terminated sometime after you have nothing in the foreground, when Android needs to reclaim memory.

Can I rely on the variables hold their values 100% ? or do I ensure some kind of valid restore for all activity variables?

Activities are notified of when they are moved off the foreground by a call to onPause(). From the standpoint of that activity, any time after onPause() until (possibly) a corresponding onResume(), the process may be terminated and the activity be lost.

You need to sit back and think about your data model. Suppose the user leaves your app (e.g., presses HOME) and does not return to your app for an hour, or a day, or a month. Any data that the user would reasonably expect to stick around for that period of time needs to be saved in a persistent data store, such as a database or flat file. It is your job to determine when that data gets saved -- perhaps it is when the user presses a Save button, or perhaps it is in onPause() of an activity, or perhaps it is at some other time.

Data that is tied to the current contents of the screen, but does not need to be saved for a month of absence, can be held onto via onSaveInstanceState(). Hopefully you are already using this to handle screen rotations. If so, and if the user leaves your activity but in a fashion by which they might navigate back to it via the BACK button (e.g., a phone call comes in, then a text message comes in, then they click on a link in a text message and bring up the Web browser, and later BACK all the way back to your app, which had been terminated in the meantime), your saved instance state will be restored.

Everything else -- instance data members of an activity, or static data members, or whatever -- may get lost if the user leaves the app, if Android elects to terminate your process. Hence, static data members are typically only used for short-term caches or for things that do not matter if they are lost when the user presses HOME or takes a phone call or whatever.

Solution 2:

If you have data in your activity that needs to be saved, implement onSaveInstanceState.

http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle)

In your onCreate, if the bundle passed in is not null, you can assume you had some state saved in there, and restore from that.

Solution 3:

Normal variables persist, but the problem is that you can never be sure when you're onResuming and when you're onCreating (since you have no control over when Android just goes and tosses stuff on the stack out the window... anything not currently being used is eligible for destruction).

So... your best bet is to save things in whatever manner makes sense if you REALLY need them between places where someone might logically put the device to sleep, or rotate it, or get a phone call, or anything else that interrupts its TOP(ness).

I don't really like the way the bundle works, so, I've been storing my stuff in a JSONobject that I convert to string and just save as one flat SharedPreference String (note that SP persists for ever, whereas your Bundle is gonna be tossed along with everything else once your Application is GCed). That way I can just grab that whenever I want, rather than having to futz around with a billion different Bundle elements, but that's obviously a matter of taste. There's a little more work up-front, and of course slightly more overhead in the serialization/deserialization, but since it's only happening on the rare instance that my variables are destroyed, it's really not anything to worry about (unless you have some massive amounts of data, in which case you should be using a database, anyway).