Support for sports and sub-sports

OK, I voted on your thread.

OK, I voted on your thread.

flocsy🤠 said:

because Garmin only needs to add them to the documentation.

Wrong. That was already discussed above and in one of the related bug reports.

flocsy🤠 said:

I mean, not sure where the constants reside for the has check... Maybe that's in the firmware? Or is it something they only need to add to the SDK?

Again, as previously discussed at length, enums need to be added in the firmware as well as the SDK.

When optimization is disabled, code such as Activity.SUB_SPORT_JUGGLING is resolved at run time, by looking up the SUB_SPORT_JUGGLING symbol in the Activity module.

- The enum needs to be added to the SDK because the code won't compile unless the symbol exists at compile time (in this fake example, SUB_SPORT_JUGGLING). (And ofc the enum itself has to exist, as well)

- The enum also needs to be added to the firmware so the actual value can be resolved, when optimization is disabled.

You can verify this for yourself by looking at the .mir files that are generated for an app that uses enums, with optimization disabled. It's not the actual byte code that runs on the device, it's an intermediate representation, but I think it does give you a good idea of what actually happens at run time.

Yes, but the question what does this really mean: "resolved run time". We're probably (!??) talking about symbols that are already present in the firmware in at least some devices. Not sure if it's in a place that is accessible by the CIQ code.

As CIQ has no way to include the extra weight for calculations done in the firmware, like calories burned, it doesn't make much sense to use that in a CIQ app.  While the app can generate user data for the extra weight, it's not used outside of that specific app - you can't replace the data generated by the FW.

flocsy🤠 said:

but the question what does this really mean: "resolved run time".

I think I already answered that:

by looking up the SUB_SPORT_JUGGLING symbol in the Activity module.

But maybe we need to talk about what CIQ symbols actually are.

The Activity module is CIQ-accessible code in the firmware, right?

The symbol in question (e.g. SUB_SPORT_JUGGLING) has to exist in CIQ and be accessible by CIQ. CIQ code can't access stuff outside of CIQ, at least not for normal devs, right?

Every identifier in CIQ is a symbol (which is an integer identifier under the covers). When you access a symbol that's part of the CIQ API, the compiler uses a predefined ID which can be seen in [device id].api.debug.xml. When you create a new symbol in your code (e.g. by naming a function or non-local variable with a name that the SDK doesn't use), the compiler picks a value which is unique (at least within your app).

Note that these are CIQ symbols, and it's very unlikely that they correspond to any kind of IDs in the firmware. (After all, the firmware is supposedly C/C++).

Consider the CIQ enum Activity.SPORT_GENERIC, which has a value of 0.

Activity is a symbol whose value is 8388631 and SPORT_GENERIC is a symbol whose value is 8388830. (I looked them up in the SDK.) It's unlikely that any code in the firmware outside of CIQ code would be able to look up SPORT_GENERIC (8388830) in the Activity module (8388631) to obtain the enum value of 0. The non-CIQ C/C++ code probably just has a literal 0 wherever SPORT_GENERIC is used (because again, it's reportedly just compiled C/C++ code.)

If you're thinking that perhaps there are "private" (or undocumented) symbols that may exist in Connect IQ that we don't know about, that's possible, but then refer to this statement:

The enum needs to be added to the SDK because the code won't compile unless the symbol exists at compile time (in this fake example, SUB_SPORT_JUGGLING). (And ofc the enum itself has to exist, as well)

Meaning that in *general* (not just talking about simple enums) it wouldn't help to know that private symbols exist, unless you had a special version of the SDK that supported them (or if you could guess / reverse engineer their integer IDs.)

For example, clearly the Connect IQ store on-device app is both a Connect IQ app and has access to a private part of the API that ordinary devs can't use. (The internal CIQ team probably has a special SDK)

Ofc, if we're just talking about enums, there's no need to guess at symbol IDs, you would just guess (or determine) the enum value itself, as you have done.

Not sure if it's in a place that is accessible by the CIQ code.

