mddub
commented
8 years ago Ah, nice work constructing the message on Android. Really appreciate you thinking about adding support to xDrip. This is good timing: I've been thinking about this as I plan something similar for Loop on iOS. Here are some ideas, none of which I'm completely sure of/committed to:
In my mind, what most complicates things is whether to build a "companion app" version of Urchin (like the xDrip version of the Nightscout watchface) or to use the existing version (which expects to communicate with JS running in the Pebble app).
If it's a companion app, then the watchface can't be configured via the settings webview in the Pebble app. I'm not sure how best to enable an Android/iOS app to do that - adding a webview and parsing/sending the preferences (or even something simple like sending pre-set preferences) adds significant complexity and versioning concerns.
If it's the existing version of Urchin (my preference), then the watchface remains Ridiculously Configurable via the Pebble app no matter what app is sending it data, but communication must be one-way:
- If the project contains at least one JavaScript file, the message will be handled by PebbleKit JS.
- If there is no valid JS file present (at least an app.js) in the project, the message will be delivered to the official Pebble mobile app. If there is a companion app installed that has registered a listener with the same UUID as the watchapp, the message will be forwarded to that app via PebbleKit Android/iOS.
https://developer.pebble.com/guides/communication/
As for your first pain point, I don't mind adding some basic validation/munging of the app messages (e.g. tolerate missing status or pump data). It's something I've been meaning to do, since converting the data message into a struct would also help with caching on the watch. But in the one-way communication scenario, there's no way for the watch to indicate that it received a "bad" message besides blowing up.
One idea is to add a new message type like you suggested. Something like "check message version", which a companion app could send when the Urchin feature is first enabled in settings. The watch wouldn't be able to respond, but it can show the user a success/failure message. This may be overkill.
Another concern is putting the watch into "push" mode instead of "poll" mode. If using camping mode, it shouldn't send data request messages to the phone, because they'll be picked up by the Pebble app, whose responses will step on those from the companion app. I think the simplest is to add "data source" to the settings page, which includes an "app" option.
For your second point (non-SGV data), I don't like the idea of sending the data in separate messages, since it's a big change, and would make caching on the watch more complex. It seems like either YADLA or xDrip should have some data worthy of including in the status, no? (Raw data?) But I'm not sure it matters much if the watch is more tolerant of missing data in the message.
Interested in your thoughts based on your experience with xDrip's camping mode. I'm traveling so won't be much help for the next couple of weeks, but I'm happy to help build what's needed when I'm back.
tuzoenduro
Pogman
I hacked together a quick implementation of an offline mode using YADLA and I wanted to get your input before I ported the implementation over to xDrip where someone else might actually end up using it.
Right now I have the app manually constructing and sending the message to the watch face with this gist.
I see a couple potential pain points and don't immediately see a remedy to them. Is there a way to verify message compatibility between the watch and remote end? I experienced a few crashes while playing around due to data type mismatches between the sending side and receiving side and would hate to make it appear that there was an Urchin bug because xDrip was out of step.
Maybe the solution is to validate data in the watchface or create a new message type for this, but I don't want to push that work in your direction.
The second pain point, and one that I don't have a good answer to, is that of the "extra" data like boluses, status line info, and basal rate info. It's certainly possible for the app to generate these, but that's going beyond xDrip's scope although I could generate the data with YADLA. Would it make any sense to separate out these portions and send them in separate messages?