Let me get this straight - you would rather have a runtime exception that
you just catch and ignore than a compile time error that will quickly
identify your problem and allow you to fix it on the spot?
Why exactly would you prefer this?
I want to change the behavior of my app by means of
Resources has getIdentifier() for this. However, this is significantly
less efficient than just using the R static data member. Use it if you
have to (and cache the lookups), but avoid compile errors doesn't
strike me as a great reason to do so.
Thank you.
As I described in more detail in my
On Fri, Mar 19, 2010 at 3:53 AM, HippoMan hippo.mail...@gmail.com wrote:
I want to change the behavior of my app by means of the presense or
absence of some items in strings.xml. This allows me to control this
behavior by simply adding or deleting the items, and then clicking the
Save icon in
If you want to 'dynamically' load these strings, you probably could
use reflection.
Some 'pseudo' code:
public String somehowGetStringAnotherWay(Resources res, String
stringName) {
try {
Field stringField = R.string.class.getField(stringName);
int stringID = stringField.getInt(null);
For one thing, it allows you to alter the behavior depending on the
device characteristics.
It also is also easier to script such changes, via XSLT.
And it's one way pulling these configurable pieces into a single
location. Of course, a dedicated class accomplishes this.
It doesn't sound like
I'd suggest instead true/false as the string values. It simplifies
your code and gives you the same result.
On Mar 19, 1:53 am, HippoMan hippo.mail...@gmail.com wrote:
Let me get this straight - you would rather have a runtime exception that
you just catch and ignore than a compile time error
6 matches
Mail list logo
