On Mon, Oct 4, 2010 at 11:44 AM, DanH <danhi...@ieee.org> wrote: > It's dumb to use a database -- would take up much more space than the > strings in arrays.xml, and be slower to access.
You will note that the OP didn't put constraints on those criteria. The OP put a constraint on memory usage. Given the stated constraints, a database is a reasonable solution. > Of course, if there > is no way to access a single element from arrays.xml ... Correct, other than by loading the whole array, which the OP is trying to avoid. > ... one could, since this is a fixed database, use a "dope vector" > into a file: Create a file with all the strings end-to-end, and > another file that contains the start-end offsets of each string. > Access the second file randomly (or have it loaded into an array) to > get the offsets, then access the first file at those offsets to get > the string. I don't know if you can somehow access a file in assets > randomly but if so you could put these files there and name them .jpg > or some such (to prevent compression). Otherwise you should copy them > from assets to real files (taking care to name the string file .jpg or > some such if it might be >1M). This is a perfectly delightful solution for somebody with a background in algorithms. Do you know of any Java code generator that creates such structures? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
