substrate
substrate copied to clipboard
gluonhq
ListView (and CharmListView) list items do not show as selected when touched on a Samsung phone.
Expected Behavior
Selecting a list item typically renders the chosen item as a different color than the others in the list to acknowledge the User has selected it (touched it).
Current Behavior
Testing on a Pixel XL phone, what is considered a natural touch (tap) of a list item on the screen does show the expected result. The item is colored light gray as its state of being selected. However, on a Samsung S9 phone, only occasionally does the list item selected acknowledge by color change that it has been selected.
Attached are two log files produced while testing with two different phones. Denoted here is the time entry in the log when trying to select a list item.
fiftystates_Samsung.log
- 17:28:22 -> Successful list item selection attempt
- 17:28:31 -> Successful list item selection attempt
- 17:28:41 -> Unsuccessful list item selection attempt
- 17:28:57 -> Unsuccessful list item selection attempt
- 17:29:23 -> Unsuccessful list item selection attempt
- 17:29:32 -> Successful list item selection attempt
fiftystates_Pixel.log
- 17:43:16 -> Successful list item selection attempt
- 17:43:31 -> Successful list item selection attempt
- 17:43:42 -> Successful list item selection attempt
- 17:43:52 -> Successful list item selection attempt
Steps to Reproduce
Use the Gluon Samples app "FiftyStates" on a Samsung device. Try selecting and reselecting any of the CharmListView's list items. You may see 5, 10, maybe 20 selections (touches / taps) before an item shows itself as selected. The next attempt after the successful one may work, or maybe many more selection attempts before successful again.
Note - during testing to prepare for this bug report submission, it became more evident that the lightest, fastest attempts to touch the screen on the Samsung when selecting an item would more often show as a successful selection. But what a reasonable person may consider a natural touch more typically resulted in an unsuccessful selection on the Samsung. By reasonable, I mean the same touch behavior that is successful on the Pixel.
Your Environment
Testing was done with a Debian Linux machine, connecting first a Samsung phone, then a Pixel XL phone.
fiftystates_Samsung.log fiftystates_Pixel.log
Thank you for the detailed issue and logs.
If you check the touch points for each event:
fiftystates_Samsung.log
-
17:28:31 -> Successful list item selection attempt Pushing TouchState.Point[id=0,x=179,y=194]] Pushing TouchState.Point[id=0,x=179,y=194]] Pushing TouchState.Point[id=0,x=179,y=194]] Pushing TouchState.Point[id=0,x=179,y=194]] Set MouseState[x=179,y=194,wheel=0,buttonsPressed=IntSet[]]
-
17:28:41 -> Unsuccessful list item selection attempt Pushing TouchState.Point[id=0,x=156,y=120] Pushing TouchState.Point[id=0,x=156,y=120] Pushing TouchState.Point[id=0,x=156,y=120] Pushing TouchState.Point[id=0,x=155,y=120] Pushing TouchState.Point[id=0,x=155,y=119] Pushing TouchState.Point[id=0,x=155,y=119] Set MouseState[x=155,y=119,wheel=0,buttonsPressed=IntSet[]]
So the ability to keep your touch still and don't move the finger gives a successful pressed event, but with the tiniest movement of the finger, it gives a drag or scroll event.
To get more sensibility on Android we use this property:
-Dmonocle.input.touchRadius=1
(default is 20) but that might too small. If you add to the plugin in your pom a higher value (2 or even 4):
<runtimeArgs>
<arg>-Dmonocle.input.touchRadius=2</arg>
</runtimeArgs>
can you test if you get more steady pressed events and therefore item selections?
I tested with a change of value for setting monocle.input.touchRadius=2. I also tested with values 4, 8, 16, 20, 40, and 80. I don't believe what I observed was a gradual change in ratio of successful selections. It still seemed sporadic as I kept tapping around on the list. What I did observe is that, regardless of the value for that setting, if the X,Y coordinates of MouseEvent changed even by just plus or minus 1, then the selection event was unsuccessful. Only when the start and end state of MouseEvent X, Y values stayed the same was the selection successful.
Consider the following two excerpts from the debug log during testing.
- Below in the first unsucessful selection, MouseState x=135,y=310 changed to MouseState x=135,y=311.
- In the second successful selection, MouseState x=91,y=223 remained as MouseState x=91,y=223 after the logging of the touch event was complete.
If I understand correctly, adjusting the value of monocle.input.touchRadius was an expectation of changing the probability of a touch event resulting in a mouse movement change of X,Y coordinate values. If this change in X,Y can't be helped, can we make it so that a negligible change of coordinate values when touching a ListView is regarded as no change in mouse (drag or scroll) movement to the ListView?
Unsuccessful Selection Event
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] V/GraalActivity(14695): Activity, get touch event, pcount = 1
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, pass to native Graal layer...
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, passed to native Graal layer...
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Pushing TouchState[1,TouchState.Point[id=0,x=135,y=310]] to TouchPipeline[SmallMove]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Applying SmallMove to TouchState[1,TouchState.Point[id=0,x=135,y=310]]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set TouchState[1,TouchState.Point[id=0,x=135,y=310]]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set MouseState[x=135,y=310,wheel=0,buttonsPressed=IntSet[212]]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] V/GraalActivity(14695): Activity, get touch event, pcount = 1
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, pass to native Graal layer...
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, passed to native Graal layer...
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] V/GraalActivity(14695): Activity, get touch event, pcount = 1
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, pass to native Graal layer...
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Pushing TouchState[1,TouchState.Point[id=0,x=135,y=311]] to TouchPipeline[SmallMove]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Applying SmallMove to TouchState[1,TouchState.Point[id=0,x=135,y=311]]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set TouchState[1,TouchState.Point[id=0,x=135,y=311]]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, passed to native Graal layer...
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): don't add points, primary = -1
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set MouseState[x=135,y=311,wheel=0,buttonsPressed=IntSet[212]]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Pushing TouchState[0] to TouchPipeline[SmallMove]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Applying SmallMove to TouchState[0]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set TouchState[0]
[Fri Aug 13 08:00:55 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set MouseState[x=135,y=311,wheel=0,buttonsPressed=IntSet[]]
Successful Selection Event
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] V/GraalActivity(14695): Activity, get touch event, pcount = 1
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, pass to native Graal layer...
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, passed to native Graal layer...
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Pushing TouchState[1,TouchState.Point[id=0,x=91,y=223]] to TouchPipeline[SmallMove]
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Applying SmallMove to TouchState[1,TouchState.Point[id=0,x=91,y=223]]
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set TouchState[1,TouchState.Point[id=0,x=91,y=223]]
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set MouseState[x=91,y=223,wheel=0,buttonsPressed=IntSet[212]]
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] V/GraalActivity(14695): Activity, get touch event, pcount = 1
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, pass to native Graal layer...
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): don't add points, primary = -1
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] E/GraalGluon(14695): Native Dalvik layer got touch event, passed to native Graal layer...
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Pushing TouchState[0] to TouchPipeline[SmallMove]
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Applying SmallMove to TouchState[0]
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set TouchState[0]
[Fri Aug 13 08:01:11 MST 2021][INFO] [SUB] D/GraalCompiled(14695): traceEvent: Set MouseState[x=91,y=223,wheel=0,buttonsPressed=IntSet[]]
Update
Good news! Changing the value of monocle.input.touchRadius was what mattered. I was not seeing the changes because of how I was testing. With my phone tethered to my laptop, I started the app as so:
mvn -Pandroid clean gluonfx:build gluonfx:nativerun
But then I switched testing to actually build the APK file, then manually copy it over to the phone and clean install it.
mvn -Pandroid clean gluonfx:build gluonfx:package
This is when the change of value with monocle.input.touchRadius was obvious. Starting at value 20, I began reducing the value to determine how low it can be before seeing unsuccessful list item selection attempts. At about value 3, my Samsung phone was occasionally not acknowledging a selection. But at value 4, it seems consistent to me.
I've since been taught that, had I tested my tethered phone as follows, I would have also seen the value changes:
mvn -Pandroid gluonfx:link gluonfx:package gluonfx:install gluonfx:nativerun
Earlier, I said selection was problematic on Samsung S9 but not Pixel XL. Actually, the Pixel also was not always acknowledging every list item selection either. But, because I was comparing it to Samsung, I tolerated the occasional fail. With monocle.input.touchRadius=4 on the Pixel also, it too now behaves more ideally to every list item selection. Consider changing the source code default value to 4 instead of 1.
Great, good to know. Are you seeing any side effects because of this “high” value now (4 vs 1)? Like selecting one item instead of the next one if you tap close enough to the cell border?
Only when I try to tap directly on the line between two list items, whereby the outcome is uncertain to me, do I see a list item selected that I couldn't have anticipated. Clicking as close as I can to the line, on either side, without trying to touch it, I still repeatedly see the list item selected which I would anticipate should be the selected one.
UPDATE I've noticed a trade-off to incrementing the setting above 1. When scrolling a list, I see the scroll, not as a smooth gliding action, but as a choppy series of the list taking quick, micro leaps.
The widgets seem to wait for my moving finger to traverse the screen's point location by a few pixels before they move along with it and, when they do, the display leaps to that new change in location. Then again, the list is still as I continue sliding my touch across the screen before they update with another micro leap.
I don't think updating this setting above 1 is a mistake, but perhaps this trade-off should be documented. For any app developer that wants to support their Samsung audience, allowing some UX compromise of lists that don't seamlessly glide when scrolled may be better than an app that won't allow list item selections. So, which way to decide is a case-by-case decision, whatever the prioritized app features may be in each separate app instance.