In case it is useful to anybody else: searchable device database for SDK 3.18

Much of this varies by experience.  When you get a handle on devices and similar devices, things become clear.  There's a ton of things, like on which devices do Number fonts have white space padding, that it's easier to just have a simple app that shows you what's up.Things like widget timeouts aren't defined anywhere.  Not only what the timeout is, but if there even is one.  Things you'll ever find in the sim, but is based on experience.

Using the va4 and fenix 6 as examples, they "look" to be the same when it comes to many things in the speard sheet if you're just doing a DF, WF, etc, but, when it comes to devices, something that makes them incompatible is fonts. if you have a WF that uses native fonts on the va4, and just add the f6, it might not look that great. 

Ok Jim, here are two of my recent use cases where your old-man-of-the-sea approach simply doesn’t cut it:

1. “Find all devices that actually support power in datafields in order to build a power dial”

2. “Find all devices that actually support running dynamics in order to build a running dynamics specific dial”

In both cases, I tried (because there was nothing else) using the documentation available. In both cases reasonable intuition failed. In both cases there were single product exceptions that (still) surprise.

But the thing is...

In both cases if I had had, say, a simple table with a column of data showing capabilities per device - or the JSON field “advancedFeatures” from the EXISTING BUT HIDDEN JSON feed for compatible devices - it is a thirty second task to search for and list accurately, without exception, ALL OF THEM.

Believe me, this has nothing to do with the niceties of per device design peccadilloes. It is simply that I want to be able to build for specific features so I need to know what devices I can build on.

Beauty is only part of it.  I'd call it usability!

For a number of the things you mention, they can be pretty obvious by just a simple run in the sim, and there's some, where coding an app correctly, simply don't really matter. ("has" is your friend!) Other's a simple check in the API guide until you get more familiar with things.

take for example onPartialUpdate.  Not only is it easy to check, but can also change based on exceeding the power budget, so in coding a WF, you want to handle both cases.  Meaning it can run on any device.

Same with backgrounding.  If the device supports it, use it, if not maybe look at doing something else, like running things in the foreground in the case of a widget.  It's "since 2.3.0" so easy to see in the API doc.

Glance support is similar - if the device has it (and it's enabled), you'll have glances.  If not, the widget still runs fine

(for these 3 examples, I have apps that use those features that run on CIQ1 devices, but don't use those features)

for #3, that to me sounds like a bug, and possibly based on the specific FW.

With the deepest respect, Jim, you are missing the point.

You are talking about "avoiding a crash" and I am talking about "building something for a specific purpose".

To wit...

jim_m_58 said:

For a number of the things you mention, they can be pretty obvious by just a simple run in the sim, and there's some, where coding an app correctly, simply don't really matter. ("has" is your friend!) Other's a simple check in the API guide until you get more familiar with things.

1. For "Power Dial", I have 34 separate devices checked in the manifest. However, there are 60 out of 72 potential targets (because I am excluding CIQ1 for Power Dial). I only now know that there are 34 compatible devices because I was able to search using the capabilities. Otherwise, I would need to explicitly and manually run a test on all 72.

And no. this doesn't help...

jim_m_58 said:

where coding an app correctly, simply don't really matter. ("has" is your friend!)

Because...

2. It is coded correctly using "has" so ABSOLUTELY NO ERRORS WILL BE SEEN OR TRIGGERED BY RUNNING ON A DEVICE THAT DOESN'T SUPPORT power in the field... My field will run perfectly correctly, it will just show zero... 

And most importantly, the reason any of this matters...

3. If I release "Power Dial" for devices that have power through some Garmin back door but do not have power in the DataField (such as the FR245 support email I got) then I will look bad for breaking something that they think is working when in reality I should simply never have included that release target.

Tl;dr;

All of your posts seem to be about workarounds, damage limitation and "a feel for the product range". Which is all well and good, but is not only irrelevant but also counter-productive when I am trying to build a working product for all the devices that support what I am building.

In order to build for a feature, I need to know which products have that feature.

Using "has" is damage limitation AFTER THE FACT for when something has either gone wrong or the value is not initialised. 

jim_m_58 said:

for #3, that to me sounds like a bug, and possibly based on the specific FW.

I'm assuming that you are talking about this:

9635560 said:

3. The fact that power is available on Forerunner series as far back as CIQ1 but not on FR6?? or anything below

If so, please do your own checks here: https://developer.garmin.com/connect-iq/compatible-devices/

But I can confirm that the JSON that populates that does not include "hasPowerSupport" for FR645 or quite a few others.

In fact, by using the "filter" on my Excel spreadsheet, I can tell you precisely that the list with "hasPowerSupport" is:

D2 Bravo
D2 Bravo Titanium
D2 Charlie
D2 Delta
D2 Delta PX
D2 Delta S
Descent Mk1
Edge® 1000 / Explore
Edge® 1030
Edge® 1030, Bontrager
Edge® 130
Edge® 520
Edge® 520 Plus
Edge® 530
Edge® 820 / Explore
Edge® 830
epix
fēnix® 3 / tactix® Bravo / quatix® 3
fēnix® 3 HR
fēnix® 5 / quatix® 5
fēnix® 5 Plus
fēnix® 5S
fēnix® 5S Plus
fēnix® 5X / tactix® Charlie
fēnix® 5X Plus
fēnix® 6
fēnix® 6 Pro / 6 Sapphire / quatix® 6
fēnix® 6S
fēnix® 6S Pro / 6S Sapphire
fēnix® 6X Pro / 6X Sapphire / 6X Pro Solar / tactix® Delta Sapphire / quatix® 6X
fēnix® Chronos
Forerunner® 735xt
Forerunner® 920XT
Forerunner® 935
Forerunner® 945
MARQ Adventurer
MARQ Athlete
MARQ Aviator
MARQ Captain
MARQ Commander
MARQ Driver
MARQ Expedition

Enjoy looking all of those up on the "compatibility" page.

I see all the f6 devices on that list. Are you saying it's not on the real device or not in the sim?  Again, that sounds like a bug or something missing in the doc.  It wouldn't make sense for the f6 devices not to have it.

The 645 doesn't surprise me.  It's not available on other lower end devices, like the vivoactives/venus.  That's where just understanding what things may differ between va/fr/fenix devices in general helps.

Oh..  ok, "fr6" confused me and you didn't mean f6, as there is the fr620, fr630, fr645.

If you support 34 devices, you really want to run each one in the sim.  I test every target in the sim for each of my apps.  You avoid a bunch of surprises.  You can eliminate a few if you understand they are the same as another one (the "legacy" devices and the va4/va4s for example)

Quite. I didn't consider, mention or mean Fenix.

jim_m_58 said:

The 645 doesn't surprise me. 

You said yourself you built a project to read all of this information back in 2005... that's fifteen years of familiarity. If it surprised you, I'd be disappointed.

However...

While your product knowledge is doubtless encyclopaedic, there is absolutely no reason why it should have to surprise anyone if there was a decent search. (Which, outside of my Excel, there is not.)