Disable touch programmatically

flocsy🤠 said:

Some apps do have settings that can be reached from the watch i.e by long pressing the menu button.

I'm not familiar with that functionality.

It's useful when you want the user to be able to change the settings even when the phone isn't around - something that sounds like a useful feature for an app that people use on a boat where they don't want the phone to fall into the water ;)

There are a few settings that I'd like to enable from the watch so it sounds very useful, but how do you implement it?

search for "on-device settings". i.e: https://forums.garmin.com/developer/connect-iq/f/discussion/237508/sdk-3-2-on-device-settings

Not very detailed, but the last paragraph here: https://developer.garmin.com/connect-iq/core-topics/properties-and-app-settings/ gives you the functions you'll need to look at in the SDK

Thanks, I'll look at it over the next couple of days. I'm busy with another project at the moment.

I don't know what "this" is (sorry, my mind-reader module is broken), maybe better to include your code.

In my experience these things are better to see in real device, because the simulator works a bit strange when you do the touch / gesture things using a mouse. But it should work the same. I usually implement all the functions in the delegate and just have 1 line where I log the parameter, so I can understand what's going on, and then start to "play" with the return true/false.

But I agree it's a mess, there's no documentation that explains what I think should be explained, i.e: what's the order of the event flow, where it continues after returning false in a certain function. The only thing in the documentation is this sentence: "If a BehaviorDelegate returns true for a function (indicating the input was used) then the InputDelegate function that corresponds to the behavior will not be called." But that is not very helpful if I want my app to support input both using the physical buttons and the touch screen if it is available. So in my last app I had to "disable" onBack, onSelect (by not implementing them) and instead I do what probably their default implementation would've done anyway: use onKey events and call onBackImpl and onSelectImpl (which are what previously I had in onBack and onSelect, just renamed the functions)

Sorry, forum as well is not very intuitive... Me reply was for a Flowstate post, regarding overriding touch event methods.

Thank you for your clarifying reply though

flocsy🤠 said:

Are you aware of Toybox.System.DeviceSettings.isTouchScreen?

But he wants to know which devices have “hybrid touch” (or what I would call optional touch, where all the crucial functions of the watch work when the touchscreen is disabled *), which won’t be reflected by that field.

(e.g. Venu/Vivoactive have “mandatory touch”, newer forerunners and fenix have optional touch)

flocsy🤠 said:

I don't know what "this" is (sorry, my mind-reader module is broken), maybe better to include your code.

But if you looked closely at the post you’re replying to, you’d see it’s not in reply to you.

And if you’d read the rest of the thread, you’d see it’s somewhat clear from context what they’re talking about (and that they were referring to code that was posted 2 years ago).

Maybe this is yet another data point which suggests that in most cases, old threads should be locked. I think some exceptions would include: threads which have activity within the last few months (so long running feature request threads can stay alive), and CIQ developer showcase support threads.

SebaCh said:

Sorry, forum as well is not very intuitive

Yeah, the CIQ developer subforums used to have threading with infinite scrolling enabled, but Garmin changed it back to linear paginated mode (to match the rest of the forums) when they realized the usability was bad, especially for long threads. This forum platform sucks in general, I begged them to use nodebb or discourse when they switched platforms years ago, but ofc it didn’t happen. Garmin in general is bad at anything to do with infinite scroll / long lists (see the Connect app and website, as well as the device reference on the CIQ website - it’s just one huge monolithic page with 100s of devices, no loading on demand and no navigation elements, which causes several technical and usability issues.)

Anyway I’m not sure why overriding touch callbacks in the input delegates works for you in the sim but not on the real device. I don’t see any reason why it shouldn’t also work on the real device unless there’s a bug. If you have a device app with an input delegate that overrides all the touch callbacks and return true (without doing anything else), I don’t see how your app could possibly respond to touch. However, if you actually want something else to happen on onTap and onSwipe, then yeah, flocsy is right and we’ll need a bit more calrification.

If I have some time maybe I’ll try it out on my 955.

Also, have you tried the Input SDK sample? It changes text on the screen in response to various input events so you can see how the input delegate works. You could try making a copy of it and modifying it for your purposes, to see what’s happening on the real device.