Button navigation

Thanks JIM!! Turns out that user interaction in a DATA FIELD is absolutely supported. I have an EDGE 820 with a touch screen and the SELECTABLE example works well.

However, I want to also support devices like a 520 that does not have a touch screen. And the SELECTABLE example doesn't work well. So I have some basic questions for those who have worked with buttons.

The EDGE 520 has up/down, lap/start, back, power/light, and select butttons.

Q1: Once I call the User Interaction delegate to present checkboxes.... Can I override the buttons so, for example, the STOP/START button will be trapped to trigger my own User Interaction functions, rather than trigger the native device action to STOP/START the running activity? Then when I exit the User Interaction logic, the buttons return to their normal default behavior?

Q2: What is the standard method to switch screens? Emulate a SWIPE right/left with buttons? Maybe use the "power/light" button to scroll thru the user input screens if more than one? Or add a "Next Screen" object on the bottom of the screen to pick and select with up/down and select buttons?

I assume the "up/down" buttons are best used to move from checkbox to checkbox within a screen? The "select" button to then check or uncheck the checkbox that has the cursor? The "back" button to exit User Interaction?

jim_m_58 over 6 years ago

Yes. It's in the bug report forum.

DaveBrillhart over 6 years ago

I'm concerned. I intended to write some really cool features into my sophisticated full screen data fields for ultra cycling, that utilize the onTap() capability. That is a game changer. Such as adjusting a User Setting on the fly rather than getting out one's phone. Or simple but important algorithm interactions with the cyclist depending on the dynamics of the ride/race.

However, even the 3.0.5 description of the getInitialView method says that InputDelegate is not allowed in a datafield. It is allowed, and it works! And I'd like to use it. Do you expect this feature is a bug and will be removed in a future release?

Here is part of the 3.0.5 method description:

Providing a WatchUi.InputDelegate is optional for widgets and watch-apps.
For watch faces and data fields, an Array containing just a WatchUi.View should be returned as input is not available for these app types.

Finally, assuming this is a supported feature... allowing onTap() user input for touch screens..... allowing CIQ developers to write cool features that interact with athletes during an activity. Then they should also allow onKey() inputs so that devices like the 520plus, whicih doesn't have a touch screen but does have a bunch of buttons, can also participate in those features.

jim_m_58 over 6 years ago

The doc is incorrect, in that you can have a delegate for DF's (and use onTap), and for watch faces (when the avg power budget is exceeded.)

Even onTap is only allowed on Edge devices, but not touch screen devices in general. Buttons are used by the native app itself, and aren't available to a DF. And even if they were available, what if you had two data fields that wanted to use the same button?

onTap is all there is with a DF.

Travis.ConnectIQ over 6 years ago

Just FYI, I've added a comment to this post that is relevant.

Nikeow over 6 years ago

I changed my code to detect a quick STOP/START button combo, using the onStop/onStart. Since it is not uncommon to use the Lap button, but it is uncommon for someone to quickly stop and restart an activity.

I tried this.. But I soon got irritated at doing this and it messing up the output. So I discarded this idea.

DaveBrillhart over 6 years ago

I tried this.. But I soon got irritated at doing this and it messing up the output. So I discarded this idea.

Agree. Now that onTap() is an option for me, I'll tap into that feature. I hate the idea of injecting even a 2 second stop/start event into my race data :-)