Disable touch programmatically

My solution works but is a bit involved and relies on the user disabling touch on devices with both 5 buttons and touch - which i identify as "hybrid" , like the F7 etc,

I use jungles "exclude"  with hard coded value for each supported watch to identify "hybrid" 

Using annotations, in my code, if the device is hybrid and touch enabled, I Alert the user to switch off touch before the app will proceed. 

Maintaining the jungles file as new devices are added is a bit of a pain, so I have built some php code to read the compiler.json in the Devices folders of the SDK to determine which devices are hybrid.

Now that it's all debugged and stable, adding a device to my app requires one more step to update the jungles 

I can fwd you my devicesUpdate PHP code  if you're interested

P.S. Even though I'm "not a programmer", now that I have become reasonably competent in python, I might migrate the code from PHP.

Alan.raceQs said:

My solution works but is a bit involved and relies on the user disabling touch on devices with both 5 buttons and touch - which i identify as "hybrid" , like the F7 etc,

I use jungles "exclude"  with hard coded value for each supported watch to identify "hybrid" 

Using annotations, in my code, if the device is hybrid and touch enabled, I Alert the user to switch off touch before the app will proceed. 

Since you've identified "hybrid" touch/button devices (i.e. 5-button watches with touch that can be optionally disabled), why not simply override touch events in the input delegate as suggested earlier in the thread, but only for hybrid devices? That way your device app can ignore all touches as desired, without having to ask the user to manually disable touch in their watch settings.

Alternatively, for hybrid devices, you could explicitly handle button events instead of rejecting touch events, but that would probably be a bit more work, and would lead to less shared code between the hybrid and "mandatory" touch watches.

FlowState said:

Since you've identified "hybrid" touch/button devices (i.e. 5-button watches with touch that can be optionally disabled), why not simply override touch events in the input delegate as suggested earlier in the thread, but only for hybrid devices? That way your device app can ignore all touches as desired, without having to ask the user to manually disable touch in their watch settings.

Yes, that was an early thought, but when "push came to shove", I found the separation of button and gesture inputs very hard to handle, so opted for my current approach.

I initially developed for the only Garmin device - the VA-HR which was touch only (yes, I know it has two buttons), Then Garmin brought out the 5-button F5, so I had to do some extensive UI mods where I mapped gestures to button presses in the input delegates. Then Garmin messed my code with the hybrid devices, so I thought  "sod it". Make the users disable touch on those devices. Much simpler programmatically and the users haven't complained. I wasn't prepared to return to the jungle of input delegates.

A case where I sacrificed some user experience in the name of  code stability and compatibility. 

P.S. even with your approach, I would still need jungles to identify the hybrid devices, but was able to incorporate the hybrid devices much more simply, since I already catered for either touch or button configurations in my code which already implemented "if touch  screen" in the input delegates.

Alan.raceQs said:

the VA-HR which was touch only (yes, I know it has two buttons)

Instead of "touch only" I would describe it as "mandatory touch".

Here's how I personally classify CIQ-era Garmin watches, as far as touch goes:

- no touch: e.g. older 5-button running, outdoor and multisport watches like Forerunner and Fenix which literally do not have a touchscreen. A tiny minority, such as 920XT, may have a different number of buttons

- mandatory touch: lifestyle watches such as vivoactive and venu series, as well as a couple of older Forerunners (like FR630). all of these watches have buttons, but touch is required for major functionality such as scrolling. you can lock/disable touch temporarily, but then you lose certain crucial functionality

- optional touch (you can do everything with the buttons): newer 5-button running, outdoor and multisport watches. all crucial functionality works with buttons, therefore touch can be disabled without crippling the watch. you could use these watches 24/7/365 with touch disabled

To me the reason 5-button watches lines have optional touch now is the same reason they never had mandatory touch in the first place (with a few exceptions): they're marketed at people who want to be able to use the watch without looking and/or who want to avoid phantom touches which mess up their activity. iow the ability the disable touch and retain full functionality is a selling point. That's also why touch is disabled for activities by default on these devices.

Alan.raceQs said:

I had to do some extensive UI mods where I mapped gestures to button presses in the input delegates

