0

I am trying to put the characters '<' '>' in a string resource.

If I use the HTML encoding inside the string:

&lt;&gt; 

it works in the first build. However, after another build of the project, something automatically converts it to:

&amp;lt;&amp;gt;

So I can't use the previous encoding...

Trying to put "<" or even "\<" in the string will generate an XML error.

Trying to use CDATA will have the same behavior as above.

How do I put a '<' or '>' character with this crap?

UPDATE

I have added the "eclipse" tags, since after some discussion, it seems like an eclipse problem - something automatically edits my XML files. The updated question is - why does eclipse sometimes mess up my strings.xml file and try to encode special characters on its own?

SirKnigget
  • 3,614
  • 2
  • 28
  • 61
  • 1
    possible duplicate of [XML within an Android string resource?](http://stackoverflow.com/questions/4490073/xml-within-an-android-string-resource) – CommonsWare Jul 25 '13 at 00:01
  • @vikram I don't need ampersand. I need angle brackets. – SirKnigget Jul 25 '13 at 00:03
  • @CommonsWare CDATA doesn't for for me here, the SDK changes it automatically as said in the OP... – SirKnigget Jul 25 '13 at 00:04
  • `CDATA` works for the people who up-voted that answer, which now includes me, as I just tried it and am encountering no problems. I pasted in the precise string resource from that answer (`<![CDATA[bla]]>`), used it in a `TextView`, and the angle brackets showed up as expected. Multiple builds, with no issues. Even Eclipse isn't complaining. – CommonsWare Jul 25 '13 at 00:15
  • @CommonsWare This is exactly what I experienced. Thought it works. Then suddenly, my QA guy says it doesn't display right, I check my project, and... Eclipse turned the CDATA into something else. Happened 2 times already... I don't know where to look, my strings.xml didn't go through anywhere that could mess it up (no file transfer or anything like that). – SirKnigget Jul 25 '13 at 00:32
  • @vikram The values don't work inside a string resource, they just display 03C and 03E. – SirKnigget Jul 25 '13 at 02:41
  • Thanks for the info. I removed my comments as they weren't helpful at all. – Vikram Jul 25 '13 at 03:25
  • Make sure you are on a reasonably current version of the ADT plugin for Eclipse (current = R22). Beyond that, I have no clue what could be happening to you. – CommonsWare Jul 25 '13 at 10:12
  • @CommonsWare I use the latest ADT + tools version (22.0.4). It just happened again. I had a string resource with <![CDATA[]]> (I need to display ""). It worked about 2 builds. Today, I restarted eclipse, and surprise... It changed that sequence to &lt;M&gt;. – SirKnigget Jul 25 '13 at 11:46
  • Maybe there's some kind of unknown plugin, or weird eclipse setting that makes it manipulate XML files. I don't know where to look... – SirKnigget Jul 25 '13 at 11:53
  • Yeah, my guess is that it is something distinctive for your environment. I have restarted Eclipse several times since then (to upgrade MAT, then to upgrade ADT to 22.0.4), and the `CDATA` in my string resource has been unaffected by that, multiple builds, multiple project cleans, etc. I'm at a loss as to what specifically you're running afoul of, though. You might try a separate SO question, with Eclipse-y tags, explaining the XML-munging symptoms, and see if you get any responses. – CommonsWare Jul 25 '13 at 11:55
  • I edited the question and included additional tags and update. – SirKnigget Jul 25 '13 at 12:50
  • @sirknigget I'm pretty sure my solution should work. did your try it?! – Sadegh Jul 31 '13 at 06:52
  • @Sirlate Yes, I tried it, see my responses to CommonsWare. It works at first, but after some build cycles or restart, Eclipse automatically encodes the CDATA tag, as if that's the string I wanted to print. – SirKnigget Jul 31 '13 at 13:56

2 Answers2

2

This should work
<string name="angle_bracket">
<![CDATA[
<
]]>
</string>

if it's not, there problem is some where else in your project. (you can be sure by trying it in a new android project)

Sadegh
  • 2,669
  • 1
  • 23
  • 26
0

My current workaround is to use a hard-coded string in my Java class.

String s = "<M>";
mTextView.setText(s);

The other obvious given answer (using CDATA) is theoretically correct, so I'll +1 it, but it fails to work in my Eclipse environment after several build cycles, as Eclipse converts the CDATA section to an encoded string (and then my string displays "CDATA..." in my app).

Since I haven't found a cleaner solution, that's the answer.

SirKnigget
  • 3,614
  • 2
  • 28
  • 61