Under Review
over 1 year ago

BUG : String resource with a double quote character renders as escaped

If a string resource includes a double quote character (ASCII code 34), then the string is rendered incorrectly with a backslash escape character. For example, consider this string resource for a lat/lon position format that will be used as an option in a setting.

<strings>
    <string id="IncorrectString">hddd°mm'ss"</string>
</strings>

When that resource is retrieved and displayed, the result is displayed with an extraneous backslash character as such:

hddd°mm'ss.s\"

This happens regardless of how I try to escape or replace the quote character. CIQ is able to handle other replacements (eg. &apos; or &#176;) so it seems to only be an issue with the double quote character. For reference, I've tried:

  • hddd°mm'ss.s"
  • hddd°mm'ss.s\"
  • hddd°;mm'ss.s&quot;
  • hddd°mm'ss.s&#34;
  • hddd°;mm'ss.s&#x22;
  • hddd°;mm&apos;ss.s&quot;

All of those tries above return the same string with the backlash character: hddd°mm'ss.s\"

This happens in both the simulator and on various actual/physical devices.

I don't know if this is a holdover/bug related to this *old* issue -- https://forums.garmin.com/developer/connect-iq/f/discussion/126/cannot-escape-quotation-marks-in-strings/596 -- but I don't see how to accomplish this. And I looked at the Strings example code in case there was a weird way/workaround but none of the strings in that sample code include a quote character.

This occurs with SDK 4.1.6 but I don't know how long it's been like this.

dbrobert
  • over 2 years ago

    It's shows no respect for developers.

    Solution is simple 

    - fixing bugs or

    - cleary highlight in doc: THIS FUNCTIONALITY IS BUGGED, IT Will BE FIXED NEVER AND WORKAROUND IS... it will be honest

    We don't need a comment in the docs when the Garmin forum defenders are here to tell us that our bug reports are trivial and meaningless. Whenever a develop or user points out a problem with Garmin devices, the Garmin Connect ecosystem or Connect IQ, it's guaranteed that somebody will post the equivalent of "you're holding it wrong" and "stop complaining".

    Still a trivial work around (add your own double quote in the app) for something that's been like this for 7 years. 

    Saying that a bug has been around for 7 years and it hasn't been fixed isn't the brag that you think it is. It means that nobody cares. If Garmin doesn't care, why should users and developers care? People should just keep blindly giving Garmin their time, effort and money forever?

  • over 2 years ago

    Bug should be fixed, There is no place for any discussions in this case.

    Every new developer meet the same bugs for years and and waste his time to looking for bugs in his code. Let's wait for next trying using spo2 history, webreq with context, group in settings and dozens others bugged stuffs 

    It's shows no respect for developers.

    Solution is simple 

    - fixing bugs or

    - cleary highlight in doc: THIS FUNCTIONALITY IS BUGGED, IT Will BE FIXED NEVER AND WORKAROUND IS... it will be honest

  • over 2 years ago in reply to jim_m_58

    I don't see how it's remotely trivial, except in a US/English centric world. A big part of the resources, aside from only loading the strings you need, is to support other languages. If I want to display something in quotes (for whatever reason), it's "Hello World!" in English but in French you will usually see the use of guillemet, as such: « Bienvenue! ». So simply adding a double quote doesn't work because now I suddenly have to check the language, etc.

    I don't think this is necessarily a seven year old bug; the one that is linked above is to do with string variables not string resources. They are potentially two different things. Which is why I reported the bug in the first place.

  • over 2 years ago in reply to dbrobert

    Still a trivial work around (add your own double quote in the app) for something that's been like this for 7 years.  Which SDK are you using, as it may be fixed (I doubt it) in the latest.

  • over 2 years ago in reply to jim_m_58

      I am NOT looking for a solution to generate a lat/lon, I am reporting a bug with string resources. The quote character is valid within an XML in the manner I have presented.

    Regardless, that was simply the example I used, since it was the first thing to come to mind where a quote character might be needed within a string resource. But to counter your point, it would be localized because if it is used as a list entry in a setting or as part of a layout then the compiler warns you if you use hard-coded strings. It would also be localized for any language that wasn't Latin based; "hour, minute, second" is "시 분 초" in Korean.