Avoiding data loss due to interruption when saving files on android?

Question

I am wondering what strategies others use to avoid data loss when saving files on Android. I have a couple of game apps that and essentially, they potentially save the game state/savegame whenever the user pauses (onPause).

This works in 99.99% of the cases, but every once in a while I receive an example of a savegame where the saving process has gone wrong. Usually, this is an ill-formed XML file, typically truncated at some arbitrary point. Based on the bug reports I receive, I believe that the problem mostly occurs when the user is interrupted during gameplay by a phone call or something like that and the Android OS then kills the app before it can finish saving. The code for saving the files is pretty simple, so I have difficulty seeing what else might cause this issue.

This is a serious problem, because it will usually result in the player's save progress being ruined.

I was thinking of writing to an empty file first, and then copying to the "real" file only after, but I suspect that would simply increase the problem as it will overall take more time and still risks getting interrupted.

Anyone who has a secure way of doing this that Android is relatively guaranteed not to mess up?

---

So summarized, the options suggested so far (as I understand them):

1. Use a service for the saving process, on the assumption that this will be less likely to be killed by the OS.
2. Save in temp file; copy over when save is verified.
3. Incremental saving of the game state (I actually already use this for player log information).
4. Combination of 2 & 3.
5. Move the saving to another thread, as the problem may be with ANR kills [DC's comments below].

I do not think SharedPreferences will work for this kind of structured data, At the moment, neither of these methds seem like an ideal solution, so I am still open to suggestions.

---

I've not yet managed to test all of these approaches, so rather than waste the bounty, I have assigned it to the answer that I feel would be most likely to solve the issue. I plan to check through the various options still, though, prior to accepting an answer. Thanks for all of the good suggestions.

Answer 1

This sounds like a good job for a service.

http://developer.android.com/reference/android/app/Service.html

Answer 2

We've had occasional issues when we're doing I/O (usually writing) to persistent storage (private filesystem on internal memory) from the main thread. Usually this doesn't take much time at all, but occasionally it inexplicably takes ages (20 or 30 seconds or more). It seems that the Android filesystem implementations on some devices don't support concurrent access (see this, so your I/O can block if another process is using the filesystem. If you are doing your I/O on the main thread, the OS can/will kill your Activity if it blocks for too long. This may be what is happening to you.

Due to this problem, I would suggest that you move all your I/O to a separate thread (not the main thread). So, for example, to save the game state, in onPause() call a method that serializes the game state to a ByteArrayOutputStream which you then hand off to a separate thread to be written eventually to the filesystem.

Answer 3

I think that saving little portions of data (not the whole game state) to the database every time user performs any action (not only when onPause() is called) would be the best approach in this case. However, this may require a lot of modifications to the code.

The compromise would be to split the game state into smaller portions or sub-states (let's say, round1, round2, ..., players, etc) and again store data to appropriate files as user performs any action, not waiting for onPause() call. This would significantly reduce the probability of loss and at least would guarantee that the user doesn't loose the whole game progress. Moreover, to avoid inconsistent states of your app, which may appear when the save process is interrupted, you'd better save data to temporary file first and only in case of success simply rename the file, not copying its content (let's say, round1.xml.tmp rename to round1.xml).