Should I be extracting strings from source in core java the way android does?

Question

I just started doing android development stuff after getting pretty comfortable with Java. Android apps tend to do this weird thing where they have all strings for their program held in an XML file called strings and the program refers to the strings instead of string literals in the code or even String objects.

The only reason I can think of to do this is internationalization. Is that it? What are the advantages/disadvantages of this approach? Should I be employing it in my other programming endeavors (such as regular Java)?

Seems like an unnecessary level of abstraction.

Answer 1

The reason Android puts strings in separate XML files is for localization.

Should you do it? Yes. Even if your app will support only one language, you never know if you'll be supporting others in the future, in which case you would only need to add another XML file.

This is not weird at all, it is actually the rule.

All platforms have some sort of mechanism like this. Microsoft's .Net platform uses .resx files, Android uses .xml files and "regular Java" uses .properties files (see the docs).

Answer 2

According to this stackoverflow question the reason for the strings in XML is for localization.

Should you do this in your other endeavours? The hard line answer is probably yes. That said, my gut tells me, if you're only going to deploy in one language then possibly it's a premature optimization. So my answer is a hard maybe.

Answer 3

If it's only about localisation then there would be many 'regular' Java applications where this wouldn't be necessary, or even helpful. In cases where the program uses strings that won't be displayed to humans then multiple languages won't be important. An example of this would be where strings are used to build text based protocols to talk to external systems that expect a specific language for the syntax of the protocol messages e.g. JSON.