Acknowledged
1 month ago

Given that a newer SDK is required to build for CIQ 5.x devices, what does this mean for existing apps on devices that were upgraded from CIQ 4 to CIQ 5 (e.g. FR955, Fenix 7, etc)? Do these apps just break?

Background:

- it has always by my understanding that if you build an app for a device with a given SDK, then that app should continue to work regardless of future firmware updates (in general). This ofc excludes situations where:

  - the new firmware update has a bug or breaking change

  - the existing app has a dormant bug which is exposed by a legit change in new firmware. e.g. newer firmware has a change where Weather.CurrentConditions.observationLocationName is null, and this caused several existing watchfaces to crash because they assume that field will never be null. But that's an application error, since that field has always been typed to be possibly null

- CIQ 5.* devices require various 7.X (or 8.X) SDKs to run properly

- Compilers have a check to ensure you don't try to build a a too-new device with a too-old device

- Due to a bug in this check, where older compilers (pre 7.2.0) seem to incorrectly believe that SDK version X can build any device with CIQ version X (or lower), it's possible for an SDK 6.X compiler to build an app for CIQ 5 devices. However, it's very possible that such an app will crash when it's run in the simulator or the device (we've already seen "bug reports" about this

- The existing crop of devices that came out with CIQ 4 (e.g. fr955, fr965, fenix7) have all been updated to CIQ 5. As far as I know, this is the first time that existing devices have received a major CIQ update since the move from CIQ 1 to CIQ 2.

- Someone in the CIQ team already clarified that CIQ 5 devices require apps to be built with newer SDKs.

So here's what I don't understand.

The two following statements seem to be mutually exclusive:

- If an app is built for a device with an existing SDK (e.g. SDK 6.4.0) it will continue (in general) to work on the device for all future firmware updates

- Devices with CIQ 5.* require a 7.X or 8.X SDK

The problem is that it was entirely possible to build an app for an fr955 (for example) with SDK 6.4.0 in the past, when fr955 was only on CIQ 4. If I installed such an app on my fr955 when it had CIQ 4, it would expect it to continue to work now that my device is on CIQ 5.

So how can it be possible that going forward, a 7.X or 8.X SDK is required to build for my fr955?

What am I missing? Has something also changed with the device files that's relevant here?

FlowState
Parents
  • 1 month ago

    thanks for the response!

    "As device configs are updated to newer CIQ versions (say going from 5.1 to 5.2) a newer SDK will needed to be used that supports that version)."

    Yes but what does this imply about an app that was built and installed a device (e.g. fr955) that was on an older API level (e.g CIQ 4.x) using an older SDK (e.g. SDK 6.4).

    Once the fr955 in question is updated to CIQ 5.x, will an existing app installed on the device that was built for an older API with an older SDK cease to work?

    If so, this seems like a serious problem, as it would imply that *in general*, CIQ apps will stop working once the device firmware is updated, and devs are required to constantly update their apps to "keep up" with new firmware. Indeed, this is actually the impression that many (non-dev) forum members have, and it has also been stated (in different words) by (non-CIQ) Garmin support employees, in the forums.

    If not, then why shouldn't it be possible to build an app for a device with a newer CIQ API (e.g. 5.x) with an SDK that only supports older APIs (e.g. 4.x)? Obviously there's no question of using any of the newer features that are unavailable in the old API.

    My observations:

    - I haven't seen any mass reports of apps that suddenly stopped working with recent firmware updates to devices that were initially released with CIQ 4, but now have CIQ 5. The closest thing to that I've seen is several reports of watchfaces breaking because Weather.CurrentConditions.observationLocationName is now returned as null by device. But this is an exception to the rule, not the general case, and it actually points to a coding error (and not backwards incompatibility wrt to the firmware/SDK) since observationLocationName was always typed to be possibly null

    - However, I have seen dev reports of problems when (incorrectly) building an app with SDK 6.4.0 (for example), but running it on a CIQ 5 device (whether it's a real device or in the simulator). Note that this is only possible because of a bug in all SDKs prior to SDK 7.2.0 where the compiler would incorrectly assume that if the current SDK is version X, it should be able to build for all CIQ APIs <= X. (This was a correct assumption before "system levels" were invented.)

    I think some of the problems including the app crashing in the sim (due to a version check) or the app crashing due to generated resource code that doesn't work with CIQ 5

    So I'm still not able to reconcile these two possible alternatives: either new device firmware is backwards compatible with apps built with old SDKs, or it is not.

Comment
  • 1 month ago

    thanks for the response!

    "As device configs are updated to newer CIQ versions (say going from 5.1 to 5.2) a newer SDK will needed to be used that supports that version)."

    Yes but what does this imply about an app that was built and installed a device (e.g. fr955) that was on an older API level (e.g CIQ 4.x) using an older SDK (e.g. SDK 6.4).

    Once the fr955 in question is updated to CIQ 5.x, will an existing app installed on the device that was built for an older API with an older SDK cease to work?

    If so, this seems like a serious problem, as it would imply that *in general*, CIQ apps will stop working once the device firmware is updated, and devs are required to constantly update their apps to "keep up" with new firmware. Indeed, this is actually the impression that many (non-dev) forum members have, and it has also been stated (in different words) by (non-CIQ) Garmin support employees, in the forums.

    If not, then why shouldn't it be possible to build an app for a device with a newer CIQ API (e.g. 5.x) with an SDK that only supports older APIs (e.g. 4.x)? Obviously there's no question of using any of the newer features that are unavailable in the old API.

    My observations:

    - I haven't seen any mass reports of apps that suddenly stopped working with recent firmware updates to devices that were initially released with CIQ 4, but now have CIQ 5. The closest thing to that I've seen is several reports of watchfaces breaking because Weather.CurrentConditions.observationLocationName is now returned as null by device. But this is an exception to the rule, not the general case, and it actually points to a coding error (and not backwards incompatibility wrt to the firmware/SDK) since observationLocationName was always typed to be possibly null

    - However, I have seen dev reports of problems when (incorrectly) building an app with SDK 6.4.0 (for example), but running it on a CIQ 5 device (whether it's a real device or in the simulator). Note that this is only possible because of a bug in all SDKs prior to SDK 7.2.0 where the compiler would incorrectly assume that if the current SDK is version X, it should be able to build for all CIQ APIs <= X. (This was a correct assumption before "system levels" were invented.)

    I think some of the problems including the app crashing in the sim (due to a version check) or the app crashing due to generated resource code that doesn't work with CIQ 5

    So I'm still not able to reconcile these two possible alternatives: either new device firmware is backwards compatible with apps built with old SDKs, or it is not.

Children
  • 1 month ago in reply to FlowState

    Old PRGs will continue to run on devices with updated firmware and CIQ versions because there was no way those PRGs could have been compiled with knowledge of newer APIs. I don't believe it is strictly impossible to devise a system that allows you to build with older SDKs minus the support of new APIs, but historically that is not how it has been done. Personally I think it would make things more confusing to understand what device supports what if that were the case rather than keeping device configs up to date and using the latest SDK. On the rare occasion there are backwards compatibility breaking changes so it is best to avoid this potential complication.