Manually exit a widget (or simulate a keyevent)?

FlipStone said:

However, now when pressing back from the main view I get back in the dummy view and you have to press back once more to actually get out of the widget. Is there a way to do this automatically?

System.exit() and popView don't work... the first doesn't do anything it seems and the second isn't allowed.

Is there a way to emulate the back button press or a key event programmatically perhaps?

Yep I have the exact same problem with a stopwatch widget and there's no way around it. It's too bad because it means that a glance-enabled view doesn't have parity with an older non-glance view, since the user has to deal with the extra dummy view.

https://forums.garmin.com/developer/connect-iq/f/discussion/249991/glance-mode-widget-please-allow-popview-at-top-level-for-parity-with-non-glance-widget-ux/

If anyone wants to take that post and turn it into a CIQ feature request, I won't argue.

In my case I need the dummy view because I have special Back button handling (back doesn't always exit the main view in my app).

In your case, assuming that you don't need to handle Back in any special way other than popping the view, could you solve your problem by detecting glance mode and acting differently for glance vs non-glance mode?

Thanks for the extensive info! Hmmm....Don't see how handling things different could work. In order to be able to handle the up and down buttons in the 'main' widget I need to have a dummy 'placeholder' screen in between (for non glance mode) and that enivitably leads to the extra 'press'.

If you mean at least make it work for glance widgets as they don't need it, that's true and I guess I'll do that then. Indeed pretty sucky though.

The simple approach, and what I do in my own widgets, is just not use up/down, and stick with a single view.  I then use onSelect() to toggle the screens, and also have a user configurable time to toggle the screens.  So a user can use select to switch what's displayed at any time, or it switches itself after X seconds.

Much less involved than glance/no glance, and trying to exit from the second view.  I started doing this before there were glances, as I didn't like the multi-step exit when pushing a second view.

jim_m_58 said:

The simple approach, and what I do in my own widgets, is just not use up/down, and stick with a single view.  I then use onSelect() to toggle the screens, and also have a user configurable time to toggle the screens.  So a user can use select to switch what's displayed at any time, or it switches itself after X seconds.

That may be simpler (and I have seen it with some CIQ widgets), but it's not consistent with the UX of widgets in either older non-glance watches or newer glance-enabled watches.

The standard Garmin Widget UX model (from my POV) is:

- Top-level view = non-interactive summary. Pressing START takes you to the 2nd level, if present.

- 2nd level view = more details / possible interaction (UP/DOWN scrolls through more pages, if available). Pressing BACK returns you to the top level.

Garmin takes this model so far that they even have some (non-glance) widgets where the 2nd level view is exactly the same as the top-level view, meaning there was no point in having the 2nd level.

Then again, no one ever accused Garmin of having great UX.

But then again, consistency does count for something. Once the user learns how their Garmin is "supposed to work" it's kind of jarring to see a 3rd party app that behaves differently, IMO. I use 1 or 2 widgets that have the "Press START to cycle through screens" behavior and it's kind of annoying to me. Yes, it's easier because there's one less "mode" to think about it, but it's also completely different than all the built-in widgets.

Plus once you're in glance land (which is the case for all modern watches), you always have that extra mode anyways (glance view vs full view).

Native widgets are not written in CIQ, and can do things you can't do in CIQ

I've has widgets that work as I've described and not had a single complaint about that in 7 years

jim_m_58 said:

Native widgets are not written in CIQ, and can do things you can't do in CIQ

Yes I understand that. I just meant that it's jarring when a 3rd party widget has a different user interface model than most or all native widgets. That's all.

Native things have been able to do things you can't do in CIQ since day one of CIQ!

jim_m_58 said:

Native things have been able to do things you can't do in CIQ since day one of CIQ!

I don't understand why you keep saying this? I know that, and even if I didn't know that, you say it all the time.

I was referring to this:

jim_m_58 said:

The simple approach, and what I do in my own widgets, is just not use up/down, and stick with a single view.  I then use onSelect() to toggle the screens, and also have a user configurable time to toggle the screens.  So a user can use select to switch what's displayed at any time, or it switches itself after X seconds.

Native...widgets...don't...work...like...this. Even on newer watches, START always "drills down" while UP/DOWN flips pages. (Yes, there's some native widgets which support both UP/DOWN and START, but you're flipping between different things in that case)

The user has to learn a 2nd interaction model to work with CIQ widgets which have this alternative user interface model, even though it's simpler. I'm speaking from personal experience because I've used widgets like this and the first thing that jumped out at me is I have to interact differently with them compared to all the other widgets on my watch.

Nothing to do with the implementation or capabitilies of CIQ vs native widgets and everything to do with human-computer interaction and UX/UI.

Just my opinion, but sometimes consistency is better than providing an alternative UI model which may be easier or simpler.

Then again I have a data field which grossly violates this principle and is more complicated, so I'm not always consistent either.