Right, this goes back to how you can just guess (or determine) the integer values you want to use for sport and subsport, even if if they're not supported by CIQ. That doesn't mean Garmin can just add those values to the documentation and the SDK, and call it a day. If those CIQ symbols don't exist in the firmware, they need to be added to the firmware.

flocsy🤠 said:

We're probably (!??) talking about symbols that are already present in the firmware in at least some devices. Not sure if it's in a place that is accessible by the CIQ code.

To circle back, with a couple of exceptions, it doesn't make sense (to me) to say that "[CIQ] symbols" are already present in firmware but not accessible by CIQ code, because the native code almost certainly doesn't use those symbols. 

The only exceptions I can think of would be:

1) private symbols (e.g. to support super-powered Garmin apps like the Connect IQ on-device store, which can do things that no ordinary dev can do).

or

2) symbols which have been "added in advance". e.g. yeah, maybe all the CIQ enums (and corresponding symbols) for the missing sports were added years ago to the firmware, but for some reason, the SDK/documentation was never updated

Idk about you, but 2) seems very unlikely to me. Why would the CIQ team go to all the trouble of adding CIQ enums/symbols in advance and not ALSO add the same enums/symbols to the SDK and documentation?

Finally, ask yourself this question:

Has Garmin ever retroactively unveiled Connect IQ functionality to a device? Have we ever gotten a new CIQ feature (which unambiguously requires code to be present on the device) which was unlocked by simply compiling with a new SDK? No, new features in the SDK are always tied a new CIQ API level, and that also requires a firmware update.

So why would they start now? Even if the CIQ enums were hiding out on existing devices for years (which I find highly unlikely), if and when Garmin puts them in the SDK, they are going to tie them to a new API level.

You've never seen a new function added to an old API level, right?

So why would you expect a new enum to be added to an old API level?

Your argument might hold water if the "non-CIQ" / native part of firmware was also implemented in CIQ (what a nightmare that would be).

FlowState said:

Note that these are CIQ symbols, and it's very unlikely that they correspond to any kind of IDs in the firmware. (After all, the firmware is supposedly C/C++).

I can't edit my previous comment, so I'll clarify here. I meant to type:

Note that these are CIQ symbols, and it's very unlikely that they correspond to any kind of IDs in the native / non-CIQ part of the firmware. (After all, the native part of the firmware is supposedly C/C++).

Another edit:

FlowState said:

Every identifier in CIQ is a symbol (which is an integer identifier under the covers). When you access a symbol that's part of the CIQ API, the compiler uses a predefined ID which can be seen in [device id].api.debug.xml. When you create a new symbol in your code (e.g. by naming a function or non-local variable with a name that the SDK doesn't use), the compiler picks a value which is unique (at least within your app).

Every identifier in CIQ is a symbol (which is an integer identifier under the covers). When you access a symbol that's part of the CIQ API, the compiler resolves it to a predefined integer ID which can be seen in [device id].api.debug.xml. When you create a new symbol in your code (e.g. by naming a function or non-local variable with a name that the SDK doesn't use), the compiler generates an integer ID which is unique (at least within your app).

jim_m_58 said:

As CIQ has no way to include the extra weight for calculations done in the firmware, like calories burned, it doesn't make much sense to use that in a CIQ app. 

That exact point was already made above.

The general question - aside from rucking - is why CIQ doesn't have support for the newer sports and subsports on current devices.

My guess is that they just didn't have time to add all of them.

TL;DR it's pretty likely that CIQ symbols are only used by CIQ (and not native non-CIQ code), so there would be no reason for the missing CIQ enums/symbols to already exist in firmware for months or years before being added to the SDK/documentation.

Furthermore, Garmin has never retroactively "unlocked" CIQ features in older firmware by releasing a new SDK, so I doubt they would start now. I have never seen a new function or enum added to an existing API level. (Think about what a nightmare this would be - you'd have functionality that's in an old API level but which nonetheless requires a newer SDK)

Speculating that Garmin could simply just update the SDK or even just the documentation to add new sports really sounds like wishful thinking to me.

Yeah, technically they could just update the docs to say "if you want rucking, use a hardcoded integer value of X and make sure you only do this for the following devices: ..." but we all know that would never happen.