PSA: 10.xx Beta firmware CIQ Position bug

jim_m_58 said:

It could also be that only devices with 4.2.0 are "System 6".  Maybe just ignore the :"system X" and go buy the min API level for something

Not sure how that helps when the docs say stuff like "Since API level 3.3" when they mean 3.3 for CIQ 3 and 4.1 for CIQ 4.

So how do we interpret "since API level 3.3.6"? For a CIQ 4 device, which CIQ API level does it need to have in its firmware? If you say 4.1.6, you just proved my point. Or if you say "we don't know if it's 4.1.6 or 4.2.0", you proved my point even better.

Obviously the point isn't that any of us cares about names like "System 4/5/6" per se, we just want to know what CIQ version is required on the device for a given feature. Simple as that. "System 6" or "since 3.4.0" is a shorthand for that information, but my whole argument was that Garmin should spell it out explicitly, because we can't even agree what "System 6" means.

Again I will point out the case of the dev in the other thread who asked why their 4.x device doesn't have 3.3.6 features. Not sure how telling them "look at the min API version" (in docs) will help with that kind of problem. What needs to happen is the docs need to say something like "Since 3.3.6 for CIQ 3 devices and since X for CIQ 4 devices" (whether X is 4.1.6, 4.2.0 or something else.)

flocsy said:

I think that this whole thread misses the point. As a developer it doesn't really matter to ME whether the fenix6 FAMILY is capable of a System5 feature that I use in my app (and even less about giving a name like System X to a set of features). What I care is:

1. What's the minimum (earliest / least advanced / smallest number...) CIQ my app can be installed to when it's installed to fenix6?

flocsy said:

2. When I develop an app that needs some feature (for example body battery) then I want to be able to decide what is better for my potential users: should I release it for minSdkVersion 3.0.0 and hide the feature with "has" but have confusing settings like: "Body Battery (only for devices that support it)"? Or do I want this feature to appear on watches that for sure (even the oldest factory batch) has the minimum CIQ version that is needed? These decisions should be based on knowledge that I should be able to find in the official documentation from Garmin. Here having some marketing buzzword like System X might help, but again, it's not the point. It could be an easy way to communicate the information. But it isn't for now, and probably never will, so I personally care less about the name.

Yeah, I agree with this 100%. It's what I've been trying to say (and what I've said elsewhere), but the goalposts keep getting moved.

- "3.3.6 is System 6 and if you don't believe that, you're confused"

- "Maybe only 4.2.0 is System 6"

- "Maybe just look at the min API level" (too bad that still doesn't answer our questions, like what firmware do I need on a CIQ 4 device for this new feature which is marked "since 3.3.6")

As I said above, I also don't care about the marketing label "System 4/5/6" per se, except to the extent that it's completely failed at its purpose of communicating how the two CIQ version tracks (for CIQ 3 and CIQ 4) correlate with each other. When CIQ 5 comes out, this problem will be even worse.

And the suggestion to "look at min API level" doesn't work either. Because neither of those communicates clearly, or as we've seen in this thread, with certainty, the minimum CIQ firmware for some feature that I'm interested in, for all devices, not just CIQ 3 devices.

The only reason we debate what "System 6" means is because we want to know which firmware versions are required for a given feature, whether it's labelled "System 6", "since 3.3.6" or "since 3.4.0".

When someone says "3.3.6 is System 6" in the context of "Feature X (available since 3.3.6)", the implication is that X will be available in 4.2.0, for CIQ 4 devices. That's what I'm pushing back against, not the actual label "System 6". As a matter of fact, I believe that this 3.3.6 feature will be available in 4.1.6, for CIQ 4 devices, but it's just an educated guess.

As I pointed out before, now it's not possible to use minApiLevel in manifest.xml to include something like System 5 devices (and only System 5 devices).

This means that if your app depends on a System 5 feature, you have no way of preventing *all* non-System 5 users from downloading it. You could have a user who has older firmware on a System 5-capable device. In the past we could have a set a minApiLevel to exclude features, but today we can't. Ofc the predictable answer to this will be to "use has".

My response would be:

- What if I want to save memory by avoiding extraneous code?

- What if I my app is focused on a System 5/6/7/8 feature, and I want ppl who don't have that System to either not see my app at all, or be prompted to update their firmware (whichever is applicable). It's a bad user experience to allow the user to download your app, then tell them this crucial feature is unavailable because reasons

There was another thread about this where AlphaMonkeyC actually responded and asked what devs would prefer instead of the current system. I'll see if I can dig it up. Of course, it wouldn't even be a question if nobody ever pushed back against the current system, otherwise known as "whining and complaining."

EDIT:

Here's the comment from AlphaMonkeyC:

https://forums.garmin.com/developer/connect-iq/f/discussion/311642/page-indications-sdk-4-2-0/1512415#1512415

AlphaMonkeyC said:

FlowState said:

1) e.g. For System 5-specific functions, the docs always say something like "Since: CIQ 3.3". While this is technically correct, it doesn't capture the fact that it's also "since CIQ 4.1 for 4.x devices".

That's fair. We've been more concerned about if something existed in 3.x versus 4.x more than the overlaps.

FlowState said:

2) For the same reason as in the previous point, it's impossible to use the minimum API level in the app manifest to include System 5 devices, and only System 5 devices, because you either end up including devices you don't want (e.g. 4.0) or you exclude devices you do want (e.g. 3.3)

Admittedly, the System level is something we made up to communicate "just because it's not the latest API doesn't mean it's not getting updates." By in large, all 4.x products have the latest 4.x APIs, so if you set your API level to 3.3 you should cover all System 5 products. 

