It’s messy and not elegant. Trust me… 
But it works (more or less) like other Android scrollers do and this is what I’m stuck with until I can get scrollView to work in a similar fashion…
I still do not think I have gotten a clear answer to my original question though: Is scrollView supposed to work the way I have described it above? Anyone from Corona want to comment?
Hey runewinse,
The scrollview scroll mechanism is not perfect. We know that and we have it on the todo list.
Except for your points there’s also no capability of scrolling the scrollview in both directions at the same time ( diagonally, let’s say ).
About people accepting the level of performance, this is not performance related, but rather functionality finetuning - related. The scroll capabilities as they are at the moment fullfill their purpose, they just require that finetuning to match the native feeling ( including scrollbar stretching when limit caps are reached ).
Since it’s hard to me to provide you with a ETA on the scrolling refactor, and you say “you’re stuck” with the current implementation, i’ll kindly remind you that the Widget library is opensourced on Git, so you can just implement your code in the momentum scrolling module of our implementation. I know this is not the ideal case for you, but that’s the only quick option i see.
Hope this clarifies,
alex
Hi alex and thanks for replying!
From the users perspective it’s very hard to understand why these basic things are not in place. I don’t know what you guys are working on at the time, but as a paying customer I really wish you would concentrate on getting the basic stuff right before starting on new projects.
(Even if it hasn’t anything to do with scrollViews it’s the same thing applies to the textField, which forces the Corona user to do all kinds of manual hacks to make it work. It’s just not good enough. Sorry.)
You’re right, of course. “Performance” was a bad term. I should have written “feature set” or “behavior”. The point was that it doesn’t behave as any (non-Corona) scrolling app I have encountered and that makes it awkward.
This is, unfortunately, a couple of notches above my level.
But it’s no crisis on my part. My app works with my custom scroller code. But how about my next app? And other users wanting to use scrollView? C’mon guys! This isn’t rocket science 
I’m a mediocre coder (at best)
3 months ago I hadn’t heard of Corona or lua
I used maybe 5-6 hours to write that scrolling behaviour code
I’m not writing this to brag, quite the opposite. The point is: If I can manage to make a scroller that that works ok in a day, you should be able to do it in 30 minutes - typing with your nose. There is really no excuses for you not doing it. None!
Hey runewinse,
In my whole post, i did not make up any excuses. I just stated the facts. This discussion went on and on about other widget features ( see http://forums.coronalabs.com/topic/37217-list-of-open-widget-20-bugs-promised-features/ ). Same as with other features, when the internal planning will allow it, it will be fixed.
Thanks,
alex
Hi runewinse,
I have some problems with the scrolling of a table - have a feeling that it’s due to a bug in the inbuild scrolling in the table. I’d like to test how your scrolling code works in my project but I have no idea where and how to include it in my code.
You can see the problem I described under point 2 in this thread:
http://forums.coronalabs.com/topic/48876-tweaking-visual-options-of-the-tableview-is-it-a-bug/
and the code is there as well.
So where do I put your code? and what changes do I have to make?
Will appreciate any help with this.
Thanks.
keram
I am a developer myself (in a completely different area than handheld devices) and trust me, I know how frustrating prioritization from the above can be. I have no idea of how big your organisation is though. Maybe you are the one who decides these things for all I know…
BTW: I have not accused you personally for excusing anything. I apologize if it came out that way (English is not my native language).
What I meant was that there is no reason why Corona Labs should release something this seemingly halfhearted. Corona is being advertised a business app solution on the front of the Corona Labs web page for goodness sake! This is not consistent with how the widgets are prioritized (or have been prioritized until now). I only have the Basic 2014.2189. Maybe the other (updated) more expensive versions are much better.
But as a quick development platform for small “fullscreen” games, Corona SDK works beautifully
Hi, unfortunately I’m lousy at reading other peoples code (and I don’t have the time either). The only thing I can do is to add a slightly more readable version of my code and explain how it works a bit more.
Basically I do this:
Create a displayGroup (display.newGroup()) that contains everything that is scrolled
By modifying the y value of the displayGroup things will scroll
A touch handler takes care of the flick gesture detection
3a. When a finger is pressed to the screen (“began”) the scroll values are reset
3b. When the finger is moving, the three last finger positions (or rather movements) are saved
3c. When the finger leaves the screen, I calculate the mean finger movement from the last 3 movements. Based on this the scroll speed is caculated.
Hope this helps a bit. I don’t know why, but I am not allowed to add .lua files as an attachment on this forum. Therefore I have to add the main.lua directly into the post (and thus loose all formatting). Sorry about this, but I cannot find any other way to do it…
Good luck!
main.lua:
local MIN_MOVEMENT_THAT_RESULTS_IN_AUTOSCROLL = 3
local lastDeltaYArr = {0,0,0}
local deltaY=0
local lastMoveY=0
local scrollSpeedY=0
local yOffs = 0
– The maximum scroll value (height of the scroll content - height of screen)
local maxYOffs = -3000
local w = display.contentWidth
local h = display.contentHeight
local bgRect = display.newRect(w/2, h/2, w, h)
bgRect:setFillColor(0)
local mainGroup = display.newGroup()
local scrollImg = display.newImageRect(mainGroup, “image.png”, w/2, 4000 )
scrollImg.x = w/2
scrollImg.y = 2000
local touchHandler = function(e)
if (e.phase == “began”) then
scrollSpeedY = 0
deltaY = 0
lastMoveY = e.y
end
if (e.phase == “moved”) then
deltaY = e.y - lastMoveY – Delta Y = finger movement distance from last position
– Always save the three last finger movement distances
lastDeltaYArr[3] = lastDeltaYArr[2]
lastDeltaYArr[2] = lastDeltaYArr[1]
lastDeltaYArr[1] = deltaY
lastMoveY = e.y
mainGroup.y = math.min(0, yOffs + (e.y - e.yStart)) – Scroll value while finger still on screen
– Stop at end points of scrolling
if (mainGroup.y < maxYOffs) then mainGroup.y = maxYOffs end
if (mainGroup.y > 0) then mainGroup.y = 0 end
end
if (e.phase == “ended”) then
yOffs = mainGroup.y
– Get mean finger movement from the 3 last registered finger positions
deltaY = (lastDeltaYArr[1] + lastDeltaYArr[2] + lastDeltaYArr[3])/3
– Keep on scrolling only if finger movement is big enough
if (math.abs(deltaY) >= MIN_MOVEMENT_THAT_RESULTS_IN_AUTOSCROLL) then
scrollSpeedY = deltaY*2
else
scrollSpeedY = 0
end
end
return true
end
local frameRedrawListener = function(e)
– The frameDrawListener is called 30 times per second. The code in here
– is used to keep on scrolling after the user input has stopped
if (math.abs(scrollSpeedY) > 0.5) then
– Scroll the view according to the scroll speed
mainGroup.y = math.min(0, yOffs + scrollSpeedY)
yOffs = mainGroup.y
– Bottom check
if (mainGroup.y < maxYOffs) then
mainGroup.y = maxYOffs
scrollSpeedY = 0
end
– Top check
if (mainGroup.y >= 0) then
mainGroup.y = 0
scrollSpeedY = 0
end
– Reduce the scroll speed (scrolling should go slower and slower)
if (scrollSpeedY ~= 0) then
if (scrollSpeedY < 0) then
scrollSpeedY = scrollSpeedY + 1
else
scrollSpeedY = scrollSpeedY - 1
end
end
end
end
Runtime:addEventListener( “enterFrame”, frameRedrawListener )
Runtime:addEventListener( “touch”, touchHandler )
Hi runewinse,
Thanks for your reply and taking time to explain the details - I appreciate it. I’ll look more closely into that.
For your future posts, to add attachments to the posts you have to click on “More Reply Options” button just below the editing window. If lua files will not be accepted then you can zip it and it will work OK.
In order to keep the formatting of the code when posting wrap it in lua tags, but since these tags disappear from this post then click on the button “Post Formatting Tips” and check there.
keram
Hi,
Yes, zipping the .lua file worked ok. Incredible that a Corona forum won’t allow me to upload .lua files…
I’ve been experiencing the exact same flicking behavior on my scrollviews as shown in your video, and I’ve been trying to fix it in *my* code. Now, it would seem, the problem may be in the underlying scrollview widget itself.
I’ve looked at the code for the scrollview widget on github, but it’s not something I could easily jump in and make a change to. It would require a little time to go through it and really figure it out in order to do things in the best way.
So I, too, would love to see the scrollview get some more love.
One more thing:
The scroll capabilities as they are at the moment fullfill their purpose
It’s possible that people aren’t complaining much about the scrollview flicking behavior because, like me, they assumed the scrollview was working properly, and that the poor flicking behavior was actually caused by something they were doing wrong in their own code.
Dave
Well, according to the Corona staff it already works correctly or is “fulfilling its purpose”. With that kind of attitude I wouldn’t be too optimistic regarding any fix for this.
As I wrote above. If an idiot like me can make some modifications that makes the scrolling look as it should in such a short time , it’s obviously not the means but the will that is the problem with Corona.
It’s the same thing with the textField “widget”.
What do you mean by textField “widget”? Are you referring to native.newTextField() or something else?
Yes, I mean native.newTextField(). The problem, of course, is that it is NOT a widget, which leads to third party solutions like widget.newEditField from Widgets Town.
Two things make newTextField() almost unusable:
Since it’s native it doesn’t follow the usual rules/guidelines as other screen elements making things like scenes/transitions a nightmare
It’s not working in the Android emulator. I’m not talking just about the fact that you cannot enter text into it, but the fact that it’s replaced by a gray rectangle that will forever be visible above all other stuff in the emulator until you reset the app.
Have you considered how many hours are spent among your customers trying to get around this limitation?
I do not use Corona as a professional. I only (well, mostly) do it on my spare time. I make my living working for a company making Windows programs. When we consider a new feature (or bug fix) we always think:
A ) How many customer will be affected
B ) How much time will each customer save
If A x B is large enough, the feature should be considered.
I have no idea how many paying customers you have and how many of them are struggling with newTextField(), but I have a suspicion that it’s a LOT of us.
I have 2 questions that I cannot get out of my mind:
If it it’s so hard (for you) to develop a textEdit widget for paying customers, how can Widgets Town manage to make it for free?
If it isn’t that hard, why haven’t you done it?
I don’t get it.
There! Now I’ve gotten it out of my system! Thanks!
If anything, you can expect less going forward. Walter, in another thread openly indicated that the widget library is not something that will be supported and improved forever…
Hey @runewinse. As I develop each day more business apps, I can understand your deception and I would like to say that you are not alone seeing these bugs.
@ksan even did a good job by proactively creating a spreadsheet to concentrate all widget problems (since Corona doesn’t have a open bug tracker as other SDK have).
I just think that more experienced Corona devs are getting tired of complaining, so you as a new developer may think that the others are fine with what we have today.
The bottom line is: Corona is a great tool but as every tool it also has its flaws. Unfortunately business apps are not a priority and so we see a lot of these issues that we wouldn’t expect see due to their nature (some very basic and, as you said, not difficult to solve). Since Corona has a small team and have their own priorities, I wouldn’t wait for them to solve anything that is not related to the core.
What we, as developers, could do is to get together and solve the problem ourselves. I am open to discuss that possibility (I can create a specific topic about that). Let me your thoughts.
Disappointing, but not surprising… This trend has been going on for a while.
I don’t think I’m prepared to use much more money on Corona at this stage.
Yep, more than once I have suggested that they remove the bragging about Corona being a tool for creating business apps as it’s obviously not. For simple 2D games it’s a great tool.
My view is that this is Coronas responsibility.
This is like buying a new car without the door handle on the drivers side. Yes, it’s possible to get around the problem by entering through the passenger side door. Or somehow create a makeshift door handle yourself. But would you accept such a thing?
Good analogy but IMHO the situation is actually worse. its like buying a car with ‘pretend’ door handles that only work sometimes and not in the way you would expect door handles to work. To add to the insult, the manufacturer says “here… take the maintenance manual and tools needed, go fix your door handles yourself”…
I fully agree with you. I PAID for a product that was advertised as suitable for developing business apps at X10 faster rate as compared to native development. I paid for those darn door handles.
The problem is not just about widgets and text entry etc either. Look at the shortcomings of mapViews and webViews for instance. You can’t even embed a button into your mapView bubbles.
Finally, for me, perhaps the biggest issue is the lack of consistency of API between IOS & Android. If the promise of “Write once, deploy everywhere” is not going to prove to be the case then what is the point of using a cross platform SDK such as Corona?
Unfortunately, for me, the experience has been far from “write once, deploy everywhere”… I summarize my Corona SDK experience as “write once, debug everywhere”… I may still use it for the occasional game idea but I have made the decision not to use Corona SDK for anything beyond that.
Re: native.newTextField(). Corona’s graphics engine is in OpenGL. That lives in a canvas behind any native.* object. Corona SDK is built around OpenGL and that will likely not change in the future. You will not be able to put Corona display objects on top of native.* objects.
But there is good news. You can insert native.* objects into display groups and any moving around of the display group, changing the group’s alpha property should now work. I’ve been monkeying around with the Business App Sample and I’ve taken the widget.newTextField() code that we put into a tutorial, removed all the syncing code and inserted the native.newTextField into the display group for the widget.newTextField(). I moved both it and the mapView into the scene:create() function to allow Composer to transition them on and off screen and manage them accordingly. This all seems to work nicely. I had both crossFade and slideLeft transitions working on the scene.
Yes, we all know that by now, but the problem isn’t that the native.newTextField() is working the way it is. The problem is that there isn’t a (built-in) widget.* version of it.
I’m not 100% sure what you have done here, but I’m very happy that something is being done
For us complete morons it’s not easy to understand why something like widget.newTextField() isn’t included in the widget library in the first place. Hopefully you’ll soon add it so that the life of your customers gets e bit easier! Thanks in advance!