I agree that the design isn’t great (i.e. less than useful for devs), but my point stands: it’s by design, so Garmin probably won’t change it. The same type of bug was filed for UserProfile.restingHeartRate and Garmin said it was by design.
Will you file the same bug report for UserProfile.runningStepLength and expect different results? I’m not saying you shouldn’t file that bug report, only doubting that Garmin will address it any differently than restingHeartRate or walkingStepLength.
> There are a lot bugs in doc
But in the case of the UserProfile fields, it seems there is already precedent that the fields marked “as configured by user” only reflect the value as configure by the user. See: UserProfile.restingHeartRate.
The point is not to say that the docs are infallible, only to provide evidence for my educated guess that walkingStepLength is the same.
> It can by custom or auto? If yes developer should obtain both...
Yes, I think it would be better if CIQ would return the actual step length (or resting heart rate) rather than only the configured value. Perhaps they have or had some justification for doing it this way that we’re not privy to.
1. The name of property is walkingStepLength not walkingStepLengthConfiguredByUser... Can you say that Garmin in each call this variable in its code use if (customlength)... No normally you make it once on start because step length is physical value and it's only one: calculated auto OR information from user...
2. More important is value calculated by system because my own is known for me and I can use it in code directly or by settings. +
3 There are a lot bugs in doc, almost everything can be null, it's easy to add something to doc to fix bugs... But getHeartRateZones returns null on some devices and shouldn't be null, so adding info that it can be null fix bugs?
4. As walkingStepLength is from 1.0.0
5. CIQ is for developers. What does developer need? Step length. It can by custom or auto? If yes developer should obtain both... Maybe it's a secret?
”Our 4.0 API docs state that this value may be null (this was not the case in earlier docs). It's currently working by design.”
> On my f7 returns null and I reported the bug months ago..
Since you (_psx_) were the one who reported the restingHeartRate bug, are you surprised that walkingStepLength seems to work exactly the same way (especially since both fields are documented the same way — “as configured by the user”).
We may not agree with the design, but that’s apparently the way it’s supposed to work. As I said for the other bug, I think the real fix would be to introduce new fields that provide the “calculated” values for resting HR, walking step length, or any of the other UserProfile which are documented to return configured values, rather than changing the meaning of existing fields.
It does seem that the UserProfile doc is pretty explicit about which fields are calculated and which fields are configured. (It’s too bad that they don’t account for certain fields which can be either calculated or configured, on the device itself).
