Overhaul Notifications & Gadgetbridge

[gfwilliams]

Merge:

• Added app to handle fullscreen notifications #130
• Gadgetbridge fullscreen notifications #131
• Adds gbridge call notification and refactor widget #155

Need to arrange that apps can create a notify module in storage, so you can then load an app from the app loader and have the scrolling notification, fullscreen notification, or any other custom notification (eg. custom look & feel)

Then remove notification rendering and just require("notify"), which should simplify the gadgetbridge module.

Also need docs :)

[gfwilliams]

Ok, I could do with some input on this...

Looking into it, it feels like there's not a great deal of common code here just for Gadgetbridge - all the code (bar ~10 lines) is either handling user interaction or how stuff is rendered.

So personally I think this is somewhere where abstraction doesn't help us...

• Fullscreen notifications? Chances are we'll want new, bigger icons, different layout and different interaction methods. I think a complete new 'Gadgetbridge' app is needed.
• Different music controls? I think a new app makes sense there too.

Any thoughts?

[detached]

Maybe we could implement a messaging system to loose coupling between gadgetbridge infrastructure and user interaction code. The gbrigde widget could just deal with the app communication and broadcast messages. Other apps could subscribe to gbridge messages.
With this architecture the user could choose the look and feel of the interaction with the phone by installing different apps and widgets. And the gbridge widget wouldn't be bloated by rendering code.
https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

[gfwilliams]

The problem is we have extremely limited memory, so we don't want to be unpacking and repacking the message.

The simplest way to work around this would be to just have a global function GB(o){Bangle.emit('GB',o)} - so just emit the gadgetbridge events and then apps can do Bangle.on('GB',...).

However a super-simple thing to just build into each app would be:

var _GB = global.GB;
function GB(o) {
  // ...
  if (_GB)_GB(o);
}

which would work around that too, without needing any common code.

[Purple-Tentacle]

I am up for more music controll. Things I want ( and am testing)

• Play / Pause
• Commands not only working when music notification is shown

[detached]

@gfwilliams sry I don't get your last js example, but the first idea works like a charm.
I tried to reimplement the gbridge connection as a POC: I have broken down the gbridge app into three parts: connector, messages and music.
The connector just emits the GB messages.
The messages shows notifications and allows browsing the last five messages on the watch.
With the music app you can control the player on the phone.
https://github.com/detached/BangleApps/tree/new-gbridge/apps

[gfwilliams]

My comment showed how you can chain GB calls - so one call to GB(...) will end up calling all the others. It just seems easier than having to install another helper regardless of whether you use gadgetbridge or not - plus it gives you the option of not forwarding gadgetbridge calls to other stuff deeper down if you think you've handled it.

(function() {
var _GB = global.GB;
global.GB = function(o) {
   console.log("second");
  if (_GB)_GB(o);
}})();
(function() {
var _GB = global.GB;
global.GB = function(o) {
   console.log("first");
  if (_GB)_GB(o);
}})();

GB()

[gfwilliams]

Ok, so if you look at a4ec996 I've added the workaround. If you were to just make your apps/widgets do that then they would work perfectly with each other without requiring the emit

[gfwilliams]

Closing this, as we're now doing chaining, we have modules for notifications, and things are working a lot better