FitContributor :nativeNum functionality

There has NEVER been a reply or acknowledgment to the customers here in this forum.  VERY disappointing that @AlphaMonkeyC and Garmin thinks of its active and purchasing customer base.  If it wasn't for this developers apps I would not be using or enjoying my Fenix 5x so much and probably buying a new one.

This functionality seem political and discriminatory based on its unevenness and the lack of reply from Garmin over the years or EVER.  We have been "dismissed" as irrelevant.

My consumer dollars may be following suit.

I'm adding to the list of complainers here. This is an obvious anti-competitive behavior by Garmin. This prevents competition of other apps on their platform with their own apps. It's also pure non-sense to have a platform for developers of fitness apps and then essentially, have the platform empty of features. If you can't replace any native field then what are fitness apps supposed to be doing? Essentially nothing.

I also want to echo the general sentiment here. It's a poor decision by Garmin @AlphaMonkeyC , and against your own customers. 

Actually, it's not AlphaMonkey.  He's CIQ, while what's shown/used in GC is a whole different group.

The basics are that garmin trusts their own data, and it's possible that data supplied by an app might not be that good.

jim_m_58 said:

The basics are that garmin trusts their own data, and it's possible that data supplied by an app might not be that good.

For what it's worth, Stryd came to the same decision. Stryd PowerCenter used to accept power data written by 3rd-party apps using nativeNum, but now they only accept power data written by their own apps. In this case, it's for a couple of reasons:

- They want to eliminate support issues from customers using 3rd party apps which write bad power data

- Their own app records several additional metrics besides power, and they want all of that data so they can do a complete analysis of the activity on the back end.

I def understand the frustration here, though.

that is of course an opinion and in my over 35 years in IT and most in software and even testing compilers in the 1990s as well real time operating systems and hardware drivers.......there is no basis for this "protection..  With the APIs and the "favored internal code writers writing Garmin apps" (many are VERY poor) using the same libraries and objects there is NO reason for the restriction.  i will stack Brown's code and apps against easily 20 canned Garmin branded apps as crap and inaccurate even though "blessed" and protected by Garmin.

The kindest thing I can say is this is "stupid" and "dumb" and the attention (NONE in YEARS here), support,  and response and position to it by Garmin and I as a customer and Fenix 5x owner is VERY disappointing.

How long have you been using CIQ on a Garmin device, in the Garmin universe?

Let's just say for me, I started with CIQ in 2015, now that I'm retired after being a systems programmer for 45 years.

I think you need to get a better understanding of things.

ThomasJohnLynch said:

that is of course an opinion

I wasn't offering an opinion, except for this:

FlowState said:

I def understand the frustration here, though.

My main point was that Stryd did the same thing (reject 3rd party data not produced by their own apps). The reasons I gave are not opinions, they are (paraphrased) statements from Stryd itself.

I feel your frustration as I've had the same problem trying to write apps which support writing power (or writing any kind of built-in activity metric). Users have also asked me whether my apps can properly write metrics like power and I always have to say no.

If we just look at the history of this forum, the complaints from both users and devs go far beyond this issue. I've probably complained as much as (or more than) anyone else.

Having said that, there's still a reason that Garmin sells watches, even though Apple could probably crush them in an instant if they wanted to. IMO, the reason Garmin sells watches is the same reason that Apple hasn't crushed them -- because they serve a niche market in a way that other companies can't or won't. It's similar to how Kindles still exist in a world of iPads.

I can't fault Garmin 100% for wanting to control their own platform. Nobody ever said that a Garmin sportswatch is a general purpose "open" platform like a PC, Mac or Linux box. If Garmin succeeds or fails in the long term, I doubt this one issue will have anything to do with it. 95% of the runners I know don't even know or care about Connect IQ apps.

Now ^ that's an opinion.

Edit: BTW, Dozen Run is one of my favorite apps, although I don't use it as much as I used to -- just so you have an idea of where I'm coming from.

don't need to understand "things" any more then the scope of this problem and topic., I am addressing this issue only and its pretty simple and clear....I can explain it to you if you are having trouble with these "things".

I am a user and customer and don't want to expect to run into this type of control and incompatibility when Garmin markets, brags, and shows a bunch of developers supporting their product with pages of apps...and in a deceptive way telling the customers the products can do all kinds of things.....thank you for your $800........but when you do something as simple as SWIM a feaking lap in a pool and realize their canned product is deficient and actually fairly inaccurate and find another superior product and then pay/support it.......but the developer community is locked out of features and functions that the "in house" preferred apps that don't work that well DO have access to.

just want my apps and programs developed for the platform to be treated and work equally and if there are concerns or issues let Garmin certify or qualify the code just like Google and Apply OR any other entity.