mTouchSlop is too short. Gives problems on vertical scrolling

[franciscojunior]

Hi all!

I'm palying with this excellent library. But I faced a little problem: If I have a scrollable view, the vertical scroll doesn't work very well. It stops in the middle of the process which removes the inertial feeling of the scroll.

I could get it to work better by increasing the value of mTouchSlop in 40 in the following line:

private void init() {
    mLoadedViews = new LinkedList<View>();
    mScroller = new Scroller(getContext());
    final ViewConfiguration configuration = ViewConfiguration
            .get(getContext());
    mTouchSlop = configuration.getScaledTouchSlop() + 40;  <===
    mMaximumVelocity = configuration.getScaledMaximumFlingVelocity();
}

I also noticed that if I have a listview the vertical scroll doesn't give this problem. So, I wonder why with the list view it works ok but with a scrollable view it doesn't.

Please, let me know if you need more info.

[pakerfeldt]

I'm guessing the difference between a list view and the scrollable view of yours is that the list view consumes the touch event when the user has scrolled enough on the Y-axis, but with your scrollable view that event is never consumed so the ViewFlow consumes it whenever you happen to pass the mTouchSlop value on the X-axis.

Can you try implementing onTouchEvent and make sure the event is consumed as soon as you believe the user is scrolling vertically?

I don't believe setting the mTouchSlop is the right way to go.

[franciscojunior]

Hmmmmm, I see.

I thought I could get a simpler approach to that. I mean, I may be missing something here, but if I'm understanding it right, I would need to add a motion controller to my view just to intercept the motion when it is scrolling vertically. I mean, I loved the approach of just getting my views as they are in xml and just inflate them inside my Adapter getView(). I used the viewflow-example as a template, so I may be missing some other ways of using viewflow. As the Scrollable view defined in my xml already gives me the scroll, I didn't want to have to play with scrolling code. I'd like to have that abstracted away from my code. Or, maybe you could make the mTouchSlop property or something which gives control over it accessible to my code.

I thought about the mTouchSlop because I noticed that the only problem is that when I'm scrolling vertically, viewflow sometimes thinks I'm scrolling horizontally and stops the vertical scroll.

I think that if I wanted to make more complex gestures in my view, I really would need to override gesture consumption of viewflow, but I just wanted a simple vertical scroll and would like to use it with less code as possible. Sorry if I'm looking like a too lazy guy.

Thanks in advance

[pakerfeldt]

I would love a solution where the user of this library didn't have to think about anything when it comes to scrolling. I just don't know how that would be possible. But it might very well be, if so I need to be pointed in the right direction. Just changing mTouchSlop doesn't seem like a long-lasting solution.

I'm not entirely sure what you mean by "a motion controller" but "all you have to do" is to implement the onTouchEvent in your ScrollView and make sure the event is consumed when the user scrolls vertically. I don't have time to test this myself at this very moment, but if you're unable to find a suitable solution for you I might try this out later. You could perhaps look at the source code for the ListView. Then again, if there is an ultimate solution for this problem on the viewflow end I would definitely implement it, I just need to know how.

[franciscojunior]

By motion controller I mean I will need another class to keep the state of the motion and consume the events.

Ok, I could make this class, but I think that the best way would be a "helper class" which could be used by many other layouts which had this "problem". I mean, it would be best if it could be used in any layout based on Scrollview xml layouts regardless of the place it is used. If this is the case, I think the best place for this helper class would be inside flowview itself. So, for example, if I need to add a layout with a scrollview inside it and I already know that scrollviews have this "problem", I could make something like:

in my adapter:

public View getView(int position, View convertView, ViewGroup parent) { switch (position) { case 0: if(convertView == null) { convertView = mInflater.inflate(R.layout.cryptcarddetails, null); convertView = ViewFlowHelpers.wrapScrollView(convertView); <=== } break; } return convertView; }

Or something like that. My point is that the wrapScrollView method would take care of this "problem" with scrollviews. Either by setting up another touchevent handler or doing a special handling of this view which has a scrollview. I say specifically scrollviews because as I said before, with ListViews I didn't have this type of problem. I didn't test other views to see if they show the same problem too.

I think this would be much easier for the library user.

I hope it is more understandable now. If you have any other question, please, let me know.

[pakerfeldt]

I get what you're after. I wonder how the list view handles this issue. Can you have a horizontal scroll view inside a list view item? If you would like to write such utility I will pull it. Otherwise, I'll dig into this issue as soon as I get some time.

[franciscojunior]

I didn't test adding a horizontal scroll view in a list view item. I'll see if I can come up with something about that and I'll let you know. If you get something, please let me know so I can test it.

Again, thanks for such awesome library!

[yjukaku]

I think an XML attribute for sensitivity (which would take a multiplier to mTouchSlop) might not be too much to ask. Why are you against this idea?

[pakerfeldt]

I'm not against the idea. But I was hoping for a solution where it wasn't needed at all. You can't change the sensitivity on a list view, right? But I guess it's best if we added such attribute to solve this issue.

[yjukaku]

Yeah, I agree with you that it would break from standard Android practice. I guess I was just being selfish because I didn't want to extend my scrollview :)