I noticed that there are Multiple “Steps” field. I also noticed that there is a “built in”
Built in = “steps” (all lower cased)
The one I was using / updating was called “Steps” (uppercased “S”) and is a custom field.
I’m now worried that I will break things if I were to change it to “steps” (the built in one)
You can probably update both. The update to “steps” will always work. I am not sure what will happen if you update “Steps” for someone without a custom field with that code.
Currently, it will report what the server reports which is parsed and shown to the user as below.
should be safe to move it to “steps” rather than the custom, tho it would mean that, all my steps fields would be populated on a “different” field.
Tx
Edit: Just initated a “past data sync” (only for “steps”) and and all is back. (tho now there would be duplicated data in “steps” and “Steps”)
When a user adds a new custom field. Will it default to Public / Private / Follower?
Is the reason why there are so many “duplicate” fields because users are inadvertently selecting Public / Followers?
When a user searchs & Adds a public field, possible to restrict it to be private? This would clean up a lot of these duplicate fields.
The other thing i observed is the “code” is case sensitive, hence we can get “steps vs Steps” and “DeepSleep” vs “Deepsleep”. Making them case insensitive (eg: code.lowerCased()) would solve some of the “same name duplicates”
what do you think? Or should I create a way for users to do their own mapping?
DeepSleep → Deep Sleep
DeepSleep → DeepSleep
DeepSleep → Deepsleep
DeepSleep → deepsleep
Users can’t create Custom Fields starting with a lowercase. That’s what @david implemented to keep the native fields separate.
Any lowercase starting field is baked in. Hence ‘steps’ is the default one. If a user needs to get steps from a source not directly supported, he would need to create a ‘Steps’ custom field. Since there are numerous different sources, there are also numerous custom fields with a slightly different script behind it. If they should all be public is another thing…
ah… didn’t know that.
right now, I see “DeepSleep” and “Deepsleep”. Maybe instead of camelCase, it can be checked based on UPPERCASED? so DeepSleep and Deepsleep is the same so users are forced(?) to create a separate name, reducing confusion.
eg: Should I use the one “Deep Sleep (code = DeepSleep)” or “Deep Sleep (code = Deepsleep)” but unfortuntely the code is not visible, only the name Deep Sleep
with flexibility comes …
@MedTechCD since you’re the creator. Can you please ammend this to show .0f format similar to the other 2 you created?
To Keep it consistent as sec rather than milisecs
Tx
Yours:
From WorldOkayestCylist. ( I see he added the convert so it’s in hh/mm format)
or is it that I can edit my own “copy” of it? (Cos I tried this and it works but unsure of the repercussions.)
Edit: Okay… looks like those that has the same “Code” like the one I pasted above from @MedTechCD and @WorldsOkayestCyclist, the diff which I can see is the other is converted to hh/mm format. But internally from the API, both are stored as seconds.
So if I Upload Wellness to DeepSleep at 3777(secs), Both (MedTechMd or from worldsOkayestCyclist) will update the same “Code” w/ the same value. But the display to the user will be different.
