I would hardly say that using a database to store a large number of strings is obfuscation.
I'm not a particular fan of SQLite, but it's a case of identifying the tools that the platform makes available and evaluating them against the benefits and drawbacks of writing code to do the same thing. You don't provide any proof that SQLite will be significantly slower, or require significantly more memory, but let's take that as given. Even if the code to do the index lookup is simple (and it is) you also have to write the code to generate the index, and package it in some way that will integrate with your build process. And you end up with a read-only data structure -- what if you don't foresee that users want to add entries? Or want entries browsable by category? Or want the option to search for entries? The poster hasn't given us much information about how these entries will be used, because of this, strongly advising against the use of a database seems unwise to me. Especially since moving from the solution you propose to one where data can be modified is far from trivial. For starters, your process could be killed in the middle of any Java IO operation. Tom. On 4 October 2010 20:07, DanH <danhi...@ieee.org> wrote: > Cute. Android jumps through hoops to save a few lousy bytes here and > there, and then folks push using SQLite for everything short of > addition tables. An SQLite DB requires 3KB overhead plus about > another 20 bytes per record. But more importantly, SQLite has to > create substantial runtime structures to access the database > efficiently, chewing up precious RAM. And it's an order of magnitude > slower. > > But I suppose if you want to obfuscate an application, SQLite is the > way to do it. > > On Oct 4, 1:25 pm, Tom Gibara <tomgib...@gmail.com> wrote: > > This combination of a data file + supplementary file for faster access, > is > > indeed very well established. Developers have spent considerable time > > providing robust and efficient implementations, where they are often > > referred to as tables and indexes, and exposed via a software component > > that's often called a database. > > > > Tom. > > > > On 4 October 2010 18:45, DanH <danhi...@ieee.org> wrote: > > > > > Well, when I look at the web references for "dope vector", they're > > > mostly referring to a different (and more obscure) concept than the > > > one I'm talking about: > > > > > The concept is blazingly simple -- something you'd invent if you > > > didn't already know of it. > > > > > Consider that you have a set of variable-length elements (maybe > > > strings) that you want to access by numeric index, you could allocate > > > an NxM byte array (where M is the size of the longest element) but > > > that would be inefficient (in space) if many of the elements were much > > > shorter than M. > > > > > So instead you pack the elements together, head to tail, in a single > > > byte array. Then you create another array, Nx2 integers. If you > > > index this second array by the "index" of one of your variable-length > > > elements, the first word in the row is the offset to the start of that > > > element (within the first array), and the second word is the length of > > > the element. > > > > > But then you notice that, for all elements except the last, for a > > > given element index X, the X+1 entry in the dope vector contains the > > > offset of the first byte after the Xth element. So instead of having > > > two columns in the dope vector you can (if you wish) just use one, and > > > add at the end an N+1th entry that addresses the first byte after the > > > end of the last element. > > > > > In this case, you replace the arrays with randomly-accessed files, but > > > that's a trivial transformation (aside, as I said, from the ugliness > > > of the Java file access classes). > > > > > On Oct 4, 11:51 am, Mark Murphy <mmur...@commonsware.com> wrote: > > > > On Mon, Oct 4, 2010 at 12:38 PM, DanH <danhi...@ieee.org> wrote: > > > > > Background in algorithms??? It's a Programming 101 problem -- > anyone > > > > > with a modicum of programming skill should be able to do it. > > > > > > You make a few assumptions, in terms of background and experiences, > > > > that may or may not be accurate. > > > > > > > It's no > > > > > harder than writing the program to read lines from a file and write > > > > > them to a database -- the only real difficulty is navigating > through > > > > > the maze of Java classes you need to do file access. > > > > > > The lines of code count is probably somewhat longer. More > importantly, > > > > though, the database solution is well-trod ground, with quite a few > > > > samples. "Dope vector" has remarkably few hits on search engines, let > > > > alone any code that can be readily applied in this case. Now, > > > > admittedly, not every occurrence of this pattern may use that term -- > > > > when I used a variant on this approach on the Apple IIe in the late > > > > 1980's, I had not heard of the term. > > > > > > Perhaps you would like to contribute, by either augmenting the dope > > > > vector Wikipedia page, or by creating a couple of Java classes for > > > > creating and reading dope vector files, to help make it easier for > > > > people to take advantage of your expertise in this area. > > > > > > -- > > > > Mark Murphy (a Commons Guy)http://commonsware.com| > > > > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > > > Android Training...At Your Office:http://commonsware.com/training > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > android-developers@googlegroups.com > > > To unsubscribe from this group, send email to > > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@googlegroups.com> > > > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
