Handle soft labels in Android

Issue

I am building an application and use labels in the following areas.

1. Component Names (TextView, Buttons etc)
2. Buttons in alert boxes
3. Parameters to AsyncTask
4. Key names in Intent extras
5. Log tags

I have got strings.xml files to store and use labels. I am using using it for category 1. What do you think is the best option for others?

res/strings.xml or Constants class ?

Solution

I'll suggest to you what I normally do:

For everything that the user will read on the screen or be referenced in anyway from a XML layout, use strings.xml. I reckon that includes your 1 and 2. But remember that for AlertDialogues you can also use android.R.string.ok or android.R.string.cancel, etc; that will vary from use to use.

Also for project config values, or API keys, you could have a config.xml with String, Integers, etc. Something that makes easy to later on change those values without diving into the code.

For AsyncTask, it varies a lot of what work it is doing, but usually a network, DB or disk operation, and I try to include private static final String URL_PT1 = "http://..."; etc, in the classes themselves, as they are the only interested in knowing that address (or DB columns, or file prefix)

For key names (both in Intent and Fragment arguments) I use private static final String KEY_VALUE = "renjith.Key.MyClassName.VALUE"; and then create a public static Bundle getIntentExtras(String value) inside that class that will properly allocate the value in the extra. That's because only that one class needs to know about it's KEY values, there's no reason to make those public accessible, that will just create errors for outside classes doing it wrong.

For Logs (5), create on every class a private static final String TAG = "Renjith.ThisClassName"; (and for Fragments make the TAG public to be used in transactions). That way you can create a filter in LogCat Renjith.* and you can easily identify from where this log is coming from

edit:

For sharedpreferences it depends:

for GlobalSharedPreferences I would create one class to handle them with static set/get methods that must receive Context and all keys private static inside that class.

For local shared preferences (that only one class is interested in saving/retrieving) I would handle in a SharedPreferences file with the same name as that class and all the keys as private static inside that one class.

Again, same philosophy, only the classes that really need to know about those details will know about them, and abstracting to the rest of the classes with direct method calls.

Answered By - Budius