Handling back button press with Confirmation view - Vivoactive

When pushing a Confirmation view to the UI stack, and clicking the back button on my Vivoactive while that view is displayed, the onResponse() method of my ConfirmationDelegate does not get called. On the simulator, it does get called with a response of CONFIRM_NO (same as clicking the X/Cancel button in the Confirmation view), which is what I would expect the behavior to be.

Example code to replicate:

var confirmation = new WatchUi.Confirmation("Confirmation?");

WatchUi.pushView(confirmation, new ConfirmationDelegateTest(), Ui.SLIDE_IMMEDIATE);



......



class ConfirmationDelegateTest extends WatchUi.ConfirmationDelegate {

		

	function onResponse(response) {

		System.println(response);

		return true;

	}

}

This issue was recreated on Vivoactive version 3.1, Connect IQ 1.1.3.

Is there a workaround for this issue on the device? The real-world problem I'm trying to solve is that I have a View with a repeating timer that is requesting UI updates frequently in its callback (every 100 ms - I'm displaying a countdown timer). When I push the Confirmation view I get some temporary weird UI glitching (drawable items from my view and the Confirmation view flashing as the Confirmation view is shown) when that view pops up due to my own view UI being refreshed so frequently. If I programmatically stop my View from requesting UI updates before I launch the Confirmation and resume them after it is responded to, I don't see the UI issue. I can easily do this if the checkbox (Yes) or X (No) is clicked in the Confirmation dialog is pressed, because those trigger onResponse() to be called, but I have no way I can see of handling the back button press. Thanks for any suggestions!

travis.vitek over 10 years ago

Is there some reason that you aren't stopping your timer in View.onHide() and starting it back up in onShow()? Maybe you are and the onHide() doesn't get called early enough?

PedlarStudios over 10 years ago

I was not in fact stopping my timer in onHide() and restarting it in onShow(). onHide() doesn't quite seem to called soon enough for my liking when pushing a view, as with a sub-second repeating timer I still get some weird UI transitioning. It is mostly bearable for me and I suspect this is the way Garmin would recommend doing accomplishing this. Thanks Travis.

Former Member over 10 years ago

BHawk124,

The device implementation is actually the correct one; if you back out of a confirmation dialogue, you've chosen to not select either option so there should not be a response issued. I will file a ticket to ensure that there is better consistency on the simulator implementation. Thanks!

travis.vitek over 10 years ago

The device implementation is actually the correct one; if you back out of a confirmation dialogue, you've chosen to not select either option so there should not be a response issued.

What you are suggesting is that there are more than 2 responses to the simple yes/no question posed by the confirmation dialog. That is just weird. Can you shed some light on why this is the appropriate behavior? Additionally, it is inconsistent with the behavior of the confirmation dialog on a fr920xt. Without rebooting the device, you cannot escape the confirmation dialog without answering yes or no.

Travis

Former Member over 9 years ago

Travis,

The suggestion came from the Yes/No/Cancel dialogue box paradigm. I did a little reading on the subject over the weekend, and I'm now leaning more towards the the FR920xt behavior. I'll check into what options we have to prevent backing out of confirmation dialogues on device.

jim_m_58 over 9 years ago

Jason. I just did some tests with the standard apps on the va.

On the "save/discard" screen, if you hit "back", you are given the option to "resume" That makes sense to me, in the event you hit the "start" button (to end the recording) by mistake.

If you hit discard on the above screen, you are shown a "yes/no" screen. There if you hit "back", you go back to the "save/discard" screen. This too makes sense to me, for cases where you hit discard by mistake, and meant to save. (seems to do the same this as the "no" response)

In one of my own apps, I use a menu to select "Record as Run" or "Record as Walk" choice, and when selected, do the proper type of recording. But if you hit "back" on that menu, the app runs without doing any recording to a .fit file (that was by design - I could add a "no Recording" menu selection too), which again seems correct (nothing was selected).

Personally, I think the yes/no/cancel scenario is the way it should be. But I also think it may be something that developers may not test and code for - it can be easy to forget about the "cancel/back" option, but for users, "back" may be a normal thing to do if they see a screen they don't expect..

jim_m_58 over 9 years ago

The way to handle "back" is quite simple to handle. Set a variable in the delegate if something was selected, and if nothing was selected, take the correct action (redisplay the confirmation, or do what is the degined response to a cancel - maybe just to go on assuming one of the two responses..) back in the calling class...

travis.vitek over 9 years ago

The suggestion came from the Yes/No/Cancel dialogue box paradigm. I did a little reading on the subject over the weekend, and I'm now leaning more towards the the FR920xt behavior. I'll check into what options we have to prevent backing out of confirmation dialogues on device.

Jason,

I was mistaken. The fr920xt allows you to select Yes or No, and you can press Back to cancel.

Travis

Former Member over 9 years ago

Jim/Travis,

I discussed the issue with the team, and because all the devices have adopted the yes/no/cancel paradigm, we are going to adjust the simulator to match that behavior. Although I agree that a yes/no dialogue is simpler to think about, devices have chosen to allow cancelling for extra flexibility (i.e. Jim's example) and we need to make sure our emulator takes that into account for now. Thanks for all your good input!

PedlarStudios over 9 years ago

Thanks for the update Jason.