Back button or Ui.popView() problem on Forerunner 230?

We're having a problem with our app behaving strangely on the Forerunner 230 (firmware 3.11) when the Back button is hit.

We have a main view, then show a second view with Ui.pushView(). In that second view's delegate we have:

function onBack() {
Ui.popView(Ui.SLIDE_UP);
return true;
}

Rather than removing the second view and reshowing the first view, as we see on other watches, the app seems to restart. However we don't get an crash logs, and what we think is actually happening is that both the second view and and first view are being popped.

Perhaps the firmware is doing a popView in response to the back button even though we are returning true to indicate that we're handling the event??

Or it may be that the firmware is popping the first view in response to our popView call even though the second view is visible on top??
  • Brandon. For me it is just having to swipe twice or press a button twice. I've been seeing it for some time on the va, but had just chalked it up to me doing a bad swipe. But now that I know what's happening, it's a bit annoying.

    My concern is that if a user sees it and posts about it in a review or something, suddenly everyone sees it, and the app gets the blame.
  • Thanks Brandon,

    I view this as a significant issue because it makes users feel that their touchscreens or buttons are finicky or crappy. It's hard to recognize as a consistent software bug without careful testing.

    I know exactly when the problem occurs so I automatically swipe or press twice now without thinking but I don't think many users are going to discern the sequence of events that leads to the bug so it will appear random to them.

    I guess I just assumed that Garmin would jump on this since it makes the hardware look bad. It seems like a user facing bug with no practical way to cover up should be a high priority.

    Roger
  • Back to the original question, have you tried calling requestUpdate() after the popView()? I have seen, and reported, an issue where the requestUpdate() is required to get the interface to update.
  • I still haven't been able to reproduce this, either with your code or with my own test app. I'll email you directly about it to make sure I'm looking at the relevant bits of code.
  • Back to the original question, have you tried calling requestUpdate() after the popView()? I have seen, and reported, an issue where the requestUpdate() is required to get the interface to update.


    I've already determined that the issue you mention here only affects the sim and not devices. I feel like we have a couple of similar issues that are being conflated in this thread:

    1. In the sim, requestUpdate() is required after a pushView() in order for the view to actually be displayed. This has been reported and is slated for investigation.
    2. Session.stop is causing button presses to be lost (see here). This has also been reported and is slated for investigation.
    3. Some other issue related to popping views during activity recording sessions (this seems to be what's reported on this thread). This I can reproduce with the OPs app, but I haven't been able to reproduce it otherwise. I'm attempting to narrow things down to a root cause. Regardless, this seems to be device-specific since it only occurs on the 230/630 devices.
  • We're having a problem with our app behaving strangely on the Forerunner 230 (firmware 3.11) when the Back button is hit.

    We have a main view, then show a second view with Ui.pushView(). In that second view's delegate we have:

    function onBack() {
    Ui.popView(Ui.SLIDE_UP);
    return true;
    }

    Rather than removing the second view and reshowing the first view, as we see on other watches, the app seems to restart. However we don't get an crash logs, and what we think is actually happening is that both the second view and and first view are being popped.

    Perhaps the firmware is doing a popView in response to the back button even though we are returning true to indicate that we're handling the event??

    Or it may be that the firmware is popping the first view in response to our popView call even though the second view is visible on top??


    Good news... it looks like there was a firmware fix completed just today to address this. :) It may not be as relevant any longer since I believe you had found a way to work around this in your app. I can't say when exactly it will make it our to customer devices, but I wanted to let you know there's been some progress!
  • Good news... it looks like there was a firmware fix completed just today to address this. :) It may not be as relevant any longer since I believe you had found a way to work around this in your app. I can't say when exactly it will make it our to customer devices, but I wanted to let you know there's been some progress!


    That's excellent news, thanks!