Ticket Created
over 3 years ago

CIQSTORE-3304

Issue handed off to CIQ store team to investigate.

Settings list items should be allowed to have the same names

As has been noted elsewhere, settings configs are relatively cheap, but not free. Every string resource you add to the settings increases your programs memory footprint.

I have a datafield which supports lots of different data types (pace, speed, distance, heartrate etc), and for each such field type it also supports "Avg <x>" (in some cases), "Lap <x>", "Last Lap <x>" and "Trailing <x>" (where Trailing <x> is the average over some configured trailing distance). As a result, every new data type I add increases the memory footprint significantly, since it adds 5 new entries to the field setting list, and hence 5 new strings, rather than just one.

But I just had a thought. I don't really need the list to say:

  • Pace
  • Avg. Pace
  • Lap Pace
  • Last Lap Pace
  • Trailing Pace
  • Speed
  • Avg. Speed
  • Lap Speed
  • Last Lap Speed
  • Trailing Speed

I could get away with:

  • Pace
  • - Avg.
  • - Lap
  • - Last Lap
  • - Trailing
  • Speed
  • - Avg.
  • - Lap
  • - Last Lap
  • - Trailing

And not only would I save lots of strings, but it would be even clearer to read, since the main headings would stand out.

But when I tried this, the UI only shows the first occurrence of each subfield. It seems to be filtering out later, same named list items, even though they have different values.

Could it just not do that? The meaning of two identical entries can be obvious from context - and if it's not, well thats the application writer's problem, not something the compiler needs to try to fix for them.

Alternatively, could we have first class sublist items? That could make the ui for cases like this much better anyway...

Parents
  • It's always best to include as much examples as possible. It is not trivial to understand the problem. If I try to reverse-engineer your problem it's something like:

    <settings>
     <setting...>
      <settingConfig type="list">
        <listEntry value="1">@String.pace</listEntry>
        <listEntry value="2">@String.avg</listEntry>
        <listEntry value="3">@String.speed</listEntry>
        <listEntry value="4">@String.avg</listEntry>


    And what you're saying is that the bug is that even though the values are different (2 vs 4) it removes 4 because the strings are the same?

Comment
  • It's always best to include as much examples as possible. It is not trivial to understand the problem. If I try to reverse-engineer your problem it's something like:

    <settings>
     <setting...>
      <settingConfig type="list">
        <listEntry value="1">@String.pace</listEntry>
        <listEntry value="2">@String.avg</listEntry>
        <listEntry value="3">@String.speed</listEntry>
        <listEntry value="4">@String.avg</listEntry>


    And what you're saying is that the bug is that even though the values are different (2 vs 4) it removes 4 because the strings are the same?

Children