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

Header reappears on top when returning to fragment that has been scrolled down. #59

Open
stshelton opened this issue Mar 24, 2018 · 8 comments
Labels

Comments

@stshelton
Copy link

Currently, in my project, I have a fragment that has a scrollable layout that hosts a header image and a recycler view. When scrolling down and hitting a button at the bottom of the recycler view a new fragment is added to the stack. When returning to the original fragment that has the scrollable layout the header appears at the top even though the recycler view is still scrolled to the bottom. What would be the best way to retain the headers state so when returning to the fragment the header is not shown if the recycler view is currently scrolled all the way down?

@noties
Copy link
Owner

noties commented Mar 24, 2018

Hey! If state is not restored automatically, you can manually save scrollY (scrollableLayout.getScrollY()) value to a Bundle (onSaveInstanceState) and then just apply it when you need it with scrollableLayout.setScrollY(). Although I think it peculiar that RecyclerView saves state correctly... Can you check if your added to a backstack fragment goes through onDestroyView phase?

@stshelton
Copy link
Author

Yea the fragment hosting the scrollable layout hits the onDestroyView when returning to it from the fragment above it.

@noties
Copy link
Owner

noties commented Mar 25, 2018

Well, if fragment went through onDestroyView but not onSaveInstanceState you can try to leverage the fragment's arguments functionality. So, onDestroyView you save scrollY:

getArguments().putInt("key", scrollableLayout.getScrollY());

and in onViewCreated (after everything has been initialized, like scroll listeners, etc):

scrollableLayout.setScrollY(getArguments().getInt("key", 0));

@stshelton
Copy link
Author

I tried that and doesn't seem to be working. My onViewCreated looks like this

int y = getArguments().getInt("key", 0);
Log.i(TAG, "onViewCreated: " + y);
mScrollableLayout.setScrollY(y);
Log.i(TAG, "onViewCreated: " + mScrollableLayout.getScrollY());

the first log is showing 545 but when I print the scrollableLayout.getScrollY() it prints 0.

@noties
Copy link
Owner

noties commented Mar 27, 2018

Hm. Are you by any chance using autoMaxScroll feature? If yes, then before applying previously saved scroll you need to wait for the ScrollableLayout to be laid out (internally ScrollableLayout uses OnGlobalLayoutListener). Just to verify, can you also log scrollableLayout.getMaxScrollY() before applying setScrollY()?

@stshelton
Copy link
Author

Yea im using autoMaxScroll and logging getMaxScrollY() before applying setScrollY() is showing 0 too.

@noties
Copy link
Owner

noties commented Mar 27, 2018

Yeah, so I thought. I think there is a bug with state restoration in ScrollableLayout. Meanwhile, you could something like that:

@Override
public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);
    
    final ScrollableLayout scrollableLayout = view.findViewById(R.id.scrollable_layout);
    // your initialization
    
    final int savedScrollY = getArguments().getInt("key");
    if (savedScrollY > 0) {
        scrollableLayout.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
            @Override
            public void onGlobalLayout() {
                // here we might validate that scrollableLayout was called first
                if (scrollableLayout.getMaxScrollY() > 0) {
                    scrollableLayout.setScrollY(savedScrollY);
                    scrollableLayout.getViewTreeObserver().removeOnGlobalLayoutListener(this);
                }
            }
        });
    }
}

@noties noties added the bug label Mar 27, 2018
@stshelton
Copy link
Author

Cool, it Worked!! Thanks for the quick response.

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

No branches or pull requests

2 participants