So I noticed a small *issue with the scrolling of table views.
It seems if you scroll down, then scroll up without lifting up your finger, then when you let go the table won’t keep scrolling, it will stop immediately. It also happens vice versa (scroll up then down).
This is sort of an unintuitive and frustrating quirk which is not present in native iOS table views. Is there a fix for this (I know I could change widget.lua myself but it seems like this wouldn’t be the desired default behavior)?
I’m having the same problem. Except it’s not having to do with starting and changing scroll directions. I notice the menu does not continue to scroll once it’s “flicked” like the tableView and scrollView widget documentation pages describe. Adjusting the friction doesn’t seem to change anything.
Even doing something rather simple like this reproduces it for me.
local widget = require( "widget" ) local tableView = widget.newTableView() for i = 1, 400 do -- Insert a row into the tableView tableView:insertRow{} endIs that your actual code? You’re not setting any parameters in the tableView creation. I don’t know if that should cause any issues, but it’s pretty unusual to not set creator properties.
Rob
Hi Rob,
I agree, and that’s not the code I’m legitimately trying to use. I’m just pointing out that even creating a basic table view with “n” number of rows still has a sticky scroll.
What I mean is in other apps is when a user is scrolling and they raise their finger, it initiates that flick that should continue moving the menu objects (provided there’s a slippery friction attribute set). But in using both the core widget’s tableView and scrollView objects, they just stop moving the MOMENT you lift your finger–regardless of whatever the friction constant is.
Is this expected behavior?
Hi, I’ve been facing this problem too, just exactly as hi5grant describes it.
Is anyone looking into fixing this? Should we request to open an issue somehow?
This spoils the UX and creates an unprofessional vibe on the app/game in general.
scrollview’s momentum code works acceptably for “quick flicks”, but not for long drags followed by a flick. for example, try as one gesture: drag up slowly, then pause briefly, then flick - won’t do what you “expect”. (particularly if your flick is in the reverse direction, as the momemtum code “latches on” to an orthogonal direction, so you need a release/re-press to flick once already moving) it’s a challenging bit of code to unravel, as other widgets derive from it, so it may be easier to reinvent your own if your use is specific enough to warrant it.
I’m having the same problem. Except it’s not having to do with starting and changing scroll directions. I notice the menu does not continue to scroll once it’s “flicked” like the tableView and scrollView widget documentation pages describe. Adjusting the friction doesn’t seem to change anything.
Even doing something rather simple like this reproduces it for me.
local widget = require( "widget" ) local tableView = widget.newTableView() for i = 1, 400 do -- Insert a row into the tableView tableView:insertRow{} endIs that your actual code? You’re not setting any parameters in the tableView creation. I don’t know if that should cause any issues, but it’s pretty unusual to not set creator properties.
Rob
Hi Rob,
I agree, and that’s not the code I’m legitimately trying to use. I’m just pointing out that even creating a basic table view with “n” number of rows still has a sticky scroll.
What I mean is in other apps is when a user is scrolling and they raise their finger, it initiates that flick that should continue moving the menu objects (provided there’s a slippery friction attribute set). But in using both the core widget’s tableView and scrollView objects, they just stop moving the MOMENT you lift your finger–regardless of whatever the friction constant is.
Is this expected behavior?
Hi, I’ve been facing this problem too, just exactly as hi5grant describes it.
Is anyone looking into fixing this? Should we request to open an issue somehow?
This spoils the UX and creates an unprofessional vibe on the app/game in general.
scrollview’s momentum code works acceptably for “quick flicks”, but not for long drags followed by a flick. for example, try as one gesture: drag up slowly, then pause briefly, then flick - won’t do what you “expect”. (particularly if your flick is in the reverse direction, as the momemtum code “latches on” to an orthogonal direction, so you need a release/re-press to flick once already moving) it’s a challenging bit of code to unravel, as other widgets derive from it, so it may be easier to reinvent your own if your use is specific enough to warrant it.