Colors on colored watches

Here are list of colours available to all devices (search in page for COLOR_)
http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Graphics.html

But there is not best practices afaik on which colours you should use.

If you want to know how many colours a device has, these are listed here http://developer.garmin.com/connect-iq/user-experience-guide/appendices/

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 (out of the available list of the COLOR_*), as that way the user can pick the appearance that's best for them. Some people like darker background, some like lighter, etc...

before app settings, once you published a watchface, the first comment you'd get was often "I like it, but could I get a version with a XYZ color background?"

Couple more notes: With data fields, you can get the background color used for native data fields and do things based on that, and also, colors in the sim will appear "brighter" than they do on a real device..

Not for colors, but have you looked at the UX Guide in the SDK? The Programmer's guilde in the SDK too if you haven't looked at it yet.

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?

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?

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.

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.

I was thinking of pushing all the overhead to GCM or whatever the desktop version is. Something like:

<setting propertyKey="@Properties.handColor" title="@Strings.handColorTitle">
<settingConfig type="color" />
</setting>

And hopefully it could be written to pop up a color wheel or grid of colors that one could choose from.

*** 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.

Yeah, that works for the 14-color palette, but it'd be nice to be able to use the 64-color palette if it's available, but those other colors aren't named.

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.

Where the extra colors can be seen on the 64 color devices, is with bitmaps, but those are pretty much just handled by the resource compiler. (and I guess makeImageRequest() but I've never tried it).

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...

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.

That's the whole point. Let GCM or GCE deal with keeping track of the bit depth of whatever device. If it's grey scale, it'll give the user only four choices. If it's for bit, there will be only 14 choices. If it can support it, 64 color choices. It would be no trouble for the developer since they are dealing with the color as a variable, not as a list of sixty four separate values.

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...

I figure the user will find out that a particular color choice won't work and change the setting back, or the developer can still use the "list" type to constrain the color choices.

"color" doesn't prevent "list" from being used, just as other methods could also be used. I admit, using alphanumeric or float input and converting to hex for the color would be a UI hell, but there are other slightly less sadistic ways of choosing colors- like integer entry of an index number between 0 and 14 (or 63).

Setting a background colour

That sounds like a neat way to set the colours, but how do you set the background at all? All my watch faces come out black unless I draw a big rectangle in the background, but then I can't update the shape drawable with a new colour without creating a whole new layout.

Thx,

R.

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.

I use dc calls (no layouts) so I just use dc.setColor() and then dc.clear().