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
  • I don't really understand the problem, I do use some strings in multiple places. However I'm sure you have a different case, which probably would've been very easy to see, have you included some example settings.xml

Comment
  • I don't really understand the problem, I do use some strings in multiple places. However I'm sure you have a different case, which probably would've been very easy to see, have you included some example settings.xml

Children
  • I thought I gave a pretty clear example. The way it is now, I have 5 strings per "kind" of setting. ie 5 for pace, 5 for speed, 5 for heart rate, 5 for time etc. But they're really a main "kind" plus a subkind.

    Right now, the subkinds have to be in the form Kind + Subkind, because otherwise you end up with duplicates in the list, and the settings manager ignores the later duplicates.

    If I could present the list the way I proposed in the second example, I only need one string per kind of setting, plus 4 more. So with 2 "kinds" as presented above, I have 10 different strings in the first case, but only 6 in the second. With 10 kinds, I have 50 strings now, but would only need 14 if duplicate strings were allowed in lists (note that obviously the *values* in the lists would be different. But they're numbers. Its just the strings that get presented to the user that could be saved.