Yes that is the bit that needs changing IMHO. I’m trying to get a “list of changes”.
There are three behaviours that should happen if a tableview (or scrollview) is being scrolled:
touch with no finger movement should halt scrolling
flick in direction of scroll should add momentum
flick in opposite direction should reverse the scroll
and 3. seem OK it is 2. that doesn’t work as other native apps do and that needs some work from Corona I think.
You also asked for added acceleration on subsequent flicks, which is not there today, but I’m a little divided if that is neccessary.
What I’d like to see is more specialized widgets instead of these large ones which should contain every feature.
Even if not considering current swipe issues, the scroll quality itself is sub par, and in 2017 that is not good enough.
i agree with both, scrollview and tableview needs a huge upgrade, lite version would be great and we could add ourselves more code if we need it, but the core base code should be smooth as butter, and right now, it is not.
sgs, the 3 behaviours a tableview should do are correct, but 2 and 3 are not scrolling correctly not only number 3 have problems. if you swipe really fast to scroll a huge amount of data…like an calendar (which is what i’m kinda of doing) swiping same direction or swiping opposite direction. sometimes will stop the scrolling, which fails completely the propose of fast swiping. if you do that in the google calendar it will work 100% of the times. no mather the speed or times you swipe it will always respond to your swipe. don’t know what project you want. any will have this problem. just copy and paste corona example and add 1000 items and test it. problem 2 and 3 will be there with the simplest tableview possible.
anaqim, didn’t understand what you want me to test. but you get what the problem is, so I’m not alone on this boat.
anyone have a working version of an example with open source corona scrollView?
i found out that if you press the screen a little time on the same spot (±half a second or more) and try to swipe up or down it will move a little the scrollView then it will stop. it will not create that acceleration process. that doesn’t happen on google calender. i’m studying corona scrollView code, the code is pretty well made. i believe the math formula behind the movement can be improved. i wish i could “play” a little with some variables i have in mind.
the code i’m testing is:
local scrollView = widget.newScrollView( { top = 0, left = 0, width = display.contentWidth, height = display.contentHeight, scrollWidth = display.contentWidth, scrollHeight = display.contentHeight, listener = scrollListener } ) for i=1, 120 do local options={ text=" It's the end of the world as we know it and I feel fine.\n", width=display.contentWidth, y=i\*50, } local text=display.newText(options) text.anchorX=0 text.anchorY=0 text:setFillColor(0,0,0,1) scrollView:insert(text) endyeah I see the same behaviour in my app using tabelView, which is logical as they both use the required widget_momentumScrolling.
though that is probably to prevent momentum scrolling when using the finger to move the scroll from one position to another, ie not flicking
the formula is directly associated with the time you are pressing the finger (time you are pressing and the distance). if you press a long time and move you will fail all the time the scroll.
they didn’t have in account that you can have a still press and move it. old people or babies tend to do that more offen. usually people that are not good with technology. i remembered i had this problem on my scroll menu code and had to correct it. I guess Corona never thought about it. Google scroll doesn’t have this problem also.
youre right, the more modern way to do it is to stop scroll momentum with a touch.
Hi again,
the only thing i can think of (since I am working with scrollView myself these days, is that the view contain some element that makes it longer or wider and that can make it “snap back” a little. I found that text objects are more likely to do this if you specify text height.
scrolling really fast isnt, from what I see, possible unless you change core script parameters.
thanks anaqim, for your input,
i’m testing right now myself the output values of the scrollview, and discovering that it is real the negative acceleration.
printing this 2 variables
print(scrollView.\_view.\_velocity, scrollView.\_view.\_lastTime)
ive this result:
16:51:28.603 Scroll view was touched
16:51:28.603 0 8643.1
16:51:28.603 ____________
16:51:28.603 0 8643.1
16:51:28.603 ____________
16:51:28.613 0 8643.1
16:51:28.613 ____________
16:51:28.623 0 8643.1
16:51:28.623 ____________
16:51:28.633 -0.080033281166426 8643.1
16:51:28.633 ____________
16:51:28.644 -0.080033281166426 8643.1
16:51:28.644 ____________
16:51:28.644 -0.080033281166426 8643.1
16:51:28.644 ____________
16:51:28.644 0.080033281166426 10118.1
16:51:28.644 Scroll view was released
16:51:28.644 ____________
16:51:29.548 Scroll view was touched
16:51:29.548 0 10986.5
16:51:29.548 ____________
16:51:29.548 0 10986.5
16:51:29.548 ____________
16:51:29.559 -0.067802182464593 10986.5
16:51:29.559 ____________
16:51:29.570 -0.067802182464593 10986.5
16:51:29.570 ____________
16:51:29.580 -0.067802182464593 10986.5
16:51:29.580 ____________
16:51:29.580 -1.5 10986.5
16:51:29.580 ____________
16:51:29.590 -1.5 10986.5
16:51:29.590 ____________
16:51:29.590 -1.5 11062.2
16:51:29.590 Scroll view was released
16:51:29.590 ____________
16:51:29.621 ____________
16:51:30.043 ____________
16:51:30.366 Scroll view was touched
16:51:30.366 0 11096.3
16:51:30.366 ____________
16:51:30.377 0 11096.3
16:51:30.377 ____________
16:51:30.387 0 11096.3
16:51:30.387 ____________
16:51:30.387 0 11096.3
16:51:30.387 ____________
16:51:30.397 0 11096.3
16:51:30.397 ____________
16:51:30.407 -1.5 11096.3
16:51:30.407 ____________
16:51:30.418 -1.5 11096.3
16:51:30.418 ____________
16:51:30.418 -1.5 11096.3
16:51:30.418 ____________
16:51:30.428 -1.5 11096.3
16:51:30.428 ____________
16:51:30.438 -1.5 11096.3
16:51:30.438 ____________
16:51:30.448 1.5 11096.3
16:51:30.448 ____________
16:51:30.448 1.5 11918.2
16:51:30.448 Scroll view was released
16:51:30.448 ____________
16:51:31.079 ____________
16:51:31.445 Scroll view was touched
16:51:31.445 0 12550.7
16:51:31.445 ____________
16:51:31.456 0 12550.7
16:51:31.456 ____________
16:51:31.466 0 12550.7
16:51:31.466 ____________
16:51:31.466 0 12550.7
16:51:31.466 ____________
16:51:31.477 -0.0063262313590543 12550.7
16:51:31.477 ____________
16:51:31.487 -0.0063262313590543 12550.7
16:51:31.487 ____________
16:51:31.487 -0.0063262313590543 12958.2
16:51:31.487 Scroll view was released
the last touch he didn’t make a move and the variable “scrollView._view._lastTime” is the highest. on all the other touches the higher the last time is higher the velocity with the -1.5 limit. but when it passed a limit the speed gone to almost 0.
EDIT: “_lastTime” gives me always incremental value, so wrong variable to test here…back to try other variables (testing _delta right now)
i tried to scroll like there is no tomorrow on my app but I dont get any slap back behaviour.
I’d make a brand new project and a default scrollView to check if this applies only to your specific apps scroll, or not.
Nothing quite like playing bug detective, is it? 
hehe, thanks for you help. but don’t look for a slap back. it’s more than a stop when it should scroll in the max velocite. some times before that stop it goes back a pixel or 2. but the real problem is swipping fast and the scroll moves while your finger is down and stops when you release. it should go at max speed. in simulator is very hard to do this. on device on ipad is very easy to do this.
what it seems is that corona limited the velocity (_maxVelocity) and didn’t limit the acceleration (i could not find this variable).
if they did not limit this function and just made an exponential formula things can go wrong.
oh yeah i know what you mean, like a fast swipe simply failing like its too fast for the code, easy to recreate.
I’m testing on a samsung pad 
i suspect this is because of the underlying code requiring a certain time window to calculate distance vs time, and that the swipe is just too fast for the code. The only solution would be to shorten that required time window, but thats going to the widget script and beyond my lua skills.
I have created my own scrolling code when i was coding a little in game maker pro, since they dont have a scroll widget or function. Took me a nasty 3-4 weeks to get it working well so yeah the mechanics behind is known.
If I recall right, I think the calculation windows was optimal at somewhere beyween 4 and 6 ms when running at 60 fps. if only 1 or 2 ms off, i’d get this kind of behaviour under extreme swiping conditions.
yes, anaqim exactly that.
the one scroll menu i’ve made took me more than a week also to build from scratch, so i know the pain is to create a new one. it would be better if we could solve it with the existing code (scrollView).
edit: the problem can’t be in “just to fast for the code”, because my scroll menu does not have this problem. and is the same client i’m making this new app and he wants a “feel” like the other.
if you print the variables while you swipe, you know the system is registering them because it shows those variables. my wonder is that since like you said distance vs time gives a huge result that is higher than the max int value. in that case it will give a negative score and the result is this.
side note: the first time i found a max int problem was playing tetris back in the days, when i played more than i should, and broke the 32768 limit and went to -32767…still didn’t gave up and went again to 32xxx and stoped there
guess I will have to build myself a new scrollView…
Hey carlos,
To my big embarrasment I just discovered that newTableView will do all i need it to do.
Rob made a decent tutorial on it as well.
If you are making a vertical scroll, this might work for you.
It is highly configurable and has a maxVelocity parameter too.
https://coronalabs.com/blog/2014/03/04/tutorial-advanced-tableview-tactics/
thanks anaqim for the input,
I went to scrollView to evade the slow code of tableview (it creates and deletes a lot. I don’t need that in this project). I used a lot of tableviews but had more problems with it than what it supposed to do, I gave up on them in most of the cases. I still use them time to time. it has a lot of features I don’t need in simple scrolls, it’s overkill. that’s why scrollView exist. I went to a simple scrollview with all my items, but even that I guess I cant use because of this problem (negative acceleration).
I’ve more than 100 self-made functions that help me on my daily base code, one more won’t hurt.
I just keep being frustrated with half baked functions corona provide. vibration function is another joke function…well let’s move on. crying about it won’t solve the problem. I’m old school I’m used to heavy labor. I’m from the time to do a simple append on a string we had to build 5 line code (or more), now is just “…” and done. I can’t complain about that.
regards,
Carlos.
hi again, damn now you got me worried about the performance.
i am considering a move to B4A but am a little on the fence as its a give and take as always
HI Carlos,
I just implemented it in my app, and it works perfectly on my mid end android device.
Maybe my list is less complicated than yours. On screen is shows up to 25 rows and each row has 3 elements, including an image.
Wont be moving on after all then :)