07-29-2018 09:29 - edited 07-29-2018 09:30
07-29-2018 09:29 - edited 07-29-2018 09:30
From my watch app I would like to send an http request and receive the response. It would need to basically work like `fetch`, but with some sensible and predictable failure modes regarding device-companion communication.
What is the recommended way to do this?
My current understanding
Since only the companion can send http requests directly, my understanding is that I need to do something like this:
And I'm not yet sure I've cracked it, because Messaging is peer-to-peer, and I would have to come up with a protocol on top of that to allow client-server type communication. This introduces a whole new set of complications, like matching requests to their corresponding responses, and handling communication failures.
I've implemented a crude version of this, but I'm pretty sure it would fail under less than ideal circumstances (like the watch being too far away from the phone).
Conclusion
This seems like a lot of work for a seemingly simple operation. Am I missing something obvious? Or has this work already been done by someone, available for reuse?
Thanks!
08-07-2018 18:10
08-07-2018 18:10
There are a number of complications with messaging. Devices being out of range is definitely one issue, but the companion can also go to sleep, or the Fitbit mobile app might be terminated.
In most cases, sending a message from the device should be enough to wake the companion or mobile app, but you would need to add your own validation.
The only similar thing I've seen was a device fetch() implementation by Remy Sharp. https://gist.github.com/remy/2f5dbe7032004a5dd09bd57733d30ab6
This was before the device had support for promises, so you can probably simplify it.
08-08-2018 01:54
08-08-2018 01:54
That's pretty close to my own implementation. Unfortunately, neither can gracefully handle failure yet. I don't see a way to know whether a sent message was received by the other side, except by expecting a response to come back within a certain amount of time. I guess that might be the only way, though it would complicate the code.
This reminds me, this ecosystem could use a more streamlined way to share and bundle packages. It might be a good idea to start supporting npm at some point, and the package.json `engines` field. Anything like that on the roadmap?
If I write a module for this, I'll probably publish it to npm. But I don't expect many FitBit app developers are looking there yet.
08-08-2018 08:02
08-08-2018 08:02
There are some open source libraries listed in our Github repo but proper modules would be great. Perhaps when the CLI tools arrive, we'll be in a better place to support that.
08-08-2018 10:39
08-08-2018 10:39
Sure. In fact, once the CLI tools arrive, I expect we won't require further explicit support from FitBit to get proper modules. I intend to transpile, bundle and minify the code locally, and effectively end up with two javascript files. One for the device and one for the companion, with npm modules inlined. (Let me know if I'm making any unwarranted assumptions about the CLI tools.)