BehaviorDelegate - onNextPage() with datafields?

onTap only works on edge devices with a touch screen.  No other input is available to data fields.

Ok, thank you for clarification!

There is a trick you can do to allow datafields to accept a very limited form of "input", by leveraging onShow() and onHide(). The idea is if your data field sees that onShow() is called multiple times within a small period of time (e.g. 2 seconds), you can trigger a special action. The user would trigger this action by pressing DOWN, UP or UP, DOWN very quickly.)

For example, I have a full-screen data field which allows the user to switch modes/"pages" by hiding and showing the field quickly (e.g.pressing UP, DOWN or DOWN, UP within 2 seconds.)

In the code you posted, you seem to need 2 actions. You could implement something like this:

- "plus": field is hidden then shown again within 2 seconds (e.g. press DOWN, UP quickly)

- "minus": field is hidden, shown, hidden shown within 2 seconds (e.g. press DOWN, UP, DOWN, UP quickly)

You could also experiment with making the window larger than 2 seconds.

The obvious downsides with this scheme are that it's very unintuitive, and it's too easy for the user to either miss an "input" or to trigger an action by accident (e.g. with my data field, you can accidentally trigger a mode switch by pausing an activity -- which causes the pause screen to be displayed -- then quickly pressing BACK or resuming the activity.)

A similar kind of trick involves detecting rapid pauses or lap button presses, but that obviously has an effect on the recorded activity.

I don't think onHide is called for Data Fields, at least on newer devices.  I recall when this came up, but I don't use onShow or onHide in DFs so didn't worry about it.  In the 3.1.4 change log, there is this, and in the sim, "Force onShow" and "force "onHide" are grayed out if you are running a DF.

• Fix an issue that onLayout isn’t invoked for data fields, also disabled the Force onHide menu when running a data field, as onHide will never be invoked for it.

Thanks, I should clarify/correct myself by saying that in my own implementation of the hack, I only look for multiple invocations of onShow() within a certain window of time. (The reason a simple press of DOWN, UP can trigger multiple onShows is that, IIRC, the page animation that's displayed when you navigate away from a data page triggers onShow(). So the data field receives at least 1 onShow() when you navigate away and an additional onShow() when you navigate back.)

The hack still works on my 945 LTE, which as far as I can tell, shares a common code base with some of the newer watches (like 955 and 965) and even has some of the new features (like wrist-based running dynamics and power.)

I don't think onHide() was ever called for data fields (at least not five years ago).

I did notice that "Force onShow" is now greyed out in the sim, which is annoying to me because I can't test my hack in the simulator anymore.

Also see this thread from 3 years back

Simulator and Greyed Out "Force OnShow" "Force OnHide" - Discussion - Connect IQ - Garmin Forums

Thanks. As I said, I know "Force onShow" is now greyed out, but like the OP of that thread said, I don't like it because it prevents me from testing my hack in the sim.

Because the data field only gets onShow called when displaying for the first time, it doesn't really make sense to allow the menus to be used to trigger onShow.

See, I disagree with this statement. What does "displaying for the first time" mean? "First time" during an activity? That's clearly incorrect because onShow can and will be called multiple times during the same activity for a CIQ data field, as you scroll through your data pages (for example). If that wasn't the case, my hack wouldn't work at all.

Clearly the implicit thought process here is that a dev has no reason to care about the subsequent calls to onShow() (since they never received a call to onHide()), which is probably true in the vast majority of cases.

I did notice that newer watches like 945 LTE seem to call onShow() multiple times during the scroll animation when you change data pages while 935 only calls it once (IIRC), which does mean that my hack behaves differently on new vs old watches. (On my 945 LTE, I can see the virtual page change on my data field while the field is scrolling off the screen. On my 935, the virtual page would only change when I navigated back to the field.)

It's fine for me since I'm just using it to change virtual pages (and I reset to the home page if more than a few seconds elapses between consecutive onShows), but it does mean that the hack wouldn't be good for changing settings unless you tailor the logic to individual devices. (e.g. Test on the real device and count how many times onShow() is called during a data page scroll animation.)

Yeah, in your case it would probably make more sense to implement on-device settings instead of attempting an onShow() hack like I suggested above. I do find it useful for switching between virtual pages within in the same CIQ field, but I think your case is a bit different.