• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Help Accidental touch input due to sudden GUI change

J

JohnSmith1989

Lurker
Hi,

I am trying to search for Android method which handles the following situation:

When there is a sudden change in the GUI, during a user input, it might be interpreted incorrectly. For example, when user provides touch input and screen orientation changes suddenly, it might cause the device to interpret the input for the second (new orientation). However, the user was actually providing input for the first orientation.

In another example, when the user is providing input on a GUI, and another event occurs, causing GUI to change, such as incoming call, an alert, etc. the user might accidentally provide input to the new event, while intending to interact with the initial GUI, that was being displayed prior to the new incoming event.

Can Android handle such a scenario? In other words, does it consider some amount of threshold time after GUI change, to decide (interpret correctly) if the user input was for first or new GUI?

Thanks in advance!
John
 
I don't know how you would handle such a thing. Leaving aside how you might implement it (something would have to keep track of the location of previous GUI elements for some period of time, which in the case of something like an incoming call would include a change of app rather than just a re-orientation within the same app), how can the device "know" whether you meant to press a button that was no longer there or the one that has just appeared? If an incoming call arrives while I'm using the phone and I press the "accept" button I certainly don't want it to open some other app because the system is assuming that I wasn't yet reacting to the new event but really meant to press whatever was previously at that point on the screen. I think that type of thing would be a greater annoyance, and cause more confusion, than it reacting to whatever the GUI is at the moment the touch is registered (even if that has just changed).
 
Hadron said:
I don't know how you would handle such a thing. Leaving aside how you might implement it (something would have to keep track of the location of previous GUI elements for some period of time, which in the case of something like an incoming call would include a change of app rather than just a re-orientation within the same app), how can the device "know" whether you meant to press a button that was no longer there or the one that has just appeared? If an incoming call arrives while I'm using the phone and I press the "accept" button I certainly don't want it to open some other app because the system is assuming that I wasn't yet reacting to the new event but really meant to press whatever was previously at that point on the screen. I think that type of thing would be a greater annoyance, and cause more confusion, than it reacting to whatever the GUI is at the moment the touch is registered (even if that has just changed).
Click to expand...

Thank you for your response. I believe it might be possible to implement it in the device by associating a threshold time after change of GUI. Based on the user touch input below or above the threshold, the device could interpret it as input to first GUI or 2nd GUI. Of course, the threshold time could perhaps be fraction of a second.
Hence, if the user's touch input occurs after threshold period expires (from the time orientation change occurred/ new GUI appeared), the user input could be interpreted for the 2nd GUI. However, if user input occurred before expiry of threshold time from the GUI change, it should correspond to input for the first GUI.
 
I considered that, and thought it was implicit in my answer. But what threshold time? If you make it less than 0.1s then I expect you are safe, since humans don't react fast enough for any touch then to be based on the new GUI. But as we often initiate actions further in advance than that that won't be enough to eliminate your annoyance. But once you start making it longer you will start to get a mixture of the two types of mis-tap (aiming for old GUI and hitting current, and aiming for current GUI and hitting old), and I'm sure that different people will be affected differently and will have different tolerances for this, so what might be optimal for one person will be very annoying for another. Speaking personally, I'd find an incorrect response based on something that's no longer there far more irritating than one where I can see what's happened.

You also have to consider how to handle the possibility of a second GUI change within whatever time you set (prevent the change? Or accept there may be mis-hits in this time?). And what elements the system applies to: it can't be everything, because to pick an obvious example it would make games unplayable, but I think this would need some serious analysis as I can imagine there's a lot of potential for unintended consequences. And if this is to go beyond just a launcher responding to an orientation change then it would have to be a system-level feature, which means that only Google could implement it.

It's an interesting idea, and I suspect I could have fun trying to analyse all of the possible implications. But I'd want a slider so I could set my own latency, and including the option to turn it off completely by setting it to zero.
 
The other option might be to disable all tap response with the initiation of any aspect change or overlay until complete so it prevented all taps, thus removing the possibility of accidental ones.
 
You must log in or register to reply here.
Back
Top Bottom