Acknowledged
CIQQA-3615

feature-request: add maxLength, maxSize attributes to string resources and fail at compilation if a string is too long

Short feature-request:

Please add a new attribute to string resources to let the compiler know the maximum length * of strings, and enforce it in such a way that if a longer string is present (either because I edited the string or because it's a translation) then fail at compile time.

i.e:

resources/strings.xml:
<string id="stepsUnits" maxLength=16>steps</string>

resources-tha/strings.xml:
<string id="stepsUnits">ขั้นตอน</string>

*) I think it would make sense to give the developer to possibility to set a constraint to either the character count or the byte size or both. The idea is that for cases like the above I would need to be able to set a maxSize in bytes, but in many other cases where the constraint comes from a UI point of view it would make sense to have a maxLengh in characters.

Long story: I got lot of complaints about a strange crash in my app. Today I realized that it only happens in Thai language devices. This helped me to find the bug:

var stepsUnits = WatchUi.loadResource(Rez.Strings.stepsUnits) as String;
mStepsActivityField = session.createField("steps", 0, FitContributor.DATA_TYPE_UINT32, { :mesgType => FitContributor.MESG_TYPE_SESSION, :units => stepsUnits });

And the Thai language translation is:

<string id="stepsUnits">ขั้นตอน</string>

<string id="stepsUnits">ขั้นตอน</string>

According to the documentation :units is at least 16 bytes. So now I found out the hard way that:
- Thai either 4 bytes / character
- that the 16 bytes includes the terminating 0 of the string.

Parents
  • > So now I found out the hard way that:

    ...

    > that the 16 bytes includes the terminating 0 of the string 

    This has been brought up before...by you.

    March 31, 2025: https://forums.garmin.com/developer/connect-iq/i/bug-reports/documentation-please-improve-docs-for-session-createfield-units 

    documentation: please improve docs for Session.createField :units

    According to developer.garmin.com/.../Session.html :units has at least 16 bytes. However it's misleading, because you can actually only use 15 bytes (i.e 15 ASCII characters) long text, because of the terminating null. There's no mention of null in :units, only in :count.

    Did you really just find out now?

    It is *sort* of implied by this part of the documentation:

    :count — (Lang.Number) —

    The number of elements to add to the Field if it is an Array

    This is also the maximum combined size of strings plus null terminators if the type is DATA_TYPE_STRING (Default 1)

    To be clear, I'm saying that if :count includes the nul terminator, then it's reasonable to assume that "At least 16 bytes are available" also includes the nul terminator.

    I agree the docs could be improved, but that's an evergreen observation.

Comment
  • > So now I found out the hard way that:

    ...

    > that the 16 bytes includes the terminating 0 of the string 

    This has been brought up before...by you.

    March 31, 2025: https://forums.garmin.com/developer/connect-iq/i/bug-reports/documentation-please-improve-docs-for-session-createfield-units 

    documentation: please improve docs for Session.createField :units

    According to developer.garmin.com/.../Session.html :units has at least 16 bytes. However it's misleading, because you can actually only use 15 bytes (i.e 15 ASCII characters) long text, because of the terminating null. There's no mention of null in :units, only in :count.

    Did you really just find out now?

    It is *sort* of implied by this part of the documentation:

    :count — (Lang.Number) —

    The number of elements to add to the Field if it is an Array

    This is also the maximum combined size of strings plus null terminators if the type is DATA_TYPE_STRING (Default 1)

    To be clear, I'm saying that if :count includes the nul terminator, then it's reasonable to assume that "At least 16 bytes are available" also includes the nul terminator.

    I agree the docs could be improved, but that's an evergreen observation.

Children
No Data