Some bugs in documentation and SDK

[Sergius]

I'm playing with the documentation and typing it with TypeScript.

Well, I found a couple of issues:

• Heart rate has no activated property (or I couldn't find it). It is documented here, but look at the following:
  

  const hr = me.permissions.granted('access_heart_rate')
  	? new HeartRateSensor()
  	: null;
  if (hr) {
  	hr.start();
  	console.log(`activated in hr: ${'activated' in hr}`);
  	console.log(`typeof activated: ${typeof hr.activated}`);
  }

  outputs
  

  App: activated in hr: false
  App: typeof activated: undefined

  I did this check after having no clue about why that check was always false in a condition, although the sensor was already started and giving metrics.
  My typings are the following: https://github.com/SergioMorchon/fitbit-sdk-types/blob/master/types/device/heart-rate.d.ts, placing that activated property in the https://github.com/SergioMorchon/fitbit-sdk-types/blob/master/types/device/sensor.d.ts#L15, just like the doc says.
• Undocumented EventTarget classes, like clock, but they are there https://github.com/SergioMorchon/fitbit-sdk-types/issues/27.
• Undocumented TextInput value property. https://dev.fitbit.com/build/reference/settings-api/#textinput, but it is the only way I found to set the initial value https://github.com/SergioMorchon/fitbit-sdk-types/pull/39/files. This is really critical I think.
• Undocumented TextInput type options. I've tried with all the HTML5 ones, but I only found a few of them working consistently in both Windows and Android. https://github.com/SergioMorchon/fitbit-sdk-types/pull/39/files.
• Undocumented settings page component props https://github.com/SergioMorchon/fitbit-sdk-types/blob/master/types/settings/components.d.ts#L143-L1...: they're critical to keep the settings page updated with real settings content.
• Undocumented "ring" haptic pattern. https://dev.fitbit.com/build/reference/device-api/haptics/ uses it in the example, but it is not listed in the documented. although it works https://github.com/SergioMorchon/fitbit-sdk-types/issues/1.
• Settings API. https://github.com/SergioMorchon/console-watch/blob/master/companion/actions/settings.ts#L10-L28 each setting callback returns an object containing a name which value is the expected new setting value, instead of a string. And in addition, that string contains a stringified version of the real value. That's really weird and annoying, and also reported at the start of the year: https://community.fitbit.com/t5/SDK-Development/SettingsStorage-getItem-from-settings-component/m-p/.... We have new SDK versions, but that is still not fixed 😞

[JonFitbit]

Thanks for this, and your excellent work on the types repo.

I have recreated the issue with `activated`, and it appears to affect all sensors. I've logged this with the firmware team.

I have fixed the `ring` haptic documentation, but the deployment is stuck amongst some other changes.

I've noted your other feedback and will take a look at those next week.

Thank you!

[Sergius]

@JonFitbit I have to add a new issue, regarding the TextInput setting component and its onChange event. Reproduced with latest SDK & Emulator.

Instead of the value (you can think of a string), as the documentation says, the callback argument is a weird {"name": <value>} object.

        <TextInput
          onChange={value => {
            console.log(JSON.stringify(value));
          }}

 You can see this issue: https://github.com/SergioMorchon/fitbit-sdk-types/issues/58

It would be really nice to have some kind of repository under the Fitbit GitHub https://github.com/Fitbit organization where we can:

* Open issues

* Follow issues

* See the Fitbit OS / SDK etc. milestones

[JonFitbit]

Thanks for the feedback @Sergius, public bug tracker and roadmap is on my list too. I've raised this particular issue about the <TextInput> before, but I would assume that the value format will remain the same for now.

[Sergius]

To we have any news on this? We have had major releases of the SDK and still happens