How to choose if it should create the views around? about gravitysnaphelper HOT 10 CLOSED

I don't understand the question, sorry.
What are you trying to achieve? You want the sample to contain lots of nested recyclerviews?

from gravitysnaphelper.

Which part exactly isn't understood?

I didn't ask about nested RecyclerViews, though this can be a case of heavy pages.

from gravitysnaphelper.

I meant the title: "How to choose if it should create the views around?"

This sample has 4 nested RecyclerViews. Each one has a different SnapHelper. You mentioned the onBindViewHolder just gets called once in this case, which is ok, although it doesn't reflect the case in real life apps. So, what's the problem here?

EDIT:
Maybe this is useful: https://medium.com/google-developers/recyclerview-prefetch-c2f269075710

from gravitysnaphelper.

onBindViewHolder Should be called not just for the current one, but also for those near it.
That's why I mentioned RecyclerView and ViewPager.
If you use this library to be used on the case of a full screen cell, for some reason, it doesn't load those near it.
This was written some time ago, so maybe I was mistakenly writing this on the wrong repo.

from gravitysnaphelper.

Closing due to inactivity. This is question was out of scope for this library.

from gravitysnaphelper.

@rubensousa I don't remember what it was about, but reading what I wrote, I think it was about the case that each cell would take whole screen (or just the whole width for horizontal scrolling), like a ViewPager, and that the issue is that it doesn't work like ViewPager.
This means that there is an issue, that the views around don't get updated till you actually see a part of them.
This is bad, because in the case of loading the images from the Internet for the cells, you will always first see a placeholder because it takes time to load each.
It's also bad because the creation of the near cells should be performed now, and not later.

from gravitysnaphelper.

Yes, I finally understood what you meant, since I faced this exact issue a few months ago. My fix was extending LinearLayoutManager and just return more extra space in getExtraLayoutSpace: https://developer.android.com/reference/android/support/v7/widget/LinearLayoutManager.html#getExtraLayoutSpace(android.support.v7.widget.RecyclerView.State). I think we need to use this as an alternative to ViewPager's setOffscreenPageLimit: https://developer.android.com/reference/android/support/v4/view/ViewPager.html#setOffscreenPageLimit(int)

This also happens in the original LinearSnapHelper and that's why I decided to close this, since the fix involves configuring the RecyclerView and its LayoutManager

from gravitysnaphelper.

Can you please show how to do it?
How to force that at least one item from each side of the current one would be loaded?

from gravitysnaphelper.

I'm not sure if it's the best solution, but this was my workaround:

public class ViewPagerLinearLayoutManager extends LinearLayoutManager {

    private int offScreenPageLimit = 1;

    public ViewPagerLinearLayoutManager(Context context) {
        super(context);
    }

    public ViewPagerLinearLayoutManager(Context context, int orientation, boolean reverseLayout) {
        super(context, orientation, reverseLayout);
    }

    public void setOffscreenPageLimit(int extraPages) {
        this.offScreenPageLimit = extraPages;
    }

    @Override
    protected int getExtraLayoutSpace(RecyclerView.State state) {
        return super.getExtraLayoutSpace(state) * offScreenPageLimit;
    }
}

If you come up with another solution, please let me know :)

from gravitysnaphelper.

I see. Thank you.

from gravitysnaphelper.