Android Question Automatic backup - timing?

[Dave O]

Hi all,

If my app does an automatic backup to the cloud, what's the best timing to run the backup process?

Long version:
I'm adding an automatic backup to some of my apps (so that users can restore later if data gets corrupted or if they just want to revert to an earlier state).

The backup would copy the data files (small text files) to the user's Google Drive using the Drive API (after they give initial permission).

I do an automatic local save on the Pause event, but because the backup is a cloud operation, it may take several seconds to complete, so I'm guessing that I won't get enough time at Pause to do this (before Android shuts down the app process).

Could I use a service to do the backup, and trigger it at Pause?

Or would I need to wake up a service periodically (e.g. once a day) to look for changes and do the backups as needed?

Any tips appreciated!

 

[Brian Dean]

It seems to me that you have several options. You could do a backup every time that the app starts - that would be better that what you have now which is no backup at all. Or you could backup every ten minutes like some apps other do. Or you could make a backup ten seconds after the last change of content. It depends on how important you think the data is. But as at present there is no backup at all then why not just take the easiest path and backup at the start. Backup at Pause will not work, as you say.

 

[Erel]

Or you could backup every ten minutes like some apps other do

I think that this is a good idea.

 

[Dave O]

I considered the periodic wake-up-and-check-for-changes method, but the only time there are changes is when the user uses the app, so triggering the check at app exit (Pause) seemed like a better option. (There are guaranteed to be no changes at other times.)

However, they may pause the app for a moment and then return and make more changes, so there might be a collision there. (I don't want to make a backup while they're changing the data.)

Hmm, so perhaps wake up periodically (a few times a day, to avoid draining their battery?), make sure the app isn't currently running (foreground UI), then check for changes and backup as needed. Does that sound reasonable?

 

[Brian Dean]

... there might be a collision there ... perhaps wake up periodically ... make sure the app isn't currently running ...

I think that you are getting far too complicated here. The file system isn't going to corrupt files by reading and writing them at the same time. We know that a 100% up-to-date backup is not required because at present there is no backup at all. Having a service that wakes up periodically is going to be difficult to write and even more difficult to test with 100% confidence. I would go for a simpler solution.

You don't say whether your app has dozens or hundreds of files, or whether the files are hundreds of bytes or kilobytes long, or whether the files are updated with human-keyed text or some computation cycle, but here is what I would do. Associate each file with a flag (integer), preferably in an object, and make a list of these objects. The normal value of the flag is zero. When a file is saved locally (ie updated) its associated flag is set to one. A timer looks through the list of flags every ten seconds (or every ten minutes, if you prefer). If it sees a flag set at one it changes it to two. If it sees a flag set at two it knows that the file has been updated locally, but not that recently (not in the last time cycle, or the flag would have been reset to one), so it backs it up now and resets the flag to zero.

It seems to me that this would be a very rugged solution. The timer procedure overhead would be very small - less than the time taken to enter a text character, probably - and would normally result in no backup action anyway. If files are being updated by user action then the backup would be deferred until the user goes quiet. Very important (to my mind) is that it would be quite easy to test.

[Edit : I forgot when I wrote the above yesterday that your app only updates files locally during (Pause), but I decided that that would not change my suggestion. I think that if you want to offer a sensible cloud backup function then you should write both to the device and the cloud regularly. Two other factors that you need to prepare for : there might not always be a reliable internet connection available, and 'phones get turned off sometimes.]

 

[Dave O]

The typical user will have a handful of data files, each usually less than 50k. I save locally on Pause (and at other points in the app) based solely on user changes while the app is running. So that's straightforward.

I'm hoping that I can simply trigger a cloud Save on Pause, where that is done by a service that continues to run even after my app finishes. However, I don't know enough about the service lifecycle to know if that would work. If the cloud Save fails (e.g. no Internet connection), it will simply try again next time the app finishes.

 

[Dave O]

On Pause, could I just do my usual local save (which just writes a small text file), then do a cloud Save using a service (e.g. the Starter service is already running, use that?).

Would Android let the service keep running long enough (e.g. 5-10 seconds) for the cloud Save to work? (I assume that if I tried a cloud Save on Pause directly, the app would quit while my resumable sub is waiting for a result.)

 

[Brian Dean]

I assume that if I tried a cloud Save on Pause directly, the app would quit while my resumable sub is waiting for a result.

That is definitely true. If you use a service then it should not be the Starter service - the advice below is taken from Erel's tutorial ...

If you want to do a background task then you should add another service.