Is there a SDK guideline or something like web colors for the best color appearance? Cannot found any informations. Btw the SDK documentation is something stupid.
I no longer hard code colors (in most cases) but use app settings so the user can pick things like background, time, icon,error colors...
But you still have to code for the colors in the app settings, right? And that whole list of colors gets copied to all the features that need color settings? (is there a simple way to reuse app settings selections over many variables?)
Wouldn't it be great if app settings had a color picker, and it could automagically adjust for the color depth of the device it's paired to? And then you don't have to try to use words to describe the colors- how would you describe 0x0055AA? Navy blue? Light blue? Off blue? This is a vocabulary test, isn't it?
Now if there was a "color picker" in the app, that would be far more overhead. And considering that people probably won't be changing colors all the time, it would be kind of wasted space most of the time.
<setting propertyKey="@Properties.handColor" title="@Strings.handColorTitle">
<settingConfig type="color" />
</setting>
*** I use names like "Dark Green" for Gfx.COLOR_DK_GREEN, and with app settings, I can be looking at a watchface, etc, and change the colors with GCM in realtime.
A year+ back I played around with using colors outside the base COLOR_* values for text/etc, and many were so close to one of the COLOR_* values on the screen, it wasn't really worth the trouble, as you'd also have to handle devices that only have the COLOR_* ones.
With having a "color" type in app settings, Garmin would also need to handle cases where for one reason or another, all 14 colors wouldn't be available. for example, a developer may want to only allow black and white backgrounds for some reason (maybe due to a bitmap used), and you'd want the same interface if the "time" could also be set to any of the 14. With the "list" app settings, that could be easily handled...
Basically, what I do us use a "list" in app settings that returns 0 to 13 (I don't use "Transparent"). Then in my code, I use that value as in index to an array that has "Gfx.COLOR_WHITE", etc. (I didn't want to use the rrggbb values in settings **). So I have the overhead of the small array in my code.
Now in the settings, true I may duplicated that same "list" a few times, but that doesn't impact the size of the .prg, as the settings part winds up as a .json that gets packaged and sent to the app store in the .iq. For a given color-type (like background) in my code It only takes 1 Number, plus the array that's shared (pretty cheap memory wise).
Now if there was a "color picker" in the app, that would be far more overhead. And considering that people probably won't be changing colors all the time, it would be kind of wasted space most of the time.
** back when app settings first came out there was also a problem with lists and GE, where the index was returned instead of the value, and this way the index and value were the same
*** I use names like "Dark Green" for Gfx.COLOR_DK_GREEN, and with app settings, I can be looking at a watchface, etc, and change the colors with GCM in realtime.