I am looking for a way to sync database and photos between devices trough Dropbox. The purpose is that several devices can add delete and update data and photos.
I thought about exporting the .db file but it would be difficult to update, I think it would rather overwrite the previous file. Maybe working with CSV is a good approach, because the app would be actually read and compare before updating its database and files.
The app will have something likea sync button or something that trigger sync.
I know that it would be correct to use an own SQL server, but I would rather avoid that.
Any ideas?
Related
I've been searching a way to implement SQLCipher on my prepopulated database containing more than a million entries. Last three months is the time I've fully devoted to my project's database and it's now complete which led me to a problem.
My app's database is something that I know will be copied in a week or so and copying database is so easy (just open the apk with WinRAR). And in India, No one cares about copyrights so that'll be of no use.
Basically I want to protect my app's database from copying keeping in mind that app should work offline (that being said no PHP/SQL servers).
I've checked GitHub/Google for it and only thing I've found is SQLCipher by Zetetic. Very same thing on GitHub - Here.
Also, One can import following library now: net.zetetic:android-database-sqlcipher:3.5.2#aar and can use this for securing database but it's something works on databases created by app and not on prepopulated. (lib taken from this answer on SO).
-> Now, for me the million dollar question is Is there anyway by which I can either password protect or encrypt my database without putting the database on any server?
P.S. -> I want to make my app work offline and also, I'm just a student and at least for now, can't afford Zetetic's paid service.
Edit - I've gone through codes of some google apps storing databases for some help but they are just using .out files (easily openable with Word/Text editor) compressed in .gz files which is not something I should use.
implement SQLCipher on my prepopulated database
This is pointless. Anyone who wants to can grab the encrypted database, grab the encryption key out of your app, and decrypt the database.
I want to protect my app's database from copying
Don't put it on the device.
keeping in mind that app should work offline
Depending on the nature of your app, you might be able to cache bits of data for offline use, for reduced functionality while offline.
A simpler solution is to not worry about the fact that the database may be copied. To paraphrase Tim O'Reilly, your problem is not security but obscurity.
I'm trying to create some sort of backup & restore function in my app. Before that, I've been reading for a while to understand if it's possible to achieve, but I found out this question:
Sqlite DB Android Backup/Restore
The only other way I could see to do it, would be to read the actual contents of the DB and generate a file containing the SQL which which it can be restored from, this is obviously a more complex and doesn't offer any advantages to justify this complexity.
This answer, I think, is the best way to accomplish that; not explorting the .db file, but exporting queries.
You know; when you export a SQL data from mysql, you get a file which contains all the queries that creates the structure and queries that fill the structure with data.
That's what I'm trying to mimic; generate a file which contains sql queries from a .db file.
Do you guys think it's possible, I mean, is there any builtin method to achieve that?
Otherwise, if its too hard to handle, how do you manage to avoid what this user (https://stackoverflow.com/a/10842043/1943607) is talking about?
So, I disabled WAL with "PRAGMA journal_mode = DELETE" and then I was able to view the database in the browser and able to restore it on my test device fine.
That previous part, I can't understand it. Is this a configuration you set to sqlite?
Thanks
I haven't actually tried this with sqlite, but with mysql you could do things like create "dumps" of your database. Those dumps contained exactly what you describe: a set of queries that, when executed together, recreate the database, including the contents.
Judging from the "sqlite3" documentation found at http://www.sqlite.org/sqlite.html (especially the "Converting An Entire Database To An ASCII Text File" section), you can do the same for sqlite. Since you can execute shell commands from a java application (using Runtime.getRuntime().exec() methods), and you are the "owner" (Linux user id) of the database, you should be able to run this "sqlite3 .dump" command even on a non-rooted device. I have never seen an Android device without the sqlite3 tool installed, so the command should always be available.
Moreover, since dump file is just a text file, you should be able to prepend any PRAGMA's to it that are required for compatibility (like the one you quoted).
I haven't tested any of this, but just wanted to think with you on this interesting topic.
An sqlite database is just a file so you could copy the file but I think you may have problems with permissions in android preventing you from accessing the database.
A better solution IMO would be to sync your data to an external website.
Using a combination of a custom sync adapter and the account manager with a website or web service that has a RESTfull api to receive and send the synced data would be the most reliable approach.
http://developer.android.com/training/id-auth/identify.html is a great introduction to setting up the account manager.
And for a custom sync adapter this is a great starting point.
http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/
and http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-2/
And finally an explanation of how it all fits together
https://sites.google.com/site/andsamples/concept-of-syncadapter-androidcontentabstractthreadedsyncadapter
The above approach would enable a user to switch phones and retain data at the same time and the data would always be up to date (providing you sync at the appropriate times.
It seems like a lot of work as you will need to set up a web service but it is the BEST way to make sure data is kept safe and secure and can be restored and backed up at any point.
For a web service there are lots of options available to you including cloud services such as Google docs or writing your own website. Ruby on Rails is a great solution for developing your own site as you get a full RESTfull api out of the box and it;'s dead easy to secure/lock down a rails site to authorised users only with a couple of lines of code and with Heroku you can get free hosting.
As usual with Android development the simplest of requirements actually ends up being the most difficult to implement but where data safety is paramount then it's worth the effort to do it properly.
The question is too open to answer simply because the changes that may apply to the db file content are open and one can't guarantee a specific behavior .
On the positive side sqlite project is an open source and the format of the DB file is specified Here
After taking a look there, it seems very possible/not too complicated to parse any DB file looking for Data Only and write it/dump it to another functional db file.
I believe this is the fastest and cleanest solution to the issue in hand.
so to wrap up:
Copy DB file everytime you want to back it up.
When you want to restore create a new DB using Android APIs.
Parse the data from the backed up file and write them to the newly created DB.
P.S:
regarding how to use
PRAGMA journal_mode = DELETE
Simply use db.exec("PRAGMA journal_mode = DELETE"); when creating the DB
Im working on a self-test app.
And I wondering on how to store the data, I've got over 200 questions and more is on the way.
Was thinking of storing them as XML but didnt find a way to get a random question without reading the whole string-array to a variable, which is bad for the memory.
So the correct way to go is to use a SQL-database, right?
But how do I make such a database so that it exists at boot and dont need to be made during start up?
Can't seem to find any tutorial on this subject, on how to handle questionnaires.
Here's a good tutorial on SQLite and Content Provider. It'll introduce you to using SQL databases on Android, and wrapping them into a ContentProvider.
As for how to get the data to the device - you have two options:
You pack the SQLite .db file in the application assets folder. Pros: the database is ready for consumption on the first run of the app. Cons: your .apk is too big. Updating is hard.
You download the data on the first run. Pros: your .apk is slim. updating is easy Cons: there's a delay before the user can use the app.
You ship a small .db file with the first 10 questions. Pros: Your users can start using the app immediately, while you download the rest of the questions in the background. Cons: You have to pick 10 questions you're likely to never or rarely change, or you risk your app to start with outdated data.
Create the db offline and either put it in the apk or download it.
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.
I'm developing a content provider which stores its data in an SQLite database. During development, I need to change the schema, or delete the database entirely and have it rebuilt (I'm not upgrading the database at this stage of development).
I found the database file, stored at /data/data//databases/app_db . When I pull it to my desktop machine, I can use SqliteSpy to see its content and all is well. However, when I delete it, it doesn't always get really deleted. Although I can't see the file in DDMS or ADB, my application still sees it.
I tried to make sure my application and service aren't up when I delete the file, but it doesn't seem to help. In about half the times I delete the file, I need to restart the emulator for it to have effect.
What could be preventing the file from being really deleted?
Itay.
I've seen this issue too when was writing unit tests for my ContentProviders. You need to make sure you've killed the process that hosts ContentProvider that uses that specific database file. And only than delete it.