Page Indications? SDK 4.2.0

DaveBrillhart over 2 years ago

I see in the README that 4.2.0 includes something called Page Indications.

Does this mean my CIQ data field will be informed about which screen (page) is currently active?

Top Replies

AlphaMonkeyC over 2 years ago in reply to FlowState +1

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…

All Replies

0 AlphaMonkeyC over 2 years ago in reply to FlowState

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.

0 FlowState over 2 years ago in reply to AlphaMonkeyC

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.

0 peterdedecker over 2 years ago in reply to FlowState

FlowState said:
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.

I think this depends a lot on how user friendly you want your app to behave.(In my humble opinion I don't think it's very user friendly to force people to update their firmware to update/download an app)

In many cases apps do not have to depend on having to have all the latest features available and you could gracefully disable functionality in your app with has and/or jungles

(Side-thoughts "I don't think it's very user friendly to force people to update their firmware to update an app". This might not be a very valid point as users are often forced to update firmware anyway if you move to a new device definition (there has been a time I hand-modified the sdk/dev defintions to be able to let it run on older firmware, I stopped doing it because it was too much maintenance overhead) )

FlowState said:
I think System Level and features would be a good start and would make lots of devs happy.

I concur, but I think you should also have it reflected in the docs, which might be a lot of work to update it everywhere (unless you handle it with a mapping page, clicking on a api level brings you to a page telling you what system level is equaling which api levels).

Selecting compatible devices in vs code based on feature would be great way to start your new project. For a matured project being able to select all devices in the product reference guide (https://developer.garmin.com/connect-iq/reference-guides/devices-reference/#devicereference) which have a certain feature would probably be more useful. But the combobox selection list with features could become very very long, it could easily become a jungle as well....