Page Indications? SDK 4.2.0

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.

AlphaMonkeyC said:

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. 

Thanks for the response! I was thinking more along of the lines of wanting to exclude 4.x devices which haven't received the proper firmware update yet, for whatever reason. (e.g. Because auto updates are turned off, because they haven't synced in a while or because they have an APAC model. I understand that for some newer watches at least, APAC and ROW actually run the same firmware, but I haven't looked into whether this is the case for all 4.x watches)

Like today if you set min API to 3.3, but someone has a 3.3-capable device which is still on 3.2, I think they will be blocked from downloading the app but they'll also see a message telling them to update their firmware. It would be nice to see something like that for a device that supports System X but doesn't have it yet, when they try to download an app which requires System X.

AlphaMonkeyC said:

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.

That's a tough question haha. I'd have to think about it. I think System Level and features would be a good start and would make lots of devs happy. Like if they have some app which revolves around weather, it would be great if users with devices which can't support weather never see it, and users with devices which can support weather but haven't been updated yet are asked to update their firmware.

The current minimum API level restriction isn't bad, but it just seems a bit limited. You'll see people in the forums suggesting never to use any minimum API level higher than 1.2 or 1.4-ish, since it isn't worth it.