I'm not suggesting remapping touch gestures for 5-button watches, just ignoring them by implementing the various touch-related callbacks in the input delegate so they return true (which means the system won't perform the default action) and do nothing else.

That way you've effectively "disabled touch", as your app shouldn't respond to any touches.

FlowState said:

just ignoring them by implementing the various touch-related callbacks

That's not a "just", Its a major retrofit!

Alan.raceQs said:

That's not a "just", Its a major retrofit!

Ok, I'll take your word for it.

I don't know what your code looks like, but it seems to me you could add the following code to your existing input delegate to "disable touch" when appropriate:

var isHybrid = false; // set to true for hybrid devices

function onDrag(event) {
  if (isHybrid) {
    return true;
  }
  
  // if you already have existing code for this handler,
  // it goes here, otherwise:
  return false;
}

function onFlick(event) {
  if (isHybrid) {
    return true;
  }
  
  // if you already have existing code for this handler,
  // it goes here, otherwise:
  return false;
}

function onHold(event) {
  if (isHybrid) {
    return true;
  }
  
  // if you already have existing code for this handler,
  // it goes here, otherwise:
  return false;
}

function onSwipe(event) {
  if (isHybrid) {
    return true;
  }
  
  // if you already have existing code for this handler,
  // it goes here, otherwise:
  return false;
}

function onRelease(event) {
  if (isHybrid) {
    return true;
  }
  
  // if you already have existing code for this handler,
  // it goes here, otherwise:
  return false;
}

function onTap(event) {
  if (isHybrid) {
    return true;
  }
  
  // if you already have existing code for this handler,
  // it goes here, otherwise:
  return false;
}

I just disagree with your contention that it's not possible or practical to "disable touch" for a device app without asking the user to manually change a setting.

Maybe I'm missing something as far as the input delegate goes, tho. If so, my bad.

Are you aware of Toybox.System.DeviceSettings.isTouchScreen? This sounds like something you could use instead of the jungle generation. What I would try to do in similar UI design is something like:

1. have a variable: var isTouchEnabled as Boolean = false;

2. in the constructor I would read some property, like isTouchEnabled. By default it would be false.

3. In the app settings I would include a setting to enable/disable touch, and I would only display this if Toybox.System.DeviceSettings.isTouchScreen is true

4. If you also have xml based settings (used from mobile app or Garmin Express) then you can do 2 things:

a. ugly, but easy: have the same property setting with label like: enable touch screen (on relevant devices only)

b. nicer, but needs juggle generation: have 2 separate settings.xml in 2 directories and include the relevant one for each device (aka, exclude this setting fon devices that don't have touch screen)

In the code you only need to nest the relevant functionality in if (isTouchEnabled).

I know it's a lot of refactoring, etc, but this is the most user friendly way I can think of. In my apps I tend to do the opposite of what you wrote: I prefer user friendlyness even if it makes my code harder to maintain and necessary to generate jungle files (I use my python app for this: https://github.com/flocsy/garmin-dev-tools/blob/main/monkey-generator/monkey-generator.py though this is a very old version, I have much more features locally, but I don't have documentation for it...) I as a user hate when I see lots of settings that are impossible to use with my device...

Many thanks for your suggestions.

I'm happy with my current approach and would only consider a major change if it provided major support or enhancement benefits. 

flocsy🤠 said:

3. In the app settings I would include a setting to enable/disable touch, and I would only display this if Toybox.System.DeviceSettings.isTouchScreen is true

I'm configuring app settings in resources/settings.xml with a single file for all devices. How would you "only display this if Toybox.System.DeviceSettings.isTouchScreen is true"? 

Maybe my wording wasn't clear. Some apps do have settings that can be reached from the watch i.e by long pressing the menu button. There you could display different settings based on the actual watch's capabilities. If you don't have this kind of on-device settings, then you can do what I wrote in 4a or 4.b (from what you replied it looks you have 4.a at the moment, but since you already have the php script to generate the jungle file it wold not be very hard to also have 2 settings.xmls in 2 different directories and include the one relevant to each device, one for touch screen devices and one for non-touch-screen devices.)