Is there a way to determine the device's color depth?

Here is where the number of colors is documented.  There's no way to get this with CIQ, but using jungles, you can do things based on the number of colors.  Some older devives only support 16, some, like the edge130 are only B&W, the fr45 and 55, 8 colors.

https://developer.garmin.com/connect-iq/compatible-devices/

And in the sim, colors won't be the same for MIP devices.  An example is red text on a back background may look ok in the sim, but its hard to read on a device.

Thanks - that web page has lots of useful information. When I looked at it, I was hopeful there would be an underlying endpoint that returned everything in json or xml format. But digging through the page a bit, thats not quite the case. It looks like they're using webpack to package up the data inline into a .js file, and then use JSON.parse to parse the literal string; and being webpack, the name of that .js file isn't predictable (ie knowing what it is today won't help tomorrow).

So I wrote a quick and dirty parser that reads the top web page via curl, finds all the scripts *it* loads from the root of developer.garmin.com, fetches them, extracts the contents of any JSON.parse calls with literal string arguments, and passes the result to jq to parse out the bits I want, which gives me: https://gist.github.com/markw65/f1949755e59c68116e03073b7c33df05

There's actually an easy way to figure out colors for watches and your app doesn't really need a json file and things can be done with jungles.  You'll need some way to determine what device your app is running on to use the json.

The fr45,55 and swim2 are 8 color

Other CIQ 1 devices (fenix3, etc) are 16 color

The fr735 is 16 color and the va-hr, 64 color for CIQ 2 devices

CIQ 3 and higher MIP displays (except fr55), 64 color

Venu devices are high color

Colors is just one of the things that comes into play with supporting a number of devices and there are things that aren't in that chart..  Things like does the device have a baro or not, the size and whitespace with fonts, support for onPartialUpdate() and background services.  Except for fonts, these things are easy to determine with a simple "has" statement in your code.

My plan was to use the json to generate a monkey-c dictionary mapping deviceId to bitsPerPixel (or display type, or something). But while looking for a way to map the device display names back to the deviceId, I came across the compiler.json file that lives in each device directory. It has everything I need in it. So I was able to extract everything via:

cat ~/Library/Application\ Support/Garmin/ConnectIQ/Devices/*/compiler.json | \
    jq --slurp 'map({ key:.deviceId, value:{ displayType, displayName, bitsPerPixel } }) | from_entries'

Which gave me: gist.github.com/.../bc26030cdf9c4de65b2e1bcf98a12b31

So now I can combine that with xmllint applied to my manifest.xml, to generate a .mc file with the dictionary I need:

xmllint --xpath '//*[local-name()="product"]/@id' manifest.xml | \

    perl -pe 's/id=/\n/g' | jq -r --slurp --slurpfile devinfo deviceinfo.json \

        '. as $desired | "{", ($devinfo[] | to_entries | map(select(.key == ($desired[]))|["\""+.key+"\"", .value.bitsPerPixel]|join(" => ")) | join(",\n")),"}"'

{
"fenix3" => 4,
"fenix3_hr" => 4,
"fenix5" => 8,
"fenix5plus" => 8,
"fenix5s" => 8,
"fenix5splus" => 8,
"fenix5x" => 8,
"fenix5xplus" => 8,
"fenix6" => 8,
"fenix6pro" => 8,
"fenix6prosystem5preview" => 8,
"fenix6s" => 8,
"fenix6spro" => 8,
"fenix6xpro" => 8,
"fr230" => 4,
"fr235" => 4,
"fr245" => 8,
"fr245m" => 8,
"fr935" => 8,
"fr945" => 8,
"venu" => 16,
"venu2" => 16,
"venu2plus" => 16,
"venu2s" => 16,
"venu2system5preview" => 16,
"venud" => 16,
"venusq" => 16,
"venusqm" => 16
}

And yes, there's lots more device dependent info - but currently this is all I need that isn't directly accessible via Toolbox apis. And as far as I can tell, if I do need anything else, it should be available in compiler.json.

I've not yet looked into using jungles (I've only just started looking at building for anything other than devices I own) - but it looks like if I do take that approach, I can still use something similar to the above to generate a suitable jungle file. 

... and of course, that doesn't work. I thought there was an api to get the deviceId (the "product" fields in manifest.xml).

So I've switched to using a jungle, generated by a similar script. 4 bit devices include source-4, 8 bit devices include source-8 and 16 bit devices include source-16. There's a single file in each directory with "var bitsPerPixel = <n>". I don't currently plan to support 1 or 2 bit devices.

fenix3.sourcePath = $(fenix3.sourcePath);source-4
fenix3_hr.sourcePath = $(fenix3_hr.sourcePath);source-4
fenix5.sourcePath = $(fenix5.sourcePath);source-8
fenix5plus.sourcePath = $(fenix5plus.sourcePath);source-8
fenix5s.sourcePath = $(fenix5s.sourcePath);source-8
fenix5splus.sourcePath = $(fenix5splus.sourcePath);source-8
fenix5x.sourcePath = $(fenix5x.sourcePath);source-8
fenix5xplus.sourcePath = $(fenix5xplus.sourcePath);source-8
fenix6.sourcePath = $(fenix6.sourcePath);source-8
fenix6pro.sourcePath = $(fenix6pro.sourcePath);source-8
fenix6prosystem5preview.sourcePath = $(fenix6prosystem5preview.sourcePath);source-8
fenix6s.sourcePath = $(fenix6s.sourcePath);source-8
fenix6spro.sourcePath = $(fenix6spro.sourcePath);source-8
fenix6xpro.sourcePath = $(fenix6xpro.sourcePath);source-8
fr230.sourcePath = $(fr230.sourcePath);source-4
fr235.sourcePath = $(fr235.sourcePath);source-4
fr245.sourcePath = $(fr245.sourcePath);source-8
fr245m.sourcePath = $(fr245m.sourcePath);source-8
fr935.sourcePath = $(fr935.sourcePath);source-8
fr945.sourcePath = $(fr945.sourcePath);source-8
venu.sourcePath = $(venu.sourcePath);source-16
venu2.sourcePath = $(venu2.sourcePath);source-16
venu2plus.sourcePath = $(venu2plus.sourcePath);source-16
venu2s.sourcePath = $(venu2s.sourcePath);source-16
venu2system5preview.sourcePath = $(venu2system5preview.sourcePath);source-16
venud.sourcePath = $(venud.sourcePath);source-16
venusq.sourcePath = $(venusq.sourcePath);source-16
venusqm.sourcePath = $(venusqm.sourcePath);source-16

Thanks for all the hints - I think I've finally got something that does pretty much what I want. And if I end up needing even more customization, the jungle approach should make that straightforward.

See https://developer.garmin.com/connect-iq/reference-guides/devices-reference/

for the specific colors supported on each device

Or for a programmatic way to find the palette, you can again extract it from the compiler.json files:

cat ~/Library/Application\ Support/Garmin/ConnectIQ/Devices/*/compiler.json | jq --slurp '(map({ key:.deviceId, value:{ displayName, bitsPerPixel, palette } })) | from_entries'

Producing: https://gist.github.com/markw65/cc23444ee3fb100c778c8ac4f49d4e36

Or you could group by bits/palette so that for each distinct palette, you have the corresponding set of devices:

cat ~/Library/Application\ Support/Garmin/ConnectIQ/Devices/*/compiler.json | jq --slurp 'map({ deviceId, displayName, group: {bitsPerPixel, palette} }) | group_by(.group) | map({display:.[0].group, devices:map({deviceId, displayName})})'

Producing: https://gist.github.com/markw65/8abdaa3ea8be9721c90cb6f291ea739f

Which you could further manipulate to create one .mc file per palette, together with a jungle file mapping the sets of devices to the appropriate .mc file.

hello,

I re-open this thread !

I am trying to update 

jq-win64 --slurp 'map({ key:.deviceId, value:{ deviceGroup, deviceFamily, partNumbers, displayType, displayName, bitsPerPixel } }) | from_entries' test0.txt >test1.txt

to add connectIQVersion information and get something like:

{
"approachs60": {
"deviceGroup": "Watches/Wearables",
"deviceFamily": "round-240x240",
"displayName": "Approach® S60",

"connectIQVersion": "2.4.1",
},
"approachs62": {
"deviceGroup": "Watches/Wearables",
"deviceFamily": "round-260x260",
"displayName": "Approach® S62",

"connectIQVersion": "3.0.12"
}
}

But I do not know how to modify query to extract connectIQVersion from "partNumbers"

Any help ?

Thanks

prenard59115 said:

But I do not know how to modify query to extract connectIQVersion from "partNumbers"

This should do it:

jq-win64 --slurp 'map({ key:.deviceId, value:{ deviceGroup, deviceFamily, ciqVersions:.partNumbers|map(.connectIQVersion), displayType, displayName, bitsPerPixel } }) | from_entries'

Note that each part number has a version, so any given device can have multiple ciq versions, so this returns a ciqVersions array with all of them.

I'm not entirely sure how to interpret the multiple numbers, but I assume it means that if your app is running on that device, the version will be somewhere between the min and the max. So if there's a feature that requires ciq3.2, and a device is listed as ciq2.4 and ciq3.2, I'll include the feature for that device, and check at runtime for availability. If the max supported version is 2.4, I'll just drop the feature on that device, and if the min version is 3.2, I'll include the feature, and not include the runtime checks.

If you only care about the max (or min) version, you could do:

jq-win64 --slurp 'map({ key:.deviceId, value:{ deviceGroup, deviceFamily, connectIQVersion:.partNumbers|map(.connectIQVersion)|max, displayType, displayName, bitsPerPixel } }) | from_entries'