Is this really how the scrollView is supposed to work?

Getting Started Newbie Questions
#68

Hi Rob, and thanks for looking into this.

Sure, I can repeat what I wrote in the original post. It’s actually very limited and has only to do with how the scrollView reacts to the swiping motion when the users scrolls.

 

  • Constant scroll speed (not controlled by gesture speed)
    I want the scrolling to be fast or slow dependent on the "flick gesture speed! As it is now, the scroll speed is completely independent of the gesture speed, making the scrollView feeling very clumsy.
     
  • No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture
    Sometimes the user drags the (list) scrollView a bit back and forth, before he wants to scroll a bit further. This isn’t possible now, because such a movement just cancels the scroll.
     
  • No scrolling if the finger is moved longer than a certain distance before flicking
    If the user wants to scroll fast, it’s natural to make a larger flick motion, but if the motion is over a certain distance, the scrollView also seems to cancel the scroll!
     
  • Occasional bugging - the scrollView scrolls in the wrong direction
    This happens maybe one of 30 times I try to scroll and it is not caused by reaching the limits of the scroll area.

I have made a small video showing some of these issues: VIDEO (sorry about the lousy resolution, it’s youtube)

 

 

 

I have not made a bug case out of this, because I have gotten the impression from Corona that there are no bugs. This is just how it works.

#69

Constant scroll speed (not controlled by gesture speed)

This seems like a feature request to me. I looked and I don’t see anything at http://feedback.coronalabs.com for this.

No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture

No scrolling if the finger is moved longer than a certain distance before flicking

Occasional bugging - the scrollView scrolls in the wrong direction

These feels like bugs, have you reported them? I looked through the open bug cases and didn’t see anything similar.

Please file a bug report for each of these separately.

We need a simple project that shows the problem. Likely our widget demo might do the trick. If it does show it, just zip it up and use that. If not, we need a main.lua, config.lua, build.settings and any resources to build and run the app to see the problem.  Please put that in a .zip file and use the Report a Bug link at the top.

For the feature request, please use the Feedback link I added above.

Thanks

Rob

#70

OK, now I’ve at least added the feature request and bug report. Let’s see what happens :slight_smile:

#71

How do I follow my bug reports or know if any of them are recognized as bugs?

#72

We normally ask you to post your case ID’s (came to you in an email) back here so when questions come up, we can look them up. The other thing you can do is look at the daily builds page and see what’s changed. There is a link on there that reads:

A summary of what’s happened since the last Public Release is available here.

You can look through those release notes and see when widget things get fixed. However I don’t believe there have been any widget fixes since 4/5. And I know the feature request has not been worked on yet.

It’s also useful to post the feature request URL back to the forum thread as well so others can learn about it and vote it up.

Rob

#73

Ok, so there’s no automatic mechanism for giving the bug reporter a feedback that the bug is being fixed/worked on. We have to go through the lists manually?

Maybe I should add this as a feature request… :slight_smile:

#74

This thread is about to have a 2 year anniversary and still the scroll view is still the same? Even if it could have been so much better with 2 hours of work on your part? I have a hard time believing this…

CORONA: Are you seriously suggesting that each developer should write their own scrollView code?

Is that what you suggest? Then I have a suggestion. Remove the whole thing from the widget library. It is exactly as someone wrote in this thread. Experienced Corona users have given up on it and is writing their own code.

#75

Watching Corona develop and evolve is exciting, and watching the progress with tvOS, Windows, and OS X apps is pretty neat. But I still feel like there are a few more basic things that need some love. Maybe now that the staff is bigger some of these things can be focused on.

I think the widget library could be moved to a proper plugin, *if* the plugin system worked better, so that (like most other libraries in other languages), I could get a specific version of that plugin.  I’ve beat that drum as much as I can, I think, in another forum post, but it would be really helpful because then if your app is working great with version 2 of the widget library, you could just keep using that one.  When version 3 is released, you could try it, and if it has breaking changes for your app, you could just continue using version 2.  It would allow the Corona staff the freedom to completely overhaul things without worrying about breaking apps everywhere.

But the plugin system still doesn’t support that, as far as I know, which means you’re still better off having your own version of the widget library (in my opinion).

Dave

#76

This is concerning.  I have a project in the pipeline that needs a scrollview and I had assumed these issues were fixed by now.  Does anyone have a third party solution?

#77

Can you provide a list of specifically what’s wrong with ScrollView (and bug caseID’s would be great)? I’ll look into the issues. As far as I know there are edge cases that we could address, but the core ScrollView is working for many people.

