> > There's no index "lookup" -- it's a "look-at" operation -- no
searching. I didn't mean to imply that there was searching. And you have to write the code to build the other ways too. One way or another there must be logic to read the (presumably plain-text) source file and insert it into: -- An XML document -- An SQL row -- Something else The android SDK comes bundled with sqlite3 which includes an import command which could help a lot (I've not used it so I couldn't say for sure). And with both the XML document and the SQL row you still need some logic on the other end to extract the data and make it "live", so no savings there (probably a loss). Not sure where XML has come into it, but as for a SQL database, yes, this will need to be copied out of the raw resources before it can be opened and used as such. I didn't say that a database is less work, I wanted to draw attention to the fact that the algorithmics are only part of the effort involved. In terms of dynamic update, you've got a problem in any case as to how you manage that atomically. Easiest is to download the new files and then swap them in in place of the old, a simple process, and no more subject to problems on a crash (actually less so) than swapping in a new copy of the DB. I anticipate that swapping out a copy of the DB would only require the additional step of first closing it beforehand and reopening it afterwards -- little different than closing and reopening the 'packed string' file. Of course, with such a file, you are limited to supplying complete updates (or at best incremental updates) to the file. A database affords more flexibility. And the OP specifically framed it as a read-only data problem. The absence of a requirement stating that data are changeable is not the same thing as the stated requirement that they are not. I think the main difference here is that I am not discounting alternative approaches -- I have used a compact frequency weighted trie to package a 250k word corpus into an apk and I wouldn't have considered a sqlite DB for this task -- whereas you have said it's dumb to use a database. I don't think it is necessarily dumb, even if there are more efficient alternatives, because applications evolve, and a database might actually be less work in the long run. Tom -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
