Why I am not able to pushview() in the Confirmation delegate

Hello,

when user is using my app for the first time, I ask via Confirmation popup if he want to set the date.

    function onLayout(dc) as Void {
        System.println("DataSet: " + Properties.getValue("dateSet"));
        if (Properties.getValue("dateSet") == 0 ) {
            var message = WatchUi.loadResource(Rez.Strings.PopUpMessage);
            dialog = new WatchUi.Confirmation(message);
            WatchUi.pushView(dialog,new MyConfirmationDelegate(),WatchUi.SLIDE_IMMEDIATE);
            
        }

In the ConfirmationDelegate I try to pushView() a Date Picker (which I also use in the Menu)

I also tried to call the Menu2, but it is never shown.

class MyConfirmationDelegate extends WatchUi.ConfirmationDelegate {
    function initialize() {
        ConfirmationDelegate.initialize();
    }

    function onResponse(response){
        if (response == WatchUi.CONFIRM_NO) {
            System.println("Cancel");
            return false;
        } 
        else {
            System.println("Confirm");
            WatchUi.pushView(new DatePicker(), new DatePickerDelegate(), WatchUi.SLIDE_LEFT );
        }
    return true;
    }
}

Any Idea why I it is not shown? I confirmed at least the function is called with the println()

  • Does anyone have an answer for this? I can do System.exitTo(), popView() but not pushView(). Is this the intended behavior?

  • Have you tried switchToView ? Or why not popView and then pushView?

  • switchToView() doesn't work either. And if you do popView() from within the Confirmation you actually pop two views off the stack (the Confirmation and the underlying view on the stack).

    I think this is the main issue here. It doesn't matter if you return true or false in the Confirmation it will always pop the view on top of the stack and if you push a view beforehand...well you know which view is on top now.

    Should I file a bug report if I think this could be improved? My opinion is that the dev should have full control of what happens after a confirmation...

  • I don't know if it's a bug. To me it looks like intended (and somewhat logical), but not well documented. Maybe should file a request to clarify it in the documentation.

    I noticed that there's a difference between Menu and Menu2 in similar regards: in Menu at the time onMenuItem is called the menu view was already automatically popped, but in Menu2 when onSelect is called it's still there. There it might be more like a bug.

  • I was not aware of that difference between the two menus since I only use Menu2. But if every view pops itself after input by the user we could get rid of switchToView() completely. So the Menu2 behavior could be intentional. Weird.

  • I will try a different approach where I push the view I want to be shown after a confirmation beforehand and push the confirmation on top. If the user cancels the confirmation I should be able to pop two views off the stack so it kinda works as intended. Not really ideal in terms of performance but I don't see another way of executing this. Will report back...

  • Why not pushing the view in onResponse?

  • Why not pushing the view in onResponse?

    As per the OP, that doesn’t work.

    I will try a different approach where I push the view I want to be shown after a confirmation beforehand and push the confirmation on top.

    You could also try “scheduling” the action you want to take place after confirmation:

    In onResponse:

    1) set a member variable which indicates that you want to push the DatePicker view. This could even be a reference to a callback function if you need the flexibility to “schedule” different types of actions after a confirmation

    2) if necessary, call WatchUi.requestUpdate() (hopefully this will cause the view that pushed the confirmation delegate to be updated *)

    In onUpdate:

    3) read the member variable from 1) and perform the appropriate action (pushing the DatePicker view)

    (*) If that doesn’t work, you could modify 2) to use a timer to trigger requestUpdate(). Only downside is it’s a waste of a timer. However, if view was already being updated once per second using a timer, then you can piggyback off the existing behavior.

  • I solved it. Here is my code:

    Delegate:

    using Toybox.WatchUi;
    using Toybox.System;
    using Toybox.Application.Properties;
    
    var model;
    
    class MyConfirmationDelegate extends WatchUi.ConfirmationDelegate {
        function initialize() {
            ConfirmationDelegate.initialize();
        }
    
        function onResponse(response){
            if (response == WatchUi.CONFIRM_NO) {
                return false;
            } 
            else {
                WatchUi.switchToView(new DatePicker(), new DatePickerDelegate(), WatchUi.SLIDE_LEFT );
                WatchUi.pushView(new DatePicker(), new DatePickerDelegate(), WatchUi.SLIDE_LEFT );
                return true;
            }
        }
    }

  • My approach I stated before worked aswell, but this looks at least more maintainable and....beautiful. Sweat smile