FitContributor :nativeNum functionality

Garmin Connect will not override the native fields with CIQ fields that use :nativeNum, but some third party applications are doing this.

There is also a device issue on some CIQ devices that is currently preventing them from writing out CIQ fields in the session message.

What is the issue you are experiencing? Is it possible one of these two things is the cause?

Garmin Connect will not override the native fields with CIQ fields that use :nativeNum, but some third party applications are doing this.

There is also a device issue on some CIQ devices that is currently preventing them from writing out CIQ fields in the session message.

What is the issue you are experiencing? Is it possible one of these two things is the cause?

It is the first issue of override native fields are being displayed in connect app/web.

If 3rd party sites are using the Garmin API, why isnt Garmin using its' own API override feature? If not, I guess the fundmential question is, why offer the override in the SDK if it is not going to be used?

It is the first issue of override native fields are being displayed in connect app/web.

If 3rd party sites are using the Garmin API, why isnt Garmin using its' own API override feature? If not, I guess the fundmential question is, why offer the override in the SDK if it is not going to be used?

I totally agree with you. I have the same issue. And my app gets lots of negative reviews becuase of this limitation.
This also adds an unnecessary complexity to the apps. For instance, my app supports meteic and imperial units. Therefore I need two different developer fields: one so that garmin connect users get to see the distance in the chosen units. And another one which uses nativeEnum so that smart sites such as sporttracks.mobi can override the native field.
To be honest, I don't get it. It is disappointing , every time I read this in an user review.

I totally agree with you. I have the same issue. And my app gets lots of negative reviews becuase of this limitation.
This also adds an unnecessary complexity to the apps. For instance, my app supports meteic and imperial units. Therefore I need two different developer fields: one so that garmin connect users get to see the distance in the chosen units. And another one which uses nativeEnum so that smart sites such as sporttracks.mobi can override the native field.
To be honest, I don't get it. It is disappointing , every time I read this in an user review.

I got around the metric/statute thing by putting the label as km/miles and posting as the watch is set for. The end user don't seem to mind.
I Agree, and I hope other developers post here to support.

I feel garmin doesn't want tainted data from rogue IQ apps. I agree with garmin, however the end user doesn't want bad data either.

I got around the metric/statute thing by putting the label as km/miles and posting as the watch is set for.

i do the same. but if you want that the field is also properly interpreted by 3rd party sites, you have to add a 2nd field, which have to be in metric. this field is the one used by the 3rd party site. this i have to do for distance and pace (session + lap + record) . so I have created 12 fields where 6 would be enough. and i also had to create the conversion to imperial logic, while this is not necessary in 3rd party sites (to make things worst, most lap fields wont be shown in GC. but this is another sad story).

I feel garmin doesn't want tainted data from rogue IQ apps. I agree with garmin, however the end user doesn't want bad data either.

is this the reason why garmin does not override data? until now i had not read this reasoning. if this is true, then this is a lame excuse, because
1. it is not garmin data. it is my data being stored by garmin
2. it is really straightforward to manipulate files with an editor (there are several sites for instance showing how to manipulate gpx files to fool strava). one can even import my fit file with native fields into sporttracks.mobi, and then, in sporttracks.mobi generate a gpx file. if then one imports back this gpx file into garmin connect, the developer fields have been converted to native fields. Distance is not zero, and so on. so this is not garmin not wanting tainted data. this is garmin being to lazy to implement the conversion in a reasonable way (and with charts in colors other than black... :( )

GPS based altitude data is also tainted. and Garmin connect does show it. in the end, this is the best the watch can do. and it shows a switch to change between watch data and real data.

I would agree that garmin would add a switch to native data which is coming from a "rogue" IQ app. or that data would be labelled. but the current status is really disappointing.

I share the complaints.

Hi,
I share the complaints ... The Garmin Connect developers do not follow their own SDK !!

Brian.ConnectIQ, Why didn't you answer my question from 03-31-2017, 05:32 PM ?

It is the first issue of override native fields are being displayed in connect app/web.

If 3rd party sites are using the Garmin API, why isnt Garmin using its' own API override feature? If not, I guess the fundmential question is, why offer the override in the SDK if it is not going to be used?

I didn't answer that question because I don't have an answer. I agree that it is odd we have the feature in the SDK, but do not support it on Garmin Connect.