Fitbit SDK and APIs despredly needs to talk to phone apps on Android and iOS

[PetrNalevka]

All major smartwatch platforms which support apps on the watch also support communications between the watch app and the 3rd party companion apps on the phones. This includes Android Wear, Galaxy Gear, Garmin Vivosmart, Pebble...

We desperately need a way how to talk to phone apps. At the moment the only very cumbersome workaround is to create a HTTP server with a local URL on the device and use the fetch() API.. but two way communication is only possible through polling and in all cases this will negatively affect battery life of the phone..

I think this limitation is a great burden to very interesting use-case which are simply not possible with FitBit. For example we would really like to introduce the Ionic to several million of our Sleep as Android users. 

Even without any API changes there is a super simple ways how to allows 3rd party integrations from within the FitBit app. For example on Android if a companion messages would also broadcast an intent with the parameters (target appId, name, payload..) like intent extras we are all done, this would open this platform to all the amazing on phone use-cases. Implementation time of that in the FitBit app is 1 man hour and there is no need to change the APIs!

[Drukar]

"The only thing holding me back currently from upgrading from my pebble to a fitbit ionic is the availability of sleep as android on this device."

I have worn two Charge HRs to their end. Although the Ionic looks amazing, the lack of integration with "Sleep as Android" is a deal breaker for me.

[PetrNalevka]

I though I did create a feature request for this, but apparently I did not or cannot find it, so I did create it now. Please anyone interested in this upvote the post..

https://community.fitbit.com/t5/Feature-Suggestions/Fitbit-SDK-and-APIs-despredly-needs-to-talk-to-p...

[CityMoth]

This was the original feature request: 
https://community.fitbit.com/t5/SDK-Development/Fitbit-SDK-and-APIs-despredly-needs-to-talk-to-phone...

[paperinik]

I realized that communicating back with the device is only one part of the problem.

Another part would be having the device being able to run code in background, otherwise you will be forced to write a watch face in order to handle the incoming messages.

I also proposed an implementation option here: https://community.fitbit.com/t5/Feature-Suggestions/add-support-for-listening-to-a-port-in-companion...

[bw089]

I cannot agree more on this request. This literally prevents any integration with an existing mobile app. This feature is not a wish but a fundamental pre-condition to develop a real ecosystem.

Basically, even if it only works when the watch app/clock face is in the foreground, the companion app should be able to:

- fetch data from a native mobile app

- get simple event notification from the native mobile app

Simple example: fetching phone battery level:

- when the companion starts, it asks the native app for the phone battery level

- when the battery level changes, the companion gets notified (and ideally/optionally, the watch app/clock face is sent to the foreground and the watch screen turns on)

It would open *many* doors, including displaying notification icons in the clock face, integration with existing sports tracker (Runtastic, MeeRun, ...).

Regarding the platform parity, I'm pretty sure that limiting this feature to Android phones would be already a huge welcome step. This could for example be achieved via a very basic abstraction for BroadcastReceiver. Any (even basic) solution would be highly welcome, FitBit!

[Guy_]

Has anything changed in 3 years or more.

It would be nice if a clock or app could simply talk to the Fitbit app itself and raise a notification on the phone.