0

I have seen this question here, and was wondering if the same method of "pre-loading" a database for an android application still works. I will be developing my application on the 2.2 platform, but I want to make sure that going forward I will not have to completely redesign if I use this method.

Secondly, is this the best method if I have unchanging data that needs to be looked up? Or is XML a better choice?

Example: I have a Car, a car has attributes like weight, color, make, model, engine, etc. these all need to be accessed in a lookup but the attributes and entries will never change (and if they do, they change as such a slow rate that I would release an update to add the few things that changed).

Thanks for any help.

Community
  • 1
  • 1
heater
  • 195
  • 1
  • 1
  • 13

2 Answers2

3

Yes, the pre-loading method mentioned in the blogpost that article links to (http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/) still works for me after some tweaks prompted by a number of force closes from users. There were some issues with the database not being found on the Desire HD, which caused problems. It was difficult to isolate what exactly the problem was, but I think it was the file locations that was the problem. You should define

  private static String DB_PATH = Environment.getDataDirectory() + "/data/your/app/package/databases/"

instead of 

  private static String DB_PATH = "/data/data/your/app/domain/databases/"

I also changed all database access to writeable as I had read that caused problems, but not sure if that was really the issue.

In terms of your second question, I would say it depends on exactly how much data you have. If it's a lot of data, you're probably better off using a database anyway for performance reasons. There are pitfalls to using the SQLite APIs, such as apostrophes in the fields (make sure you use the convenience methods query, update and insert rather than rawQuery). But I'm sure there are with XML too - I don't think there's any "correct" method more what you are most comfortable with - i.e. do you prefer working with databases or raw XML? If neither, and you're not planning to do major updating or querying, I would use XML, or even JSON, because of the reasons above and what Jodes alludes to.

Stev_k
  • 2,118
  • 3
  • 22
  • 36
  • Ok, so maybe I don't want to use a database then. I have about 160 entries (which I feel isn't too much) each with 9 "single word" attributes, and 1 attribute that could be a paragraph. BUT I do want to be able to sort on a particular attribute. With that said is a database still the best option, and if done in XML would parsing it take too much time for the amount of entries I have? – heater Jun 08 '11 at 15:40
  • 160 doesn't sound like a lot no, but it might test an XML parser, and therefore a user's patience (even if it's only run when your app is opened). Having parsed CSV files before (using an external library) I think Android does make it easier for you with Sqlite, rather than XML parsing (although there will be a learning curve either way) so perhaps that is the way to go after all. There are some solid reasons for doing that [here](http://stackoverflow.com/questions/5213550/raw-resources-versus-sqlite-database/5213569#5213569) – Stev_k Jun 08 '11 at 21:06
1

The answer is not simple, you need to cross reference the version of SQLite used in different phones with the file format used for those versions.

A previous SO question showing difficulties in determining SQLite versions are here:

Version of SQLite used in Android?

And a page listing differences in file formats for different SQLite versions is here:

http://www.sqlite.org/formatchng.html

Community
  • 1
  • 1
Jodes
  • 14,118
  • 26
  • 97
  • 156