Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The refresh view remains #2

Closed
tomoyuki28jp opened this issue Feb 22, 2011 · 7 comments
Closed

The refresh view remains #2

tomoyuki28jp opened this issue Feb 22, 2011 · 7 comments

Comments

@tomoyuki28jp
Copy link

If we scroll fast once from the bottom and it stops on the top, the refresh view remain and nothing will happen.

@tomoyuki28jp
Copy link
Author

I found another issue. If there is only one row in ListView, the refresh view never disappear. Is this expected behavior?

@johannilsson
Copy link
Owner

When reaching the top it should bounce back. That's a bug.

Second issue I'm not sure, I do think that's expected at least that is how the Twitter implementation works which is our current reference.

@mattg1981
Copy link

Add the following code to onScroll(AbsListView, int, int, int) within PullToRefreshListView.java to fix the issue of the refresh view remaining visibly at the top after a fling scroll:

if ( mCurrentScrollState == SCROLL_STATE_TOUCH_SCROLL && mRefreshState != REFRESHING )     {
..
}

// add this code

    else if ( mCurrentScrollState == SCROLL_STATE_FLING && firstVisibleItem == 0 ) {
        scrollListTo( mRefreshViewHeight , 1250 );
    }

EDIT: refined the code a little to take out unneeded statements

@MantaMay
Copy link

You can use the SCROLL_STATE_FLING to detect when a fling has occurred, and set a flag that you reset once SCROLL_STATE_FLING has ended. Place this in the onScroll as a conditional, and you will fix this issue. Also you will probably want to impement the same logic in a onTrackBallEvent and setOnKeyListener to make sure the user only fires this with a scroll rather d-pad or track ball.

To make this Android 2.1 compatible use setSelection(int) instead of smoothScrollBy. If you still want a smooth scrolling you can take the time to dispatch a TouchEvent, but this can get ugly. Sorry I haven't provided any code, if you have troubles implementing this yourself let me know and I'll finish it and upload the code.

EDIT: whoops, someone beat me to the SCROLL_STATE_FLING, must've missed this, should've refreshed comments before posting.

@johannilsson
Copy link
Owner

@mattg1981, @MantaMay Thank you, seems like SCROLL_STATE_FLING solves the problem with the view being visible. Will wrap it up during the weekend.

@MantaMay I've done some test with TouchEvent to simulate a smooth scroll, but never got it to behave as good as I wanted so I gave up and just used scrollBy if smoothScrollBy does not exist. Think it works fairly good but smooth scroll would be preferred though.

@mattg1981
Copy link

Instead of editing my previous post, I thought this was worthy of a new one. To make it feel even more like the Twitter Pull-To-Refresh (ie, on a fling, it is not visible at all when hitting the top, it is only visible when pulling the list down), make these adjustments:

if ( mCurrentScrollState == SCROLL_STATE_TOUCH_SCROLL && mRefreshState != REFRESHING )     {
    mRefreshView.setVisibility( View.VISIBLE );
    ...
}
else if ( mCurrentScrollState == SCROLL_STATE_FLING && firstVisibleItem == 0 ) {
        mRefreshView.setVisibility( View.GONE );
        scrollListTo( mRefreshViewHeight , 1250 );
}

@johannilsson
Copy link
Owner

Hide the pull to fresh label in a fling, its now only visible when pulling the list down. Thank you mattg1981 and MantaMay for this. Closed by f69140d.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants