Timeline for File operation(s) failure on game crash/kill by OS/User in Android
Current License: CC BY-SA 4.0
13 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 19, 2018 at 13:30 | comment | added | MrCranky | As we said above, only save on important actions. If you have 10 important actions a second I'd be surprised, but if you do, implement queuing of saves (so if a save is in progress, just flag another save to happen once it's done) A database solution would achieve the same effect, what I've described is the most basic transactional approach which you can implement easily without the need to refactor what you have into database form. There are some pretty light DB solutions that will work, which is best is not something we can judge here, you have to assess it on your own code. | |
May 17, 2018 at 9:56 | comment | added | Faisal Imran | What if i use document database like couchbase. Database can provide me rollback mechanism in case of user kills the app forcefully and transaction isn't completed yet. which solution would be best ? | |
May 17, 2018 at 9:51 | comment | added | Faisal Imran | Thanks everyone. from all the above discussion i can conclude that i have to divide my apps data into multiple files. Moreover i cant update/write files on each action, because actions are user dependent and user can fire 10 or more actions in a second. Any suggestions on it ? | |
May 14, 2018 at 6:41 | vote | accept | Faisal Imran | ||
May 12, 2018 at 17:20 | history | edited | MrCranky | CC BY-SA 4.0 |
Added advice to save immediately on key events
|
May 12, 2018 at 17:13 | comment | added | MrCranky | Lastly, although this may not solve all your problems, I'd say that your problem is not fully solvable. You can't support both "the user may kill my app at any time" and "no data must be lost ever" because there will always be a window after an event has taken place but before it has been persisted to storage where the user can kill the app and lose data. | |
May 12, 2018 at 17:10 | comment | added | MrCranky | @Polygnome While that's probably neater, managing A and B versions of the files isn't that onerous. If you don't want to have double the storage usage all the time, you can delete the older file as soon as you've confirmed that the newer file is definitely written successfully. This is at its heart a checkpointing problem a la database atomicity; you want as few steps as possible because failure can occur at any step in the process and you have to recover by rolling back to the last viable step. Rolling back itself can fail, so a roll back that involves no operations at all is preferred. | |
May 12, 2018 at 17:07 | comment | added | MrCranky | I'd agree with @CandidMoon, save immediately after the important stuff. If your user is deliberately killing the app immediately after an IAP, they can hardly be surprised if they lose out. The assumption here is that your saves are sensibly short, i.e. <1 second to save. If your saves are taking longer than that, then a) consider optimising what you're saving, and b) consider separating out vital data (like list of IAPs) to a separate file so it can be saved much more quickly and thus be less vulnerable to app being killed mid-write. | |
May 12, 2018 at 10:32 | comment | added | Candid Moon _Max_ | @FaisalImran Save data right after the important operation, for example, after IAP. If the operation was interrupted by phone turning off, I guess it would never take money from the person anyway. But just in case, you might want to save his account data in a purchase on some platform as an attempt to buy something. Then later you can compare your earnings to that data and see if this person really bought something. And then open this feature for him via online service you are using to save all the data. If you are using local saves for IAP, then it's even worse than this problem. | |
May 11, 2018 at 21:13 | comment | added | Dietrich Epp |
@Polygnome: Note that in the case of power failures this will not always provide the guarantees you expect, unless you call sync() on file B before you move it over file A (even then there are not complete guarantees, but sync() is fairly good).
|
|
May 11, 2018 at 16:20 | comment | added | Polygnome |
You don't even need two files. Write to B, if and only if writing was successful, delete A and rename B to A. java.nio.file.Files.move(Path source, Path target, CopyOption... options) can do renaming and overwriting as an atomic operation.
|
|
May 11, 2018 at 15:56 | comment | added | Faisal Imran | Thanks MrCranky this is partial solution to my problem how can i save data of last session i.e just before killing app/game? For example he made an in app purchase and killed app. | |
May 11, 2018 at 12:17 | history | answered | MrCranky | CC BY-SA 4.0 |