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

Reply via email to