These are chat archives for abranson/rockpool

Mar 2016
Andrew Branson
Mar 24 2016 08:36
Hi, that sounds really interesting. Definitely lower level than the standard watch api, which is very appropriate for Sailfish.
And if it doesn't conflict with the existing API then why not?
In the original pebble API, watchapps would have to communicate with 'companion apps' on the phone, which of course were platform specific. They replaced that with the JS api in v2 so you could write the same javascript for the phone side and it would run the same on android, iOS and even Sailfish.
Mar 24 2016 15:25
Sure but now if one introduces some "platform-specific" call to the jskit - you again breaking the portability of the app, since app will be bound to the platform where this feature is implemented.
Also am a bit worry abt security constrains. JS environment is effectively a sandbox, while giving DBus invocation option you open entire platform to it. Which is not bad by itself, companion app can do even more, but you know about that when installing the app.
Mar 24 2016 15:31
This functionality would indeed be very platform specific (Jolla, Ubuntu). I don't mind. The compagnion-apps on android/ios are very specific too.
Security is a good point (of course). But like you said, it wouldn't be different than installing a normal phone app. Actually I'm more concerned about the configuration method for just about any phone app. These webpages are hosted somewhere else. I'd prefer a way to bundle the config page with the watch app, and serve them up locally. Then it works offline too.
Mar 24 2016 15:40
Yeah, at least they should have provided common hosting platform for configs, like that their cloudpebble. It's not a big deal to host a config on my web server - once I have it already set up and running, but firing up one just for the app configuration - a bit an overkill
Mar 24 2016 22:39
Hi Andrew, plz review the fix and if all green i'll pr misfit and ordering fixes so that we could close them