I am trying to implement a service to backup the SQLite database of my Android app. I am planning to both schedule this service for frequent backups (every day for example), and add an option to launch it immediately.
My problem is that the service might start while the application is running, or the user might start the application while the backup is in progress. And they may write to the database while I am copying it.
Is there any way to make sure that the copy and write will not run concurrently, without adding synchronization locks to all my queries ?
Thanks !
If you are not using explicit transactions, SQLite will automatically use a transaction around each SQL statement.
To ensure that the database files cannot be accessed by another database connection while you are doing the backup, open an exclusive transaction around the backup.
SQLite site has some notes on doing hot backup on a running database. See the Example 2 in that page.
In android, if you want to initiate a file copy of your sqlite db file, you will first need to get a shared lock as mentioned above, but this approach has shortcomings.
Ideally, you would want to use the sqlite3_backup_* apis.
These APIs are not available in standard android sqlite API, but it is easy to copy the sqlite jni code to your project, and expose these additional features. The advantage with this approach is that you dont have to change existing API calls in your code, as it mirrors existing android sqlite API definitions.
To expose backup APIs, take a look at android_database_SQLiteConnection.cpp to see how existing JNI functions call the native sqlite_* APIs.
Another option is to use something like sqlite4java, it has the sqlite backup APIs wrapped in as Java APIs, and seems the latest version supports Android.
Related
I'd like to receive some advice from all of you.
What is the best way for me to alert users on an update to my app? My app is a very knowledge-based & it works like a dictionary, so there will always be updates to it.
The database I have used is by DB Browser for SQLite, and they are all local database where it is uploaded into the assets folder in Android Studio.
Currently, the limitations are that:
1) it's obviously not real-time because it's stored locally;
2) every update I make to the database structure, I am required to upload the new database into the assets folder again, followed by uninstalling the old app on my phone, then run the app to install in my phone again so that the new database is overwritten.
I have read (How can I regularly update a database of content on an Android app?) & some others, and it seemed like I have to have a server, a cloud-based database & live app in market, to solve the limitations?
Is there really no way for me to overcome the limitations if I want to stick to a local database? At the same time, I kinda wish to avoid setting up a server because I am not intending to make the app live on market, and also this is just a school project I am working on and as such, I have very limited skill sets & knowledge about it and would like to make it on a school-project-based level.
Thanks in advance.
One way to do it is to connect to your local DB through local network instead of assets folder. Therefore, you can update the information by querying the local DB.
As for syncing the information between DB and your application, you should create a trigger or watcher that notify your application when the DB is updated. Therefore, your application can know when to query the DB for the updates. Another way is to just query the database periodically.
Bonus: you could move your database to a cloud-based database. Usually there are several providers that provide free database hosting up to a certain size, which should be enough for your project.
I have started working with databases lately, I was able to create a local database and manage it in my Android app. Now I want to move to higher level with it but I don't know how to do it.
The users in my app need to be able to modify the database, for example insert new data in it. When a user insert new data in the database I want other users to see this change in their copy of the database.
I understand that I will need to store that database on a server or something and synchronize it with the users.
Can anyone tell me the steps to do so?
You should perfom this task in steps.
First, make the local database, and use a system to know when/what changed.
I usually work with triggers myself, but any "mark" is enough to synchronize.
Then, you must make a replica of that database somewhere else. Realise that maintaining the databases is a process, any change in the structure of one database must be performed in all other as well.
Finally, you must implement a method to transfer the data.
So, for an example:
db_local the database in the device.
db_outside the database in the internet.
db_local.trigger -> onInsert
On the applications, check for internet, then connect to your server, then upload the same command to db_outside and run it...
In this step, you must handle connection issues, and if the SQL command was succesfully executed, you have replicated the database content.
Once you have the replicated database, inform a system (like google cloud messaging), that the database was changed, and have the other users pull the info.
I am trying to develop this android application whose database is not stored in the device but on a server. To use sqlite database I need to use android.database.sqlite; and I haven't made much use of android.database package. I went through the documentation site but it did not state clearly if it's possible can store my sqlite database file on server and invoke methods to access it from there. What should I do?
SQLite is not an ideal database to use on a server. The andriod.database.sqlite package is going to have resources for dealing with sqlite specifically, where the android.database package is going to have generic database resources, not specific to sqlite.
For using sqlite on a server, first bear in mind that concurrent connections are a big no-no... sqlite is not designed to handle them.
If I still felt I had to do this, I'd probably look at creating an adapter on the server which would accept requests from the application, then use the android.database.sqlite package on the server, as it's local per the scope there (as sqlite is designed for).
https://www.sqlite.org/serverless.html
My app tracks school grades, calculates averages, etc. and stores all of this in a SQLite database. If a user has to reinstall or gets a new phone, I'd like to be able to restore their data.
It looks like most developers do this either by backing up to SD card or by using Android Backup Service through Google. I'm not sure which is the better method. I'd like restoring to be simple but reliable. I welcome any comments on this.
One thing I'm trying to understand is why Google says to extend BackupAgent instead of BackupAgentHelper if using a database.
If you have an SQLite database that you want to restore when the user re-installs your application, you need to build a custom BackupAgent that reads the appropriate data during a backup operation, then create your table and insert the data during a restore operation.
Why can't I just back up the database as a file and then restore the file? My SQLiteOpenHelper class already handles upgrades if db versions are different. I guess I could just abort on a downgrade.
Why can't I just back up the database as a file and then restore the
file? My SQLiteOpenHelper class already handles upgrades if db
versions are different. I guess I could just abort on a downgrade.
Reason: same database file may not work on different device models(even though most of the cases, it should work, there are cases where it will fail). It depends on parameters like page size etc set at sqlite engine level. Ideal way is to backup the data rather than copying the whole file
It's suggested that you avoid backing up the whole db file all the time mostly because that's a lot of redundant data traffic, especially if you've only changed one record in a large db. Being able to write per-record updates to the backup system is much more efficient (though of course is not nearly as simple to implement).
In my app I have a SQLite DB want to backup to server but what I want is one to one synchronization for off-line backup (e.g. standalone SQLite file instead of a centralized MySQL server, mainly performance reason and I don't need real time query)
Ideally I don't want to upload the database everytime when I need to sync, prefer only sync the changes?
Are there any existing solution for this? (I can consider using other file DB as currently I mainly use SQLite as Key-Value database)
Thanks.
As you are willing to consider using a different DB, take a look at TouchDB-Android. This syncs a database on an Android device to a CouchDB server. There is a related project SyncPoint, that automates setting up a database for each user.
We are using TouchDb-iOS for our product at the moment are planning work on an Android version using TouchDB-Android soon.
The development community is active. Check out the user group.