Adding "back" button to Weather app (matching Agenda, Health, etc)?

I've noticed some apps on the Bangle.js 2 feature a back button widget in the top-left of the touchscreen (e.g. Agenda, Settings), and other apps do not (e.g. Weather).

From reading a recent commit to the Health app, it seems like supporting the back button widget is the intended way forward (instead of having to install widclose or such). When using the Quick Launcher to access apps from the clock screen with swipes, having the back button is convenient to avoid needing to press the physical button. And this saves on wear to the watch physical button, which I'm a bit concerned about after hearing that others' buttons have become dislodged.

However, the Weather app already calls for the clock UI, which sounds like it'd conflict with using Bangle.setUI({mode : "custom", back : function() … }) to provide a back button.

As someone new to Bangle.js/Espruino, what would be the proper way to solve this?

I think the back button and stuff like widclose/widcloselaunch have slightly different purposes. The widgets get me back to clock/launcher in one touch from everywhere. The back button is/should be more dependent on context. It was initially created for things like menus, to be able to navigate the different layers there without having to create an explicit menu entry for going back. So essentially back navigates inside the current app and on reaching the "root" level of the app it currently either disappears or the next touch goes to launcher or clock. What is actually happening is of course implementation dependant.
This is the reason for https://espruino.github.io/BangleApps/?id=fastload having the redirect option which can redirect every call to Bangle.load (and thus indirectly Bangle.showClock) to Bangle.showLauncher.

Maybe we need some kind of UX guideline in the docs regarding the use of the back button? Or a default implementation going back to clock or launcher (configurable?).

Regarding the weather app, I think the use of the clock UI is a workaround for not having to copy over the clock UI implementation. Since the only thing that UI actually does is setting a button for going back to launcher, replacing that for weather with a custom UI would probably be ok.

That makes sense - in rough Android parlance, the Bangle back button mimics the Android Back button (even down to the inconsistency with which Android apps handle "back" events), and widclose/widcloselaunch act like the Home button/"open launcher" keyboard shortcut, respectively.

I feel like it'd be reasonable to have a default implementation that's either a boolean to enable or made opt-out, similar to how the widget bar can be shown/hidden. However, I'm not sure how practical this would be in reality.

And noted on the weather app! Whenever I have the time/energy, I'll look into making this change.

it seems like supporting the back button widget is the intended way forward

Yes, absolutely!

However, the Weather app already calls for the clock UI, which sounds like it'd conflict with using Bangle.setUI({mode : "custom", back : function() … }) to provide a back button.

I think it would still work fine. I just tested:

Bangle.setUI({mode:"clock",back:function() {
  Bangle.showClock();
}});

And I think that's good. I'm not really sure I understand the reasoning behind making the weather app behave differently to every other app (going to launcher instead of the clock) but my preference would be to make 'back' go back to the clock.

Maybe we need some kind of UX guideline in the docs regarding the use of the back button?

Yes, I guess this might clear things up? I'm just wary of adding to the existing pile of documentation when it seems not that many people read it anyway :)

Or a default implementation going back to clock or launcher (configurable?).

I think we'd already discussed this in a PR? Afaik nothing stops someone from making a one-line custom boot code app that does Bangle.showClock = Bangle.showLauncher if this is what they really want.

And I think that's good. I'm not really sure I understand the reasoning behind making the weather app behave differently to every other app (going to launcher instead of the clock) but my preference would be to make 'back' go back to the clock.

The idea was less changing the way the app behaves and more removing the need to manually remove Bangle.CLOCK after setting the UI to clock. An "clocklike" UI that does not set that marker var would be enough for that. The clock UI messes with some widgets if users forget to remove Bangle.CLOCK and it is not easy to find if none of those widgets are randomly installed during testing.

I think we'd already discussed this in a PR?

Yeah, I think we did :) Actually fastload already includes some optional code to redirect close to every load to launcher so always going to clock is fine with me.

I'm not really sure I understand the reasoning behind making the weather app behave differently to every other app (going to launcher instead of the clock)

Probably because I just copied it from some clock code without thinking too much about it ;-)
And after that we just kept preserving existing behaviour, which is how we ended up with Bangle.setUI("clock");delete Bangle.CLOCK;

my preference would be to make 'back' go back to the clock.

Yes, I agree.
Maybe we should even add a Bangle.setUI("app") mode, where the middle button goes back to the clock?

Maybe we should even add a Bangle.setUI("app") mode

Maybe although I think the current solution of a back => Bangle.showClock should work ok for now?

Whenever stuff like Bangle.setUI gets changed it's a nightmare because it means that we have to polyfill it for any older Bangle firmwares or they will break - so I'd like to avoid changes for things that are easy to work around if at all possible

Right, I can see why we want to avoid changing Bangle.setUI.

But as far as I can tell on Bangle.js 1:

    Bangle.setUI({mode:"clock",back:function() {
      Bangle.showClock();
    }});

opens the launcher (instead of the clock) when you press the middle button.

And

    Bangle.setUI({mode:"custom",back:function() {
      Bangle.showClock();
    }});

does nothing for button presses.

So we end up needing something like this:

    Bangle.setUI({mode:"custom",
        back: function() { 
            // Bangle.js 2 also calls this for button presses
            Bangle.showClock();
        },
        btn: global.BTN2 ? function(b) { 
            if (b==2) Bangle.showClock(); // only needed for Bangle.js 1
        } : undefined
    });

Bangle.js 2 setUI checks if there are any button listeners, and assigns the back function otherwise, Bangle.js 1 doesn't :-(

Maybe we could add similar code to the Bangle.js 1 setUI:

    Bangle.on("touch", touchHandler);
    if (Bangle.btnWatches===undefined) // only add back button handler if there are no existing watches
	    btnWatch = setWatch(function() {
	      btnWatch = undefined;
	      options.back();
	    }, BTN2, {edge:"falling"});
    ...
    // and in widget.remove:
    if (btnWatch) clearWatch(btnWatch);

But I suppose that would lead to the same problem of it not working in older firmware... (On the other hand: it doesn't work now either, so apps that already assign their own BTN2 listeners should be fine?)

That's odd. On Bangle.js 2 this works great with button and touch as you say:

Bangle.setUI({mode:"custom",back:function() {
      Bangle.showClock();
    }});

Maybe we could add similar code to the Bangle.js 1 setUI
But I suppose that would lead to the same problem of it not working in older firmware...
On the other hand: it doesn't work now either

Yes, I think that's the best bet. We need to fix that or setUI({back}) on Bangle.js 1 ends up being a bit useless. Plenty of stuff uses setUI({back}) even now so it's something that should probably be tweaked.

Not sure what you think, but since long-pressing BTN3 goes back, it might be the best bet to use that instead of BTN2? Not sure...

or setUI({back}) on Bangle.js 1 ends up being a bit useless

I don't think it's quite that bad: touching the left-hand side of the screen works fine, and most apps do use the buttons anyway. But for those that don't, it would be nice if this worked.

BTN2 seemed natural, but now you mention BTN3, that would make sense
short-press: go back
long-press: go all the way back

Ok - just done!

Thanks!