I want to store some data that should remain also after application uninstall and to be accessible by a new version of this application.
Share preferences/files are not a solution as they are removed when program is uninstalled, also writing to internal memory is not a solution (also removed with uninstall).
Writing to external public folders I see that is not removed but this would require an external SD Card and don't want to be constrained by this.
I don't know about using the SQLite database, how it works? It could be a solution for what I want ?
Or any other solutions would be appreciated.
The databases made by your app will be stored in /data/data/your.package.name/databases/ and will be deleted on uninstallation of the app.
So, that's not a solution. I think the only way would be using the SD-card.
It sounds like you got this right. Writing to SD-card is the only really persistent way to store data.
edit:
The Data Backup might also have something going for it, but don't take my word for it ;).
Use SharedPreference or by using SQLitedatabase
1) create temporary table (with the same structure as original) and copy data from the original table into this new one 2) drop the original table 3) create the new original table (i.e. with more columns, with other column names, etc.)4) copy data back from the temporary table to this new original one 5) drop the temporary table
Related
Since there are two ways by which we can store or copy the data from database. one is from sqlite file which we lay in assets folder and another by database which is created programmatically.
I have following questions regarding the sqlite database in android:
1.which performs faster while getting performing select query from database and why?
2.what are the advantages of each approach.
I found on internet but i could not get any proper information, the only thing that i come to know by Googling is copying data from assets is better for static data like list of country(that is obvious because you will not perform any bulk operation of inserting data programmatcially in android). Any help regarding this is appreciated . :)
It does not make a difference.
Your select query is performed on the final database, which would be identical whether you copied it from assets, or imported it programmatically. Your approach to its creation does not influence its behaviour.
As for advantages, that's entirely up to you. In some scenarios, having a base database in assets would give you better, and easier to read, control over versioning, as you could commit it easily with your repository, vs. having thousands of SQL statements in code.
On the flip side, updating a database that you copy from the assets folder with each version could be difficult, especially if you modify data within the app frequently. Instead of programmatically simply altering the schema or data on update, you would have to export any modifications, copy the new database, and then import all your modifications by performing some form of merge.
I have some entities which I hold in SQLite DB.
Some of these entities will have image as well, as I read, SQLite DB can return up to 2MB per cursor, so storing the images in the DB isn't an option.
So I guess we are left with internal storage and self managing.
Are there any support libraries for managing these images ?
Is there a recommended design for this ?
I though about saving the images with a filename scheme of entityType_id.png where the id is the entity id in the SQLite DB, but I'm afraid it may change over time (backup / restore and such) so maybe another scheme might be a better solution ?
I used the solution that you mentioned here:
I though about saving the images with a filename scheme of entityType_id.png where the id is the entity id in the SQLite DB, but I'm afraid it may change over time (backup / restore and such) so maybe another scheme might be a better solution ?
I created a folder in my Android project and used ids that will never change. Knowing the folder and the id, which I retrieve from the DB, I am able to get the image. I used the android SQLite asset helper library for the solution.
I used such an approach for this little app: MTBcat. You can find an example here: http://www.6020peaks.com/2015/03/how-to-ship-an-android-app-with-preloaded-data/
You should store all of images on the internal storage. There is a post about that with piece of code, which could be helpful for you:
Capturing and Saving an image in Android with different names and then retrieving it by any of those names?
EDIT:
I mean external storange not internal
Have some sequence to generate unique ids (maybe just store current value as property), and store the id only in the database. Name the image file by id and store the file somewhere in the file system. If you delete the record, remove the file and do not reuse the id.
Generate own ids, independent from what the database is doing. Then they will not be affected by backup/restore or things the like.
I think storing an image which size is more than 2M in sqlite is not good for reading or whiting,maybe you can compress your image before you store it.
the scenario is that -- in my application client would make dynamic edit text (of which i m not sure ), but i want to store all the information he creates. All other part have been done.
I just want to know which is the best way to store them in File OR in Database.
As if some says in Database, i want to know how?
and if in File, why?
I will encrypt and decry pt the data too.
Any help would be appreciable.
Thanks in advance.
Store the data in a database. If you're doing Android development, simply use SQLite - http://www.sqlite.org/.
There are many reasons not to store the data on the file system:
It is easier to query a database than a file system. You can quickly and easily answer questions like "How many records do I have?" or "How many items in a given category do I have?"
If you do this in the file system, you'll have to write your own code around querying.
SQLite has strong data types that enforce a schema. If you just write to a file, you'll have to ensure an ID is an integer etc. The database can do this for you.
From my experience when writing files to the file system, I've always ended up with orphaned files. You write them and then forget they are there and they never get deleted. It's annoying. With a database you can easily assess the state of the database and remove old/unused records.
In my android projects I need database to store data for offline usage.
For that I am looking at two options 1)Creating the empty db and copying it to asset 2)Creating the db via code
which option will be good as my app is handling secure data.
weather it will cause any security vulnerability if we store the db structure in asset folder as it will be easily available if we extract .apk file.
Thanks for your support
If your database has something you don't want your legitimate user to see, look for a new project because you cannot attain that. Using a static database in the APK is as you know, easily viewable, but creating it from your app also leaves something that is viewable. You could encrypt the contents, but then you have the problem of how you store the key in a way the user cannot access -- so you really haven't solved anything.
Back to your original question though -- is the data static, or is your application ever going to make changes to it? If the data is static, providing a pre-populated database is fine. If the application is intended to be able to make changes though, you are much better served by letting the application create and manage updates on the database, its schema, and its contents. Following Google's examples will get you there.
I want to make database backup to my app, so I'm looking for the best way.
I should save a copy of the database and programatically make the backup?
Can make database backup with backup manager?
Any tips?
If you are going just to let the user save current state of the application for some reasons, db file(s) copying will be fine. Your can find plenty of samples here, like this: https://stackoverflow.com/a/2251647/812046
But if you need to restore your data on another devices, you should think of anything like sqlite .dump and you'll have to implement it yourself. As I know if you don't have root you will not be able to use native sqlite dump.
Once I used simple csv files to copy data between android device and openbsd machine. Worked fine for small amounts of data.