FlowState said:

Same reasoning applies to System 6 and any feature System Xs. Seems like it will be even more of a problem if and when CIQ 5 is introduced, because then you could have System Y which applies to *three* separate firmware branches.

Likewise, when we release System 6, setting your min version to API level 3.4. Now once we have devices start falling off the 4.0 train things will get a lot messier, but that's something for another time.

My question would be: if we were moving away from straight API level, what would be your preferred way of selecting the products in the VS Code plugin?

• By System Level?
• By feature or capability? (Has the BLE API, etc)
• By heap size?
• Something else?

Not saying we're implementing any of those, but I am interested in the feedback.

I'll just leave this here, for emphasis:

forums.garmin.com/.../1512415

AlphaMonkeyC said:

Likewise, when we release System 6, setting your min version to API level 3.4.

If only I had watched the GDVC live tho -- all my confusion would've evaporated.

Again, it's not about being right or wrong, it's about having the humility to:

- admit that you could be mistaken

- be open to changing your mind when confronted with new facts or arguments

Going back to the important part: now that we have a feature which is available "since 3.3.6" for CIQ 3 devices, what does that mean for CIQ 4 devices? Obviously we can look at the pattern and guess that it will be available for CIQ 4.1.6 devices (which also tracks with the fact it's available in the 4.1.6 SDK), but we shouldn't have to do that. As this thread has proved, not everyone will make the same guess. And as the other thread showed, the general public doesn't understand why a device with CIQ 4 doesn't have a 3.3.6 feature.

Looks like I was wrong.  You happy now?

Doesn't really make up for the heaping mountains of condescension - I couldn’t care less which one of us was actually right or wrong. I'm also guilty of being arrogant, condescending and dismissive at times, though, so I guess I can't complain too much.

My main point is that the "System X" scheme is obviously broken. All this discussion has proved it without a doubt.

you can't use api level in jungle towards to api level because it isn't connected with device/hardware, 2 users f6p can have 2 different firmware so also ciq/api level

of course solution is checking what api level is on device before installation of app and choosing correct file

but if user upgrade firmware he should upgrade also app

so API levels unfortunately can be checked only in runtime using HAS

There can also be differences if a device has WW and APAC versions where runtime makes things a bit easier.

I'm ignoring most of the previous conversation on this topic. It got a bit out of hand.

System 6 is ConnectIQ versions 3.4.0 and 4.2.0. In some cases, we push features in earlier than that. i.e., the Position.CONFIGURATION_* stuff was made available for API version 3.3.6.

It isn't ideal for us to do this, but we sometimes break our own rules.

Normally, the right thing to do here is to use has checks to determine if the device has support for a feature or not. I haven't looked at the actual bug reported in the OP, but if it is broken as described there, I don't see that the has check would have avoided this particular problem.

_psx_ said:

you can't use api level in jungle towards to api level because it isn't connected with device/hardware, 2 users f6p can have 2 different firmware so also ciq/api level

of course solution is checking what api level is on device before installation of app and choosing correct file

but if user upgrade firmware he should upgrade also app

so API levels unfortunately can be checked only in runtime using HAS

But that's only because the minApiLevel property in manifest.xml became useless as soon as Garmin started updating CIQ 3 and CIQ 4 devices in parallel. One minApiLevel doesn't work for both CIQ 3 and CIQ 4.

It becomes obvious when people ask "why doesn't my 4.1.0 device support this feature which is listed as 'since 3.3.6 in the docs'? Is something broken?" "minApiLevel = 3.3.6" works exactly like a human being interprets "since 3.3.6" in the docs: it just includes all firmware with a version number that's greater or equal to 3.3.6. Too bad that includes all the CIQ 4 firmware which is less than 4.1.6, which means that it includes CIQ 4 devices which lack a feature which is misleadingly labelled as "since 3.3.6".

What would be great is if we could specify multiple minApiLevels, corresponding to the current firmware tracks. e.g.

minApiLevelCiq3 = 3.3.6

minApiLevelCiq4 = 4.1.6

(Maybe there could still be a generic minApiLevel and/or one for devices lower than CIQ 3 and 4. The only problem with this suggestion is that it would be confusing. But then again, so is the whole System X scheme. And I don't just mean the naming scheme, I mean the fact that there's now two parallel version tracks which are actively developed: one for CIQ 3 and one for CIQ 4)

Or, as AlphaMonkeyC floated in his response above, it also be would nice to be able to gate applications by software/hardware features. As in Gavriel's example, maybe he only wants his app to be available for devices with body battery in CIQ. If they don't have that ability, either they never see the app or they're prompted for a firmware update (when applicable).

I think the very least Garmin could do is update the docs so that the "Since API level" information always describes the full picture for all devices. I assume the docs are machine-generated to some extent, so I would hope this wouldn't be an impossible ask.

For anyone who wants to say "but I am very smart and I can translate it in my head!!!1!", I will refer them to the last 5 pages of debate about whether System 6 is 3.3.6 or 3.4.0. There’s also the fact that even if seasoned devs know how to translate something like “since 3.4.0”, new devs won’t.

Again the "System 6" label itself doesn't matter, it's more about the implication that whatever features are defined as "System 6" are also tied to 4.2.0 (for CIQ 4 devices.) All of this debate was really about which of the following two possibilities was true:

- (System 6 = 3.3.6) "3.3.6 and 4.2.0 features are correlated"

- (System 6 = 3.4.0) "3.4.0 and 4.2.0 features are correlated" and "3.3.6 and 4.1.6 features are correlated"

Again if Garmin would just document this stuff, there would be no debate.