Thread: Android: How to deal with App being closed in the background?

So I've come across something with my Android app which I am apparently not handling well (or at all).
If I open my app, then press the home button (so the app is now running in the background), then wait a long time (perhaps do other things in the meantime), and then open the app again, I get weird behavior. Specifically, the app remembers what activity it was on, but it doesn't remember much else about that activity.
In my scenario, I have a puzzle game which is drawn onto the activity. When I start up the app again at that later time, the activity for interacting with the puzzle opens (as if the app was just put on hold), but the puzzle itself is gone. This only happens after a long period of time running the game in the background.
Furthermore, my app is not listed on my device as an "Active App" when this happens, which leads me to believe Android has closed the app due to inactivity, but saved the app's state or something (since reopening the app doesn't start the launcher activity). I suppose the other possibility is that the puzzle data was garbage collected.

So my question is: what would be the "correct" way of preserving the puzzle data? My initial assumption would be saving it in a temp file, but I'm not sure when I should tell my app to create that temp file, or if this is even a valid assumption.

Record the state of the app in the onPause() function, and reinitialize it to that state in the onResume() function.

Chances are your app is being destroyed by the OS either because it is in the background for too long or another process needs the resources. The correct way of dealing with this is to re-create the activites states with a Bundle. Override the activites onSaveInstanceState(Bundle savedInstanceState) and create key-value pairs that define the state of the puzzle. You've probably seen it thousands of times before but the activities onCreate(Bundle savedInstanceState) comes with a Bundle that can be used to re-create the activity.

It's a much cleaner approach than creating temporary files but it also has a few un-expected benefits. For example, every time the screen is rotated an activity is destroyed and re-created. Now, android automatically stores the state of all objects that extends a View which is why this process is typically transparent to a developer but in your case the Puzzle activity has some state that isn't captured so using a Bundle will let you re-create the activity when the screen is rotated or the user hits the back button.

That's an interesting solution that seems to be what I want. But there are a few things I'm curious about.

Ok, so I have a separate class for the Puzzle which is in a library that is independent from the Android app (the library has no reference to anything Android related). The specific Puzzle object that the App is using is stored in a static Data class, which just contains the puzzle and a handful of constants which wouldn't have made sense to put in the resource folder or any specific class. The activity in question refers to the static Puzzle object in the Data class. Because of this, the Puzzle object itself is not effected by the screen being rotated or the user pressing the back button or anything (because recreating the activity doesn't recreate the Puzzle object).
The Puzzle class itself contains lists, multidimensional arrays of objects, ect., so it's not just a bunch of raw data. While looking over the Bundle object, it seemed that you can only store raw data and Parcelable objects. The Puzzle object obviously contains a heck of a lot more than just raw data (I have to dig pretty deep into the infrastructure before I get to raw data), and since the Puzzle object is in an Android-independent library, telling it to implement the Parcelable interface would not be an option.
I could probably create a wrapper for the Puzzle object which implements Parcelable, but I would then have to create similar wrappers for all the other classes which the Puzzle object contains, which seems like major overkill to solve just this problem.

Do you know if there is a way around this problem for me to use the solution you suggested, or should I probably just stick to the temp files? The size of saving the puzzle isn't enormous, perhaps at most 100kbs. Furthermore, if you do suggest I stay with the temp file, should that file be created/read on the onSaveInstanceState()/onRestoreInstanceState() methods, or the pause()/resume() methods? I want to reduce the number of unnecessary reads and writes to files if possible.

You re-create the Views with a Bundle but your model sounds complex enough to warrant it's own serialization. Kevin's answer is the way to go; serialize in onPause() and deserialize in onResume()