I'm looking for a way to implement a truely modal user prompt. I want to be sure the user either presses the Yes or No screen button to return to my app. I would be happy if the back button exits the app.
When deployed to the watch, UI.ConfirmationDelegate isn't really modal as
the back button clears the prompt and
there is a timeout that clears the prompt after some seconds.
There is nothing in ConnectIQ that does this. The built-in menu and confirmation classes all allow the user to press the back key, and this is by design.
there is a timeout that clears the prompt after some seconds.
I don't recall there ever being a timeout with the built-in Ui.Confirmation class. Are you sure you aren't running into a widget timeout?
Thanks for the design reference It seems the Cancel part of "Yes/No/Cancel paradigm" is what I'm unable to disable. BTW the emulator is still operating in a Yes/No mode so the foreshadowed update to the emulator hasn't yet been implemented.
Are you sure you aren't running into a widget timeout?
On the VA-HR the confirmation screen definitely disappears after 30 seconds and the underlying app screen is displayed. Can you suggest a reference to "widget timeout" so I can investigate further?
"Widget Timeout" only applies to widgets (not watch-apps). On the va-hr, you get to widgets by swiping up or down from the watchface.
They are meant to be a "quick view" type of thing, and if you are looking at a widget, after the timeout (it's 45 seconds on the va-hr, IIRC), you are returned to the watchface.
I loaded the "ConfirmationDialog" sample from the SDK on a va-hr and 230, and the dialog does time out on the va-hr (after maybe 30 seconds) and not on the 230.
(I did switch it from a widget to a watch-app to be like your case)
Ok, in this case, I started a post in the bug report forum, and there Coleman said he reproduced it. It's a FW problem on the va-hr, so the ticket goes off to the platform group. The platform group mixes it in with other stuff and prioritizes it, and when they fix it, it will be in the FW release after that. (which may not be the next one, if they are finalizing one right now). So once it's fixed, it will be in a FW update, and not in an update to the CIQ SDK.
But... You can make a small change in this case, and not have to wait for a fix.
Instead of using a confirmation dialog, you can use a menu. Just a simple one, with two options - "Yes" and "No", or "do it" and "cancel", etc.
Instead of using a confirmation dialog, you can use a menu. Just a simple one, with two options - "Yes" and "No", or "do it" and "cancel", etc.
I experimented with the SDK sample menuTest by inserting System.exit() in the onBack callback. But it seems the back button doesn't trigger onBack(). The API documentation is a little coy on the subject, simply:" When a back behavior occurs, onBack() is called", to which, I suggest, Homer Simpson would respond: "D'OH". On both the VA-HR and the emulator, the back button closes the current view without activating the onBack callback, so present me with the same problem: a Yes/NO/Cancel instead of Yes/No.
I'm a little sorry you reminded me about the bug report forum. The number of items being "referred to the team" makes pretty worrying reading for someone considering a future with this product. I was hoping its lineage would have made it far more reliable than pebble!
As Travis said in post 2, with a menu/Confirmation dialog, the back button simply clears it (the cancel thing), and this is by design. That back is seen and handled by the firmware, and not seen in your app.
Let's say you want to use the menu to exit. You do a menu like "Continue" and "exit", where in the code for "exit", you exit the app. When recording a .fit, and the user does the action to display the menu, I'll call session.stop() and stop the recording, and then display a menu with "Resume", "Save", and "Discard". While the menu is displayed, the recording is paused (the stop() does that). If resume is selected, I restart the recording (session.start()), if save, then session.save(), and be in a state that after the menu, a summary page is displayed, and if discard, session.discard() and I exit the app and there's no summary screen.
If the back button is used on the menu, the recording remains paused, and the user can go back and looks at the various screens, and later do the action to bring back the menu and take one of the three actions.
OK, So the menu doesn't offer a Yes/No solution and doesn't provide an alternative to the Confirmation dialog.
Is my reported behavior of the onBack callback (not being triggered by the back button on emulator or VA-HR) a bug, or am I misinterpreting the SDK documentation?
