Develop Reference

When I use a sqlite database as an asset can the database still be used/viewed by another program?

I am working on my capstone and I need to create two programs using two different languages that use a single local database. I am making a chore manager that will be a windows program and an android app. I figure out how to use sqlite for the windows app, but I cannot wrap my head around using an existing database with android studio. I need the app to be able to read existing data and display it and then based on some conditions edit the data.
If I add the database as an asset will the data a user changes using the app be usable by another windows program?

Here's my opinion: "Don't use SQLite for this." Use a regular shared database that you can (securely ...) access from both environments.
SQLite databases are files, accessed through the file-system. They are most commonly used where the data won't be shared, because, like any "shared file" database of aeons past, they are always subject to corruption if someone (or the operating system, or the network ...) does anything wrong. Whereas a conventional client/server database doesn't have these problems because it controls the data while it talks to you.
SQLite is a marvelous tool for storing structured information on a device. I've deployed many dozens of "boutique" websites which store their page-information that way. But, I think, it's not the right tool for this job.

Android App: can I use iOS sqlite? If not, how do I create a local database from a database in the cloud (Parse.com)?

I am making an Android version of an iOS app that I already have. I want to use a local database so that the user can use most the app offline.
Initally I thought I could use the sqlite database created by Core Data in Xcode, but as I am reading things online it seems like this is not possible. Is this true? Or is there a good way to export it to something Android could use?
If not, I want to create a local database with values from a database on the cloud(I use Parse.com). How can I do this? The data on the cloud doesn't change very often (maybe twice or thrice a year) if that makes any difference.

This is a good tutorial to handle preloaded databases:
http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/
Essentially, once you have your precreated database, put it in your assets directory in your apk. Then on first app use, copy this from assets to "/data/data/YOUR_PACKAGE/databases/" directory.

You have to create the database by code in Android, using a DatabaseHelper http://developer.android.com/guide/topics/data/data-storage.html#db. If you want to use your already created database you will have to export it to SQL statements and then "import" them to your application.

Storing Db in asset folder or create via code

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.

Is there any way to extract queries from SQLite?

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

Shipping a (huge!) SQLite3 DB with Android app

I need to ship an app that uses read-only access to several preexisting SQLite3 DB's that each are a couple of 100MB's, total combines size > 1GB. The databases are created on a Mac, and are currently used in a shipping iOS app. I am pretty proficient in Java, but new to Android.
This leads to the following questions:
1) Will I need to modify the databases? I only plan to use them with SQLiteDatabase::rawQuery queries, so no nee for bindings and metadata I hope.
2) It it really correct that even if the DB's will only be used as read-only, I'll have to copy them out of the app bundle or download them to user directory on first start-up?
3) The queries can be slow. I want to run them in a thread and provide data via a callback. Is this done the way it's done in normal Java (Runnable/Thread), or will I have to use another method?
4) Is there anything else that's obvious to the Androidan that I have clearly missed?

1) No, it should work fine.
2) Yes, if you want to ship an APK that is over 50Mb you will need to use an expansion file.
3) For easy background tasks with a call back you could use an ASyncTask.

for a decent example of a sqlite helper class look here
you shouldnt need to edit the database. my sqlite databases work the same wether I access them via sqlite3 or with the android my sqlite helper class
once you copy them you can read and write
not really sure about this answer. i will say though that the database helper class above seems to work just fine (fast) but my db is smaller (500kb)
dont think so