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
Related
I have an Android app I wrote that uses a sqllite database,(the app is used for the reservation) now I want to write the same app for iPhone and I want to use the same database I used in Android app. My question is can I use the same database in IOS.
If yes, then how can be used and where I place the sqllite database (I mean what folder)? and the users must be online to see the update in the database ?
Can I use an sqlite database created for android in IOS?
Yes, an SQLite database is a a file (or potentially 3 files if using Write-Ahead logging). It's simply a matter of copying the file(s).
Typically (i.e. if not specifying otherwise) an SQLite database is stored in data/data/your_package/database/the_database_name
where your_package is as per the App and the_database_name is the file name (may or may not have an extension).
Note if the database uses Write-ahead logging then 2 other files may exist, these being the_database_name-wal and the_database_name-shm. If they exist and are not empty, they need to also be copied.
However,
and the users must be online to see the update in the database ?
Is a completely different matter though. SQLite is not suited to a client/server situation, as you would have to write all the code to provide this functionality. See Appropriate Uses For SQLite.
Firebase may be an option if you don't mind Google's policies reqgarding information privacy. Otherwise you are likely then looking at something like MySQL/MariaDB.
I'm starting to build a new Android application which will help me to manage material movements in a warehouse. I would like to use use a database for the following applications:
A table that will be managed from a server (my PC probably) to add or delete new users.
Also, there must be another table that will be managed by users. This table will be used to add or delete materials from the warehouse.
I'm not sure what kind of database to use. I have some knowledge of using MySQL Workbench to create and manage databases. However, I've read the SQLite is better for Android applications. Can you please help me to choose which one will be the best for my application?
Thanks
If the databases run on the android device (which I guess they do not from the description) SQLite is probably the way to go. I like this tutorial but there are millions out there.
If they run somewhere ales (server) you can choose whatever system you are comfortable with since you will have to implement some protocol to communicate between mobile device and server anyway (most people would use HTTP/REST for that, but again, you can do that in a million ways)
SQLite is indeed better for Android applications.
In terms of preloading tables, schemas, and data into a Sqlite database, you can use the SQLiteManager firefox extension to do it.
Or, if you're too lazy to care about what types of database to use, might as well use ORMLite for Android to manage your tables and schemas within your Android application.
As for your server, you'll need to expose the API so that you can do HTTP/RESTful operations on it. You can choose whatever web applications that you prefer.
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
I am using SQLite database in my application. I want to make my SQLite database password protected.
HWACI (the commercial arm behind SQLite development) provides (for money) an encryption engine called SEE. It's quite painless to integrate this in if you are building your own SQLite source, and it's also very easy to use.
SQLCipher is an open source alternative to SEE. I've never used it but I would expect it's as easy to integrate and use as SEE.
As far as I know: no, you can't do it in a simply way.
Posible choices:
-You could simply encrypt the data you want to be secure when inserting it and decrypting the values when you want to play with them. In my opinion this is the best choice.
-You could encrypt the db file in your app's folder. And decrypt it every time you want to access it (not very recommended).
Also note that your DB file is stored in your app's private directory, so in most terminals (except for rooted ones) neither the user nor other apps will have r/w access.
EDIT: For the first choice, I recommend you to take a look to mah's answer if you don't want to implement your own encryption methods =)
I have a huge set of data that I want to insert into the sqlite database before the user is able to do anything inside my application. Right now I have all my data stored in CSV files, then I parse those files and use DatabaseUtils.InsertHelper to do a bulk insertion, but this is taking to long to complete.
I stumbled on this tutorial some time ago and I'm wondering: is it safe to distribute a pre-generated sqlite file? Can I run into problems due to different versions of SQLite on different devices?
I'm planning to support Android 2.1 and higher.
I suppose it depends on your definition of safe. It is certainly possible as long as the database conforms to the metadata table spec Android expects, which is what that tutorial you stumbled upon is showing you. You won't have to worry about version conflicts with SQLite as that is a package built into the core platform and isn't something OEMs add to or implement anything on top of.
However, if by safe you mean "protected" you would need to take special steps to ensure that your database is not externally readable if that is a concern. If you simply place the preconstructed DB into assets/ and copy it over, anyone who can properly deconstruct an APK file can view your database data. This may or may not be an issue for you.
The best approach is to populate this data in the database, keep the database in assets & then copy it to the device ... You can follow this complete sample code here.