Undocumented differences between watches that materially affect what I build and what I advise about things I've built...

If you want to get a good understanding of different devices, a really good source is the garmin forums for specific devices.  For example, if I've seen one post about the limit on the number of CIQ DFs on a device, I've seen hundreds.

Then there things like which devices even support power meters - again, you don't need the device to find that out.  Same with running dynamics.

Some of that you can see is based on if it's a "heath and wellness" device, a low end forerunner, a high end forerunner, Fenix, low end edge, high end Edge, etc.

When it comes to specific things on watches, plan for differences - and what I often use is "has".

You can also understand the difference with CIQ1, CIQ2, CIQ3 devices.  Pay attention to "since:" in the api doc.

Things were easier when there were only 4 CIQ devices, where today I've lost count.  If you're new to CIQ, there's actually a whole bunch of the info you're looking for in this forum.  It might not be in one place, but I've found doing a search here can be helpful.

But why not in a document somewhere?

This is all, surely, essential information that should be accessible to developers. 

And I don’t mean the nitty-gritty of coping with difference- I can and have worked that out for myself. 

The issue is _knowing_ that there _is_ a difference to allow for. 

It’s all very well saying search the device forums but there are at least 60 devices that I _currently_ support for _most_ if not all of my DF. Every single issue I cited in the OP (and I’m certain there are more) could not have been anticipated based on developer information and searching retrospectively across the entirety of the Garmin community worldwide to find stuff that I should have known is not even feasible, far less workable. 

This is really basic technical information amounting to a few configuration parameters that need to go into a spreadsheet somewhere and to be shared with us, your development community who work to enhance Garmin products for the benefit of Garmin. 

It doesn’t seem like a big ask to make that information available but it is a HUGE AND UNWORKABLE ask to get us to somehow intuit for ourselves. 

Not least because all three of the examples I cited are cases where the received forum wisdom either contradicts or clashes with practical observations of live, functioning, bug-free DF behaviour. 

Some of it is CIQ has a learning curve that can be fairly steep at the beginning, especially when it comes to devices you don't have.  But many of the questions become clear after not too great a time.  You start seeing how different families of devices work, and things become much clearer.

There is an O'Reily book about CIQ (you used to be able to get it as a PDF), but it was CIQ 1

Maintaining a doc like this could be a fairly large task, and would get outdated every time a new device is announced. And yes, some info gets outdated.

Out of your 3 points, #1 as I said is very well known.  #2, I recall saying I think it's 16,not 14, but wasn't sure.  And for #3, I would trust Travis' view without a doubt.  He's someone that knows all the devices, and can point to at ways to do things that will work on them all.

CIQ is very complex (MUCH more so than it was in 2015) and I really can't see a magic document that would give you everything over night.  Best advice, start simple.

Over the last few years, I've completely re-written some of my apps from when I only had a vivoactive, and later learned better ways to do things.

The last 3 CIQ developer summits, those that attended got one of the latest CIQ devices.  Things like that also help.  Or even just finding someone that has a device you don't who can run some basic tests for you.

All of that is valid, but...

I am still talking about a very small number of configuration values that are by definition in the Garmin codebase that is only accessible by Garmin that could be included in, for example, devices.xml as an automated scripted inclusion that needs no maintenance.

So...

I am really not asking for the impossible here.

I am asking for easily found (by Garmin) values that are well known and programmatically exact and incontrovertible (to Garmin) that can readily be extracted by script (by Garmin) to be made public as a small inclusion to the technical specification of the device that absolutely must be known and maintained internally (by Garmin) as a matter of routine to prevent development mishaps.

I am not, for example, asking you to reinvent the wheel or pull elephants out of an orange. 

jim_m_58 said:

Another think to keep in mind, is CIQ has a simulator.  It's not an emulator and doesn't show everything on the device, like the # of CIQ DFs.  Things like that are up to the platform/devices groups and not the CIQ group.

I think that this is pretty much my entire point.

It is a simulator and not an emulator and so there is absolutely no way at all, whatsoever, anywhere without actually owning the device to know the value of a simple integer that is hardcoded into Garmin code by a Garmin developer who I will likely never meet and wouldn't realise even if I did.

I'm really not questioning any of your observations about the reality of programming CIQ content.

What I am questioning is the completeness of the documentation with information that only Garmin is able to provide and that Garmin could provide very easily.

jim_m_58 said:

the compatible device matrix on the developer site.

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

(notice the blue circle with the "i" for each device)

Meh.

That is less complete and less searchable than the Excel I was able to derive from devices.xml.

As a programming resource it, frankly, sucks.

Actually not, if you are looking for more than the basics, as you'll see things like what devices support things like BLE.

Did you click on a few of the blue circles?

Yes, I clicked on them. No, I did not find them enlightening.

Quite apart from them being:

9635560 said:

less searchable than the Excel I was able to derive from devices.xml

with the emphasis on searchable (I have better things to do than a human-error prone manual click, read, document over 60+ blue circles of inconsistent text), they are largely marketing style information when I am looking for cold facts.

Anyway, it's clear neither one of us will convince the other today, so I'll call it a day.

Have a good weekend wherever you are, I intend to have a good one where I am!

Cheers,

9635560 said:

In another thread, Travis asserts coding behaviour for RunningDynamics that makes perfect sense, but again, doesn't match my 735xt. I have no way to know whether this is an anomaly of my 735xt (which is becoming increasingly likely) or is a change in the underlying code to make it work,

This is not an issue with your fr735xt. It is an issue with the language that it allows you to write such code. It should be prohibited.