Inconsistency btw sim/device: 2nd view of widget, when onPreviousPage() not handled

Environment:
CIQ 3.0.7
Device: FR935

Test Case
1) Create widget app and run it
2) Push second view (e.g. onSelect())
3) Don't handle onPreviousPage() (or return false)

Observed Behaviour
In the sim, nothing happens if the user presses UP. On a real 935, the widget closes (and the previous widget in the loop is displayed).

I assume the same thing would happen when the user presses DOWN, and onNextPage()/KEY_DOWN is not handled.

Expected Behaviour
Sim behaves as real device (at least the widget should close, just as it would if you pressed UP on the initial view)

EDIT: I should've said that I expected the real device to behave as the sim (and do nothing), but of course it all depends on the intended behaviour.

Sample Code
using Toybox.WatchUi;
using Toybox.Application;

class widgettestApp extends Application.AppBase {

function initialize() {
AppBase.initialize();
}

// onStart() is called on application start up
function onStart(state) {
}

// onStop() is called when your application is exiting
function onStop(state) {
}

// Return the initial view of your application here
function getInitialView() {
return [ new widgettestView(), new widgettestInputDelegate() ];
}

}

class widgettestView extends WatchUi.View {

function initialize() {
View.initialize();
}

// Load your resources here
function onLayout(dc) {
setLayout(Rez.Layouts.MainLayout(dc));
}

// Called when this View is brought to the foreground. Restore
// the state of this View and prepare it to be shown. This includes
// loading resources into memory.
function onShow() {
}

// Update the view
function onUpdate(dc) {
// Call the parent onUpdate function to redraw the layout
View.onUpdate(dc);
}

// Called when this View is removed from the screen. Save the
// state of this View here. This includes freeing resources from
// memory.
function onHide() {
}

}


class widgettestInputDelegate extends WatchUi.BehaviorDelegate {
function onSelect() {

System.println("pushing new view");
WatchUi.pushView(new SecondView(), new SecondDelegate(), WatchUi.SLIDE_IMMEDIATE);
}
}
class SecondView extends WatchUi.View {

function initialize() {
View.initialize();
}

// Load your resources here
function onLayout(dc) {
}

// Called when this View is brought to the foreground. Restore
// the state of this View and prepare it to be shown. This includes
// loading resources into memory.
function onShow() {
}

// Update the view
function onUpdate(dc) {
// Call the parent onUpdate function to redraw the layout
View.onUpdate(dc);
}

// Called when this View is removed from the screen. Save the
// state of this View here. This includes freeing resources from
// memory.
function onHide() {
}

}

class SecondDelegate extends WatchUi.BehaviorDelegate {
// same behaviour if this function simply not defined, I think
function onPreviousPage() {

System.println("return false in onPreviousPage");
return false;
}
}
  • This sounds like it could be a FW bug on the 935 and like devices (I see what you see on a f5x with your code). Returning "true" makes it the same as a sim.

    In the case of the back button (unhandled) in the second view, it returns to the first view (as I'd expect) on the f5x, and on the main view, it exits the widget (as expected)

    Interesting, I have a widget for the f5x, where the second view is a MapView, and I don't handle up/down in the MapView Delegate, and it behaves as I think it should. up/down do nothing in the second view.

    But this could be that when the MapView is in Browse mode, up/down are used for pan/zoom
  • Former Member
    Former Member over 6 years ago
    FWIW on my device FR935 FW 12.10 CIQ 3.0.1
  • jim_m_58 thanks for the comment, I am referring to UP and DOWN buttons, not BACK button. I don't think an unhandled UP button should scroll to the previous on a second view, but that's just my opinion.
  • I don't think unhandled up/down should do anything on the second view, much less exit the widget. That was my comment about an unhandled "back" not exiting the widget from the second view.
  • I don't think unhandled up/down should do anything on the second view, much less exit the widget. That was my comment about an unhandled "back" not exiting the widget from the second view.


    Yes Jim, I concur, and I'm pretty sure unhandled back doesn't exit the widget from the second view -- I'm pretty sure it should just pop the second view.

    My bug report is about an unhandled up/down on the second view, not an unhandled back. onPreviousPage() maps to the UP key on 5-button devices.

    Try my sample code on a real device and see what happens. On my 935, pressing UP on the second view scrolls to the previous widget in the loop, as if the user had been on the initial view.
  • This is one that I can see either way, and the question is what the intended behavior is.
  • This is one that I can see either way, and the question is what the intended behavior is.


    ??? I thought you just said you don't think an unhandled up/down should do anything on the second view. It sure isn't expected behaviour for UP/DOWN on a second view to go back to the widget loop, based on how every single native widget works after you "dive in" by pressing START or tapping the screen. But I get why it might work that way, in order to have an escape hatch for badly coded widgets.

    Either way, the sim and device don't do the same thing, hence the bug report.
  • There can be a difference between how I think it should work and the planned behavior of the FW. That's my point! I can see it both ways :)
  • There can be a difference between how I think it should work and the planned behavior of the FW. That's my point! I can see it both ways :)


    Agreed, and yet the sim and device behave differently, so I will insist on calling this a bug. In an ideal world the sim and device would always be the same, down to (known) bugs that will never be fixed (e.g. lack of long press detection on older devices), but I know that's not realistic. So instead, I would hope that the sim always does what's intended, which seems to be the policy anyway.

    Thanks for the replies :).
  • NO DOUBT there is a bug. It's just a matter of where the bug is! :)