I'm following a simple tutorial that creates a class which extends from SQLiteOpenHelper and creates a DB with one table and 5 rows.
OK, but I need to understand some more about android Sqlite databases. For example, what happens if the app is closed or the phone is off? Is the database deleted?
Of course the database isn't deleted. I assume you're doing it the "proper" way. In which case the database is persistent. (of course if you choose to create a database in a temporary directory or something similar then its not going to work properly).
Think of it like this. The database is basically a text file. What you're doing to the database is modifying the contents of that text file (ok its a little bit more complicated in real life, but its a good way to think about it).
Once you've made a change to the database (e.g. added a row) the database file is saved onto the disk thus persisting it. If the phone is turned off or the app is quit then the database file persists and you can keep connecting to it in the future.
The database is deleted only when your app is deleted, the user clears the data associated with it or you do it programmatically.
Therefore, your app can be killed or the phone rebooted and your database persists. That's why database is considered to be a persistent storage.
what happens if the app is closed or the phone is off?
Answer is No, database not deleted, your data is only deleted when you Uninstall the Application or Clear data from Application->Manage Application->Application_Name from your device.
When a database is created it lives in your applications private file store and is only deleted when you explicitly delete it (using Context.deleteDatabase) or when your application is uninstalled.
Related
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).
I have one question .
I am using SQLite database ,if i uninstall the app from my device database will be in device or it will removed automatically.
and if i again install the same app again what will happen.
SQlite databases are just files, and they're treated like any other file: they're stored (by default) in the application's private data area (/data/data/$PACKAGENAME/databases). They're deleted along with everything else in the application's private data area.
You can create a database on the SD card if you like. They, of course, won't be removed on uninstallation.
EDITED:
Check this Database related example HERE
I am trying to build an app that will use an SQLite database. My question is once the database is created, will all data still be there once the app is closed, i.e.: the database won't be overwritten when the app is restarted?
You, as a developer are the only one who have access to this database, thus it is only your code which will be allowed to change the state or content of this database.
Yes, the data will remain there.
The data will remain there because of your default create method. There is a status code. You can use SQLScout http://www.idescout.com/ to visualize the table and watch its change step by step.
Yes, data will remain in your application when you close the application. When you run the application the database create in the application.
But yes, if the user uninstalls, the application then user will lose the application. On the other hand, if you want to save the data when the application is uninstalled, then it's better to create the database in SDCard.
I've been going through some tutorials on working with sqlite databases and they all seem to create a new database, tables, etc on the first run of the application. Is this necessary? What if I already have a pre-built database sitting in the assets folder when the application is installed? Can I not simply just open the connection to said database and start using its information or is there a specific reason everyone wants to create it using sql on first launch?
This question comes up frequently. Try this tutorial to use an existing database on Android:
http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/
You can't use database file which sits in assets folder directly as SQLite database, since this file would not be usual file located in common filesystem. E.g. you can have only readonly access to it. So the only your option is to copy those database from assets folder to device's filesystem.
To handle database creation for the first time and accessing it there's special helper class SQLiteOpenHelper. Read about it here. Specifically look in SQLiteOpenHelper.onCreate() - where should sit database creation (or copying from assets folder as in your case)
It's been quite sometime since I last worked with SQLite databases (in Android) but I believe that when they write CREATE statements, they always do so with the IF NOT EXISTS condition (i.e., CREATE (DATABASE|TABLE) IF NOT EXISTS...).
I don't know what you'll use SQLite for but I believe they do that in Android "just to make sure". That is, if it's the user's first time to run the app, the DB/Tables must be created first else app goes bonkers. Otherwise, they are (probably) created already and this case will be handled by the IF NOT EXISTS clause and they just go ahead and create a connection with the existing DB. Win-win.
(If, for some reason, it is not the user's first time to use the app and the DB isn't there, it will just be created again. But that's obvious isn't it? ;) )
If you just link with preexisting database it wont bind to your system. So there may be failures. Creating db at first run is the most appropriate way to work with db.
I have an Android application which uses sqlite database to store textual data for a particular user. The data is read/written from/to the database from a service that runs periodically after every n seconds. My requirement is to clear data depending on age. Like, if the file is more than 24 hours old it should be deleted.
Checking the age of the file seems easy, just compare current time with the File creation time. The problem is:
where should I put this check and delete the file; inside application onCreate() or when the user logs in/ logs out? What would be an ideal place to trigger this logic from? Should I schedule an Alarm when the user logs in?
Should I delete the file or simply delete the rows? If I don't trigger the Cache clearance logic from login/logout, won't deleting the file cause problems, especially if the service is still trying to read and write from the database?
Please advice.
Thanks.
Well, this all depends on your logic for the application for the second part. I cant see why you would delete a database unless its just used to store temp data that does not matter. Either way the ideal place to do this check and delete is in the Data Access class thats opening the connection to the database. Below would be my logic...
Call to open DB
Check if DB file is old
If yes, delete it
Open Database (should create one if it does not exist)