Interacting with a widget

I adapted the "Input" sample of the SDK to run it as a widget. Differently than on the watch-app, the UP/DOWN/BACK keys will always close the program on non-touchscreen watches. It means that the "return true" command in the "onKey" of the input delegate isn't taken into account. I understand that it is made to prevent that the widget loop would be blocked by a poorly programmed widget.

However, I saw some apps in the store which handle those keys. For example: https://apps.garmin.com/en-US/apps/83bad36e-be16-422f-ad79-70eaa01a8173

Could someone please tell me how to implement that?

By the way, I have little bug report related to this issue: a "real" Vivoactive HR does handle the "return true" for the "onKey". For example, it's possible to avoid closing the widget with the BACK KEY. The simulator does not reproduce this behaviour.
  • You need to have a second view to catch the things that are normally used for the widget loop. Up/down by default moves through the widget loop, and back goes back to the watchface
  • Thanks, Jim!
    I managed to do it.

    Now I​​​​​​ just wonder what would actually be the problem to let us handle the input without an extra view [i.e., just using return true for the key/behavior methods]. A "bad" programmer can just push a new view in onShow and block the widget loop with return true for all the keys. So the reason I first thought ["prevent that the widget loop would be blocked by a poorly programmed widget"] doesn't hold, and the solution to let us use those keys [i.e. pushing a view] just adds overhead to our limited memory environment [in comparison to what I am suggesting].

    As I said, handling the BACK key is possible on a real Vivoactive HR even with only the initial view [not in the sim. bug? Inconsistency?]. No one has ever complained.
  • Former Member
    Former Member
    The reason things work this way is to provide a consistent user experience on Widgets, not to prevent bad behavior (as you have seen, this is unpreventable). Though, it may prevent accidental bad behavior to some extent.

    The back key returns to the clock page from the base level of the widget view. That is how the products work, and Connect IQ is not allowed to override that behavior. If the VVAHR is allowing that key to be used, it is probably just a bug in the product.

    You should push a secondary view when the user presses the select key like the default widgets do if you want extended behavior. From that view, you can handle any input, but it would still be ideal if you followed the user experience of the default widgets. This provides a consistent experience for the user so that they can understand how to use your application easily.
  • Thanks for the clarification, Brian. I understand the concept, and I partially agree with it.

    If I'm not wrong, previous versions of the SDK allowed handling the back key with return true on the sim, and so does my VAHR. So I didn't learn to do it in the right way. And I don't recall seeing it in the documentation, sorry if I missed it.