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.

jim_m_58 said:

if you have a WF that uses native fonts on the va4, and just add the f6, it might not look that great. 

Aesthetic decisions are very much in the eye of the beholder, Jim, but they are also secondary to whether or not you can build something that actually works in the first place.

If you want me to state outright in bold text that my spreadsheet does nothing for the inherent beauty of your creations, then absolutely, I state here and now in bold text that my spreadsheet does nothing for the inherent beauty of anybody's creations.

But that is really not the point!

The point is, was and remains; if I or anybody else wants to know the basic functionality exceptions that they need to allow for, such as:

1. The fact that only two devices have 8 colours in their palette (and which two devices)

2. The fact that only one device is monochrome (and which device that is)

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

4. The fact that power is available on every Edge device except for one and which device that is...

5. Which is the only CIQ3 device that doesn't support Cryptography?

6. Which is the only CIQ2 device that does support Cryptography? (Although, I admit that's a bit futile as the SDK won't let you use it AFAIK.)

7. Do all CIQ2 devices support background processing?

ALL of those facts are things that should be a few seconds work to find out and would be if Garmin made their existing, essential and well maintained data more searchable and available.

The spreadsheet is an attempt to fill that needless, pointless and futile hole in Garmin documentation.

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