ScrollView is missing a phase! :(

[kcdev]

Okay, so big apologies in advance [IF] I am mistaken, but unfortunately that doesn’t seem to be the case…

So if I understand correctly ScrollView has 3 phases:
 

–event.phase == “began”: Triggered when the user starts/begins dragging

–event.phase == “moved”: Triggered when the user is actively dragging

–event.phase == “ended”: Triggered when the user released and thereby stopped dragging

Now, we notice that ScrollView comes with a variable “friction”, whose default value is 0.973.

(Sorry for the rant, but I am obliged to write this: The name “friction” is a HORRIBLE, HORRIBLE choice for the variable. The name “friction” implies that, if the value is increased, the movement will be slowed down because, well…friction was increased LOL   But NO, if you increase “friction”, friction is DECREASED. I mean seriously. Shame on whoever came up with that idea. The variable should be called “sliding” or something to that effect. Or better yet, make friction increase when you increase “friction”.)

Sorry for the rant. Going back to my point, whenever you set “friction” to a non-zero value (or don’t set the value at all), there will be sliding. 

So my question/critique is this: Isn’t there a (very important) phase dedicated for when the ScrollView object stops sliding missing?   The absence of said phase (unnecessarily) complicates my life. It was a shock to learn that Corona doesn’t support this. 

My pseudo “solution” (which really isn’t a solution at all) was to make “friction = 0”, there by guaranteeing the coincidence of “ended” and the missing phase, which I will call “stopped”.

However, this is not visually pleasing, and damages the user experience in my opinion.

Again, I apologize if the phase I am talking about does exist, but I could not find anything.

On the other hand, it if doesn’t, which seems to be the case, I strongly, STRONGLY urge the Corona staff to add a fourth phase, because it is NECESSARY, and it will make so many Corona developers, including myself, happy.

Thank you.
KC

[dirindon]

There is no such phase its duplicate of my post,  (more or less).

My solution is to on enterFrame detect scrollView X contentPosition and calculate delta from it, so you know both, slowing down and sliding effect stopped. For further questions (or how to code it), feel free to ask me.

[steve262]

Whilst friction is probably a misleading name for it, moaning about that might lead to it being changed and everyone who’s ever used a scrollview with a non default friction getting confused as to why the behaviour has changed when they update corona…

If you were to download the open source version of widgets from github you could change widget_momentumScrolling.lua to add such a feature.
A “stopped” on the flick is easy to add, something like (at line 485ish)

 -- If there is a listener specified, dispatch the event if view.\_listener then local newEvent = { phase = "stopped", target = view, } view.\_listener( newEvent ) end

To do the same if they scroll it past the end and bounce back though you’ll want to modify handleSnapBackVertical and handleSnapBackHorizontal to have a callback on the completion of the transition they use to move it back to the limit to do similar.

[kcdev]

@dirindon 

There is no such phase its duplicate of my post,  (more or less).

Okay, so there isn’t such a phase after all. Just what I thought…Sorry about missing your post–I don’t read every post to check for duplicates…In any case, looks like I’m not the only one who noticed this.

 

My solution is to on enterFrame detect scrollView X contentPosition and calculate delta from it, so you know both, slowing down and sliding effect stopped.

So you are basically saying I can calculate where it will stop? While I have no doubts this will work, calculating delta from the contentPosition will just make my code really ugly and practically unreadable. Not to mention there are many ways something can easily go wrong when doing calculations at run time. I’m not sure if it is worth it…

@steve262
“Whilst friction is probably a misleading name for it, moaning about that might lead to it being changed and everyone who’s ever used a scrollview with a non default friction getting confused as to why the behaviour has changed when they update corona…”

You are right in that the behavior will change if the they make friction increase when you increase the variable “friction”.  I didn’t consider this. However, they can simply change the name of the variable, which will avoid this dilemma. Either way, I highly doubt they will change the name and/or behavior.

 

If you were to download the open source version of widgets from github you could change widget_momentumScrolling.lua to add such a feature.

Again, I am sure this will work if done correctly, but using third party code is the last thing I want to do…

As dirindon said, the phase I am looking for doesn’t exist, which means this is no simple and elegant solution. But at least just knowing this is better than not.

I am not sure what I will do, but I thank all of you who replied for your suggestions.

Regards,

[steve262]

Both suggestions are essentially the same, I’m just doing it inside the widget library.
 
Every frame it multiplies the velocity by the friction, checks to see if it’s below 0.01 and stops it if it is (that’s the point I’m suggesting inserting the above code) then adjusts the position by the new velocity*time since last frame.
 
I don’t see that there’s a lot of difference between doing that and doing the same in a runtime enterframe listener like dirindon is, though calculating the change in position that way will give you the event you want for *all* instances of it stopping in one place without having to care about why it was moving which is probably less work for more benefit.

[bjsorrentino]

Hi all,

You bring up good points. I may be able to roll this into the existing ScrollView framework so it’s easier for you all to use. But first, can you field ideas on what this phase would best be named? My inclination is to call it “stopped”, but I could be convinced to call it something else. Note that this would probably be a phase added to the existing “listener” function defined in the ScrollView constructor.

Brent

[kcdev]

@Brent Sorrentino

WOW! I’m impressed. Looks like Corona staff actually read posts and know what is in the Corona community’s interest. This is not something to be taken for granted.
 

But first, can you field ideas on what this phase would best be named? My inclination is to call it “stopped”, but I could be convinced to call it something else.

If you paid close attention to my original post, on the 16th line I wrote:
 

 …thereby guaranteeing the coincidence of “ended” and the missing phase, which I will call “stopped”.

Looks like we’re in agreement as to what the variable should be called  :D  I think “stopped” is a both a simple and enlightening name for the variable (unlike “friction” which is a totally misleading name), and illustrates what the variable does well.

KC

[bjsorrentino]

Hey KC,

What can I say… I have a soft spot for framework code and physics.

I already worked up some initial code for this. It needs some thorough testing on our side but hopefully it can be rolled into builds before too long. FYI, it would be a phase name of “stopped”, tied into the main widget listener, and it would be triggered when motion (obviously) comes to a stop… but not when you (the user) touches/drags the view then releases, for which there is already the “ended” phase (I don’t think a “stopped” phase would make sense in that case anyway). It would also occur if you drag beyond the limits of the ScrollView and then release, when that “spring back” effect happens (it would happen when that completes).

Brent

[kcdev]

@Brent Sorrentino

Sounds good! Looking forward to the next build 

[bjsorrentino]

Hi guys,

Go ahead and grab daily build 2016.2980 or later. This feature should be working for you now, for both ScrollView and TableView. The daily docs are updated on this point too:

https://docs.coronalabs.com/daily/api/library/widget/newScrollView.html#listener-optional

Brent

[dirindon]

There is no such phase its duplicate of my post,  (more or less).

My solution is to on enterFrame detect scrollView X contentPosition and calculate delta from it, so you know both, slowing down and sliding effect stopped. For further questions (or how to code it), feel free to ask me.

[steve262]

Whilst friction is probably a misleading name for it, moaning about that might lead to it being changed and everyone who’s ever used a scrollview with a non default friction getting confused as to why the behaviour has changed when they update corona…

If you were to download the open source version of widgets from github you could change widget_momentumScrolling.lua to add such a feature.
A “stopped” on the flick is easy to add, something like (at line 485ish)

 -- If there is a listener specified, dispatch the event if view.\_listener then local newEvent = { phase = "stopped", target = view, } view.\_listener( newEvent ) end

To do the same if they scroll it past the end and bounce back though you’ll want to modify handleSnapBackVertical and handleSnapBackHorizontal to have a callback on the completion of the transition they use to move it back to the limit to do similar.

[kcdev]

@dirindon 

There is no such phase its duplicate of my post,  (more or less).

Okay, so there isn’t such a phase after all. Just what I thought…Sorry about missing your post–I don’t read every post to check for duplicates…In any case, looks like I’m not the only one who noticed this.

 

My solution is to on enterFrame detect scrollView X contentPosition and calculate delta from it, so you know both, slowing down and sliding effect stopped.

So you are basically saying I can calculate where it will stop? While I have no doubts this will work, calculating delta from the contentPosition will just make my code really ugly and practically unreadable. Not to mention there are many ways something can easily go wrong when doing calculations at run time. I’m not sure if it is worth it…

@steve262
“Whilst friction is probably a misleading name for it, moaning about that might lead to it being changed and everyone who’s ever used a scrollview with a non default friction getting confused as to why the behaviour has changed when they update corona…”

You are right in that the behavior will change if the they make friction increase when you increase the variable “friction”.  I didn’t consider this. However, they can simply change the name of the variable, which will avoid this dilemma. Either way, I highly doubt they will change the name and/or behavior.

 

If you were to download the open source version of widgets from github you could change widget_momentumScrolling.lua to add such a feature.

Again, I am sure this will work if done correctly, but using third party code is the last thing I want to do…

As dirindon said, the phase I am looking for doesn’t exist, which means this is no simple and elegant solution. But at least just knowing this is better than not.

I am not sure what I will do, but I thank all of you who replied for your suggestions.

Regards,

[steve262]

Both suggestions are essentially the same, I’m just doing it inside the widget library.
 
Every frame it multiplies the velocity by the friction, checks to see if it’s below 0.01 and stops it if it is (that’s the point I’m suggesting inserting the above code) then adjusts the position by the new velocity*time since last frame.
 
I don’t see that there’s a lot of difference between doing that and doing the same in a runtime enterframe listener like dirindon is, though calculating the change in position that way will give you the event you want for *all* instances of it stopping in one place without having to care about why it was moving which is probably less work for more benefit.

[bjsorrentino]

Hi all,

You bring up good points. I may be able to roll this into the existing ScrollView framework so it’s easier for you all to use. But first, can you field ideas on what this phase would best be named? My inclination is to call it “stopped”, but I could be convinced to call it something else. Note that this would probably be a phase added to the existing “listener” function defined in the ScrollView constructor.

Brent

[kcdev]

@Brent Sorrentino

WOW! I’m impressed. Looks like Corona staff actually read posts and know what is in the Corona community’s interest. This is not something to be taken for granted.
 

But first, can you field ideas on what this phase would best be named? My inclination is to call it “stopped”, but I could be convinced to call it something else.

If you paid close attention to my original post, on the 16th line I wrote:
 

 …thereby guaranteeing the coincidence of “ended” and the missing phase, which I will call “stopped”.

Looks like we’re in agreement as to what the variable should be called  :D  I think “stopped” is a both a simple and enlightening name for the variable (unlike “friction” which is a totally misleading name), and illustrates what the variable does well.

KC

[bjsorrentino]

Hey KC,

What can I say… I have a soft spot for framework code and physics.

I already worked up some initial code for this. It needs some thorough testing on our side but hopefully it can be rolled into builds before too long. FYI, it would be a phase name of “stopped”, tied into the main widget listener, and it would be triggered when motion (obviously) comes to a stop… but not when you (the user) touches/drags the view then releases, for which there is already the “ended” phase (I don’t think a “stopped” phase would make sense in that case anyway). It would also occur if you drag beyond the limits of the ScrollView and then release, when that “spring back” effect happens (it would happen when that completes).

Brent

[kcdev]

@Brent Sorrentino

Sounds good! Looking forward to the next build 

[bjsorrentino]

Hi guys,

Go ahead and grab daily build 2016.2980 or later. This feature should be working for you now, for both ScrollView and TableView. The daily docs are updated on this point too:

https://docs.coronalabs.com/daily/api/library/widget/newScrollView.html#listener-optional

Brent