Gadgetbridge: [DEV] Gadgedbridge specific API for pebble watchapps/watchfaces

[danielegobbetti]

This issue is for coordinating the Gadgetbridge devs (working on pebble support) and pebble developers who are willing to support Gadgetbridge specifically.
It is mostly meant for developers, but everyone who has good ideas to share is welcome to do so. However off-topic questions and comments will not be tolerated.

tl;dr: Please stay on topic. Non-constructive messages will be deleted.

With the release 0.17 Gadgetbridge added support for weather data, and in the future the currently running watchface/watchapp will have a background JS runtime just like the official app (well, a subset of it). (There's a branch for that)
Unlike the official app, watchfaces/apps are currently unable to access the internet. We have plans to allow some kind of internet access (see #302) but:

1. it cannot be taken for granted (user will be in control)
2. it makes little sense for every watchface to fire XHR requests to get data (e.g. weather) we can provide locally

The question is what is the best way to provide these data to each watchface/app, and that's why we would like to hear the opinion of developers.

The approach that sounds more promising to me at the moment is:

1. the data is accessed in javascript, by the means of a new Gadgetbridge object.
2. the Gadgetbridge object will fire some events that each app's js will then intercept, manipulate the returned data and then push them to the pebble side using the normal Pebble.sendAppMessage function.

Theoretically, this could allow each watchface/watchapp to detect if it's running within official Pebble app or Gadgetbridge (by checking for the Gadgetbridge object) and choose wether to fire XHR requests to fetch the weather or wait for the Gadgetbridge event to be fired: either way it will get data, process them and then push them the usual way.

Once we find agreement on the basics (please note that what described above is just a proposal!) we can start discussing details like the exact format of the data, how to best document this new "API" etc.etc.

pinging @ashimokawa , @krayon and @tilden .

[jneubrand]

Here are my 2¢:

• Gadgetbridge object: probably not the right choice if this is only for weather. Something like DataProviders.on('weather') would allow for cross-compatibility without name reuse if alternative phone apps for pebble are made.
• internet access: I agree with the general sentiment. However, I feel that it would be more logical to require each app to provide a list of sites it may access, show this to the user, and restrict user control to on/off switching for internet access as a whole. Anything more fine-grained would quickly become confusing for users and annoying for devs.

[danielegobbetti]

Well weather is something we have already and would be immediately available to watchapps. Other info already available are location and sunrise/sunset time. I didn't mention them explicitly as they are in the response by openweathermap but I probably should have.

Adding methods to the Pebble js object instead of creating a new one is of course also an option.

[jneubrand]

Other info already available are location [...] as they are in the response by openweathermap

I assume you mean reverse geocoding? :) Geolocation is being exposed through the standard api in PebbleKitJS and I strongly urge you to continue the trend of using standard JS apis whenever possible.

---

In general, I think that this (WearableKitJS? :P ) be kept as platform-agnostic as possible. The Pebble object only provides access to Pebble-specific things—notifications, webviews, watch info, account/watch tokens—and, therefore, Pebble is a good name for it. Similarly, GadgetBridge would be a good name for GadgetBridge's configuration API.

Conversely, weather will eventually (hopefully) be provided by other wearable phone apps as well. I don't feel strongly about how this is named, but it would be really great if it'll be something others can use as well :)

Super happy to see this progress :D

[KonradIT]

I'm the dev behind GoProRemote, I agree with @jneubrand , maybe the app page in GB could have a internet toggle, and when its on a way to input allowed origins (eg for my case it would be the camera IP).

[danielegobbetti]

Please add your remarks re internet access in #302, thanks!

[Avamander]

I'd love if GadgetBridge provided a way to trigger specific intents (and get responses through PebbleKit maybe).

[danielegobbetti]

@SuperPichu please post your comment to #189

[danielegobbetti]

Since master supports (optionally) background javascript execution I'm closing this.