views:

360

answers:

1

Hi everybody,

I'm looking for ways to back up the database of my app on an Android phone. I know that SQLite databases are just files, so I'd expect to be able to just copy the file to SD-card if one is available.

However, I'm unsure as to how I'd prepare my database/activity for backup/restore.

When starting, my main activity reads the entries from one table in the database and displays them in a ListView. As shown in the API's "Notes" sample, I have a cursor that is automatically notified about changes to that table (ListView is automatically updated when I add/remove/update records in the table).

So: When I copy the database file to SD-card, I should not have a problem. But what if the user wants to restore a database file? I can't just copy the file back to the data folder, can I (EDIT: ... while a view displays data from the database and thus maybe holds an open connection)?

What would be "best practice" when implementing backup/restore? One approach I've considered is:

  1. Open a special "restore" activity that holds no open database connections
  2. Call finish() for the main activity to remove it and close database connections
  3. Copy back the database file
  4. Open a new "instance" of the main activity
  5. Call finish() for the "restore" activity

Would that be the way to go? Thanks for any advice!

+4  A: 

But what if the user wants to restore a database file? I can't just copy the file back to the data folder, can I?

Yes, you can. As you can move the file from your data folder to a folder onto your SD card, you can move the file back from the SD card into your data folder.

What you proposed now, is a good approach, just keep in mind you do not want any open database objects during backup/restore.

Anthony Forloney
What I meant is that I can not copy back the file when the view has an open connection. When I finish the view that retrieved data from the database, all connections should be closed, right?
Thorsten Dittmar
Yeah that is correct, you have the right idea.
Anthony Forloney
Alright, thanks, I'll give that a try!
Thorsten Dittmar
No problem, best of luck.
Anthony Forloney