I was recently working on my new application idea and wanted to add a basic but useful feature. The application is an Attendance Manager utility app called — SKip for students to keep track of their attendance for which I made use of Room Database. I explored Room Database thoroughly and liked how Google has evolved the SQLLite with fewer boilerplate codes with Room. But, since the data the user enters is important, it should be backed up and kept safe in case the phone gets damaged or the user wants to change the device.
For automatic backup, I have made use of another Architecture component called the Work Manager. Work Manager helped me in running background tasks every 24 hours to back up the database and keep it safe under the app’s folder.
For backup and restore features, most of them will suggest and force you to add and request STORAGE permission from the user. While more users are becoming aware of privacy issues and have concerns granting permission to just any other app, we will implement the feature without any
Backup Database —
To back up the database which is maintained using Room, we will do it using the following method.
Explanation —
First, we would get the instance of our database (AppDatabase is the abstract class that extends RoomDatabase) using the context and then close the database connection so that there is no operation happening parallelly on the Database. Then we would get the database path (DATABASE_NAME is the name of the database we used to create the database) and the location of which folder we would want to store the backup file at.
We have if checks to see if the folder exists and to create one if it doesn’t. Also here, we have a logic to keep only ’n’ database backup files at a time to not exploit the storage. checkAndDeleteBackupFile() method is defined below if you want to implement that in your application too. We then create a file appending it with the timestamp and copy the database using the streams object.
checkAndDeleteBackupFile() method will help you delete the oldest backup file so as to keep the count of backup files limited. The method is easy to understand and debug so I will leave it up to you.
Restore Database —
To restore the database, we have some basic if checks, and then we do the restore process. Before we delete the database file, we will make a temporary backup of it in case anything goes wrong while doing the restore operation.
Explanation —
We will open up an intent for the user to select the database file they want to restore.
In the OnActivityResult —
We would first validate if the file supplied by the user is actually a database file or not. To do that we have the validFile() utility method —
Now since we know the file is valid, we will first make a backup file of the existing data using the following method —
Now, we will restore the database —
For copying file which is the copyFile() method, we can implement it as —
To validate the Database, we can have our own custom logic implementation. Here, I am validating if there is a user table and if it has any entry (for my application logic, having a user in the database is the initial step) so I can be sure if the restore file is valid or not —
Once the database is restored successfully, we will delete the temporary backup file we created.
By this, we can easily add a backup and restore feature in our application within an hour and test it properly. Do make sure you validate the Database correctly because if a different database file is provided, the application will end up being corrupted and the user will have to either clear data or re-install the application.
Also, since you have come this far, I would love if you would try out the application and keep using it if it helps you tackle your attendance issue. You can download SKip from here.