> The reason for the big difference is that strings in res/values are > stored uncompressed in UTF16. They can then be memory mapped. (The > Android dev team later said if would have been better if they went > with UTF8 for size)
Interesting, thanks. > Perhaps you could leave one language (the most used) in res/values for > safety, speed, and the generations of the IDs. And then create > something that will load strings using the same IDs from xml for other > languages. That's a great idea but it means an extra 130k just to have English in res/ and the app doesn't go on SD (service,widgets) so I can't justify those extra bytes just for ease of building I think. I'm currently leaning towards parsing the xml files in Perl as a pre- build step and replacing R.string.NAME in the java source with the ints. I'll leave the values-xxx directories in res for eclipse building and move them to assets/ as part of the build (I copy everything to /tmp for release building anyway) The most time consuming is going to be replacing getString() with MyRes.getString() and pulling all the @string specs in layouts into code. Pent -- 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
