Acknowledged
CIQQA-4196

API docs: nativeNum option missing for DataField.createField()

In the API docs, the nativeNum option is documented for ActivityRecording.Session.createField(), but not DataField.createField(), although I believe it's actually available for both functions. (Since I have an old CIQ data field which uses nativeNum, and this use case has been heavily discussed over the years.)

https://developer.garmin.com/connect-iq/api-docs/Toybox/ActivityRecording/Session.html#createField-instance_function

https://developer.garmin.com/connect-iq/api-docs/Toybox/WatchUi/DataField.html#createField-instance_function

  • It does do something.

    It allows CIQ device apps / data fields to override native fields in 3rd-party apps / sites like Strava.

    Yes it's well known that Connect will ignore nativeNum, but the same cannot be said of all 3rd party sites.

    There's years of discussion on the forums about this. I've written apps that take advantage of this, and obviously Stryd is the most prominent example of this use case. (Strava will use Stryd power if you disable the recording of native power. You should know this very well, since I've mentioned this a million times in threads that you have either started or have been a part of.)

    Go ahead and look at the FIT files that are created when you use the Stryd data field on a run.

    Note what I wrote in the bug report:

    "(Since I have an old CIQ data field which uses nativeNum, and this use case has been heavily discussed over the years.)"

    You think that devs use nativeNum for absolutely no reason? 

  • You're probably right and Garmin should fix the docs.

    However I don't think that there was ever a CIQ developer who was able to use nativeNum. Or to phrase it other way: I don't think anything, including Garmin Connect uses the nativeNum. I wouldn't be surprised if it doesn't even do anything (though you could check it in fitfileviewer.com, maybe you'll see something is different when you create a field with and without nativeNum.