#78

Hi Rob, and thanks for looking into this.

Sure, I can repeat what I wrote in the original post. It’s actually very limited and has only to do with how the scrollView reacts to the swiping motion when the users scrolls.

 

  • Constant scroll speed (not controlled by gesture speed)
    I want the scrolling to be fast or slow dependent on the "flick gesture speed! As it is now, the scroll speed is completely independent of the gesture speed, making the scrollView feeling very clumsy.
     
  • No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture
    Sometimes the user drags the (list) scrollView a bit back and forth, before he wants to scroll a bit further. This isn’t possible now, because such a movement just cancels the scroll.
     
  • No scrolling if the finger is moved longer than a certain distance before flicking
    If the user wants to scroll fast, it’s natural to make a larger flick motion, but if the motion is over a certain distance, the scrollView also seems to cancel the scroll!
     
  • Occasional bugging - the scrollView scrolls in the wrong direction
    This happens maybe one of 30 times I try to scroll and it is not caused by reaching the limits of the scroll area.

I have made a small video showing some of these issues: VIDEO (sorry about the lousy resolution, it’s youtube)

 

 

 

I have not made a bug case out of this, because I have gotten the impression from Corona that there are no bugs. This is just how it works.

#79

Constant scroll speed (not controlled by gesture speed)

This seems like a feature request to me. I looked and I don’t see anything at http://feedback.coronalabs.com for this.

No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture

No scrolling if the finger is moved longer than a certain distance before flicking

Occasional bugging - the scrollView scrolls in the wrong direction

These feels like bugs, have you reported them? I looked through the open bug cases and didn’t see anything similar.

Please file a bug report for each of these separately.

We need a simple project that shows the problem. Likely our widget demo might do the trick. If it does show it, just zip it up and use that. If not, we need a main.lua, config.lua, build.settings and any resources to build and run the app to see the problem.  Please put that in a .zip file and use the Report a Bug link at the top.

For the feature request, please use the Feedback link I added above.

Thanks

Rob

#80

OK, now I’ve at least added the feature request and bug report. Let’s see what happens :slight_smile:

#81

How do I follow my bug reports or know if any of them are recognized as bugs?

#82

We normally ask you to post your case ID’s (came to you in an email) back here so when questions come up, we can look them up. The other thing you can do is look at the daily builds page and see what’s changed. There is a link on there that reads:

A summary of what’s happened since the last Public Release is available here.

You can look through those release notes and see when widget things get fixed. However I don’t believe there have been any widget fixes since 4/5. And I know the feature request has not been worked on yet.

It’s also useful to post the feature request URL back to the forum thread as well so others can learn about it and vote it up.

Rob

#83

Ok, so there’s no automatic mechanism for giving the bug reporter a feedback that the bug is being fixed/worked on. We have to go through the lists manually?

Maybe I should add this as a feature request… :slight_smile:

#84

Any updates on this? As of the latest build (2016.2951) many of the issues runewinse mentioned as still present.

I realize trying to mimick native momentum scrolling can be a challenge and a time burner, but this is so fundamental to all mobile applications that it’s hard to turn a blind eye. It’s important to get it right. Just try scrolling a long list in a native iOS/Android app and then try doing it on Tradebase (http://www.tradebaseapp.com) or Recent News ( http://www.recent.io). It’s a night and day difference and immediately noticeable to anyone using it. You can argue that it’s good enough, but “good enough” in this case really takes a bite out of user experience and that’s a problem.

#85

Hey, don’t be so hard on them! After all it’s just been 2-3 years…

And look at all those glorious Ads / Monetization thingies they have added in the meantime!

#86

Any updates on this? As of the latest build (2016.2951) many of the issues runewinse mentioned as still present.

I realize trying to mimick native momentum scrolling can be a challenge and a time burner, but this is so fundamental to all mobile applications that it’s hard to turn a blind eye. It’s important to get it right. Just try scrolling a long list in a native iOS/Android app and then try doing it on Tradebase (http://www.tradebaseapp.com) or Recent News ( http://www.recent.io). It’s a night and day difference and immediately noticeable to anyone using it. You can argue that it’s good enough, but “good enough” in this case really takes a bite out of user experience and that’s a problem.

#87

Hey, don’t be so hard on them! After all it’s just been 2-3 years…

And look at all those glorious Ads / Monetization thingies they have added in the meantime!