• Honestly, I wasn't very convinced by @Ganblejs's idea either - but then I tried it and it did make a huge difference to how the watch felt.

    Regardless of whether there is feedback, making the new app load ~200ms or more quicker is a big improvement.

    The problem is that while several people were very vocal about wanting support for long button presses, the reality is that nobody actually uses them, as the long press currently reloads to the clock at an OS level.

    ... but even if someone did want to use long presses you still can do it easily (with the btnRelease handler) - it's just that in the 99% of cases where long press isn't used, it makes sense to use the rising edge.

    So somewhere there is something hindering the watch from acting on the first rising edge after a long press of the hardware button. But not the first falling edge it seems.

    Hmm, this is a problem. So I think what's happened is:

    • Button is pressed to load the clock
    • The clock itself takes a long time to load
    • The button is pressed again to load the launcher
    • Bangle.setUI gets called at the end of the clock loading, after the button has already been pressed.

    The solution that comes to mind is:

    • In boot code, add setWatch(()=>Bangle.BTN_PRESSED=true,BTN­,{repeat:0,edge:"falling"});
    • In setUI, before we do setWatch(Bangle.showLauncher do if (Bangle.BTN_PRESSED) Bangle.showLauncher() else setWatch...
  • So somewhere there is something hindering the watch from acting on the first rising edge after a long press of the hardware button. But not the first falling edge it seems.

    Hmm, this is a problem. So I think what's happened is:

    • Button is pressed to load the clock
    • The clock itself takes a long time to load
    • The button is pressed again to load the launcher
    • Bangle.setUI gets called at the end of the clock loading, after the button has already been pressed.

    I don't think this is it, at least not the full picture. It feels like it doesn't add up with the following I posted above:

    By changing to a clock that takes slightly longer to load, e.g. LCARS is what I used, I could test what happens if:

    1. You release the hardware button AS SOON AS the Loading... message appears - before the clock face has had the time to finish loading.
      or
    2. You release the hardware button after the Loading... message has been shown for a while, say two seconds - when the clock face has had the time to finish loading.

    The problem only manifests for case 2 (on a factory reset watch as well as on my personal usual setup).

    To clarify that, I do for case 1:

    1. Have the clock face be in a state where a short button press will fastload the launcher (I use launch and antonclk currently when writing this).
    2. Press and hold the button.
    3. The launcher is loaded on button rising edge.
    4. Release the button as soon as the Loading... message appears.
    5. The clock is loaded and shown with a short delay after the button was released.
    6. Short press the button to load the launcher (It works!).

    And for case 2:

    1. Have the clock face be in a state where a short button press will fastload the launcher.
    2. Press and hold the button.
    3. The launcher is loaded on button rising edge.
    4. Release the button only after the Loading... message has been showing for a while (it doesn't seem to matter how long I wait with releasing the button, as long as it doesn't go on to trigger the watchdog).
    5. The clock is shown immediately on button release.
    6. Wait 3 seconds (or more) to make sure that all clock code including Bangle.setUI has run.
    7. Short press the button to load the launcher (It doesn't work!).

    I think points 6 and 7 in case 2 rules out that it's a problem with the Bangle.setUI not having run yet.

    I believe the problem manifests when we hold the button and go through an regular, non-fastload, load cycle with the whole boot process being run and only release the button after the boot process has finished. If we release it ASAP when the boot process was initiated there seems to be no problem.

    Can it have something to do with the watchdog functionality?

About

Avatar for Ganblejs @Ganblejs started