2

I followed the article here about how to precreate a sqlite database and copy it from the assets folder to the system db for use in an Android app: http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/

I then found this Stackoverflow answer that says doing this is a bad idea: https://stackoverflow.com/a/6948334/211457

I also found this answer and comments saying this technique doesn't work on the Samsung Galaxy S, Motorola Bionic, and Evo 4G: https://stackoverflow.com/a/620086/211457

I only have a Motorola Droid to test with and it works fine. I want my app to work on all Android phones. The reason this technique is preferable to loading the database via sql inserts and create tables is it's quicker on initial load.

Do you think precreating a database and loading it on Android is an OK thing to do, or should insert statements always be used instead?

Community
  • 1
  • 1
Andy
  • 1,815
  • 2
  • 22
  • 49
  • 1
    I found no mention of it "not working" in Evo and others in the (3rd) supplied link. Also the answer saying it is a "bad idea" is wrong; the SQLite file-format is well-defined (all the details are available on http://sqlite.org) and has been historically, stable. Only a *non-compliant* SQLite engine would change this. Now, there *are* some edge-cases of programs breaking SQLite compatibility (e.g. Firefox with the SQLite database size-padding), of which I view as "non-conformant". –  Sep 03 '12 at 20:00
  • In the second link here's a quote: "it's a common trick to pre-populate database content by bundling a sqlite3 .db file in your application's assets, and then using it intact after install. It isn't guaranteed to work, though, not even between devices running the same version of the Android platform." – Andy Sep 03 '12 at 20:01
  • That is, you can take an SQLite database -- with it's well-defined ABI -- to **any** hardware and a *valid* SQLite implementation (of the same database file version) will be able to read and write the file format. Bitness does not matter. Endianess does not matter. Storage hardware does not matter. Speed does not matter. *If this is not the case then it is a **broken** SQLite implementation.* YMMV, as the world is far from perfect. Also, "mods" such as encryption are an extra topic/concern. See http://stackoverflow.com/questions/2157330 –  Sep 03 '12 at 20:04
  • In the third link scottyab says: "It works ok on nexus s, but issues with the Samsung Galaxy S on 2.3.3" and gonzobrains says "I have tried this approach but the database fails to open on some models, such as Galaxy S, Motorola Bionic, and Evo 4G. Any ideas?" – Andy Sep 03 '12 at 20:05
  • (Oh, invisible comments aren't searched, see it now.) –  Sep 03 '12 at 20:05
  • Now, while the SQLite *file* format is very consistent, there are some features which may only be found in certain/newer versions including triggers and referential constraints and even WAL-mode. There are also some pragma options which are stored as part of the database and might be "carried over". But neither of these affect the SQLite storage format. –  Sep 03 '12 at 20:15
  • Are you using transactions properly? I have no Android experience with SQLite, but on other platforms using transactions properly will improve performance hundreds (thousands, millions) of times. – Steven Fisher Sep 04 '12 at 03:54

1 Answers1

0

If you don't care about security at all, than store on Android in whatever you prefer. If you have 1 single info which shouldn't be accesible for all web, than you should use remote storage: webservice + server side database. Encryption isn't safe if is stored in Android if the key is in your app.

  • Yes, but this question isn't about "is the data safe", it is about "is this approach guaranteed to work reliably"-safe? –  Sep 03 '12 at 20:33