Animation bug when moving items

[MFlisar]

I made a short screencast of the problem and appended it as a gif, here's a short description:

My ChipsLayoutManager looks like following:

ChipsLayoutManager chipsLayoutManager = ChipsLayoutManager.newBuilder(getActivity())
            .setChildGravity(Gravity.TOP)
            .setScrollingEnabled(true)
            .setGravityResolver(new IChildGravityResolver() {
                @Override
                public int getItemGravity(int position) {
                    return Gravity.CENTER;
                }
            })
            .build();

I add my chips (they have wrap_content as width) and my two headers to distinct between selected and not selected items (the headers have a width of match_parent so they automatically take the space of a row). Selecting an item does just move it under the selected items header and notifies the adapter about this move.

[Oleg-Beloy]

This problem is based on constraints of this layout type. Each concrete item location is based on all previous item locations. That's a basis. Layout manager keeps in memory only visible views on screen & some views for caching purpose. All other views are recycled. So when you scroll to upper items, LM tries to layout previous views based on current view locations and on cached locations of that appearing views. In case moving/inserting/deleting in somewhere above of visible bounds, it means that you have changed a basement of views, the cache of locations become invalidated. To accurately display changes layout manager would recalculate new locations for all views above visible bounds. I decided that it isn't optimal, coz you could have any amount of views. How does it work now? According to current algorithm LM just leaves it as is, scroll above with placing views based on available view locations (it can't be so accurate) and performs normalization to natural view locations when user scrolled to changed position in basement. That normalization looks like animation displayed in your gif ( without it it would look like blink change or like wrong item locations if counted from start) . I hope i've explained it clearly. I think it is possible to perform some optimizations here. For example, it won't affect performance much if LM recalculated all view locations for example if changes had made in above 50 positions as maximum. I'll think about it. But for greater distance it will be left as is.

[MFlisar]

I get the idea behind it and understand the problem. It's an accepatable solution, just wanted to inform you about this behaviour...

I could think of an alternative solution though, the basic idea is following:

Precondition

• Chips are layed out the same in landscape and portrait, otherwise it won't work after screen rotation
• Always start a layout at top position

Idea

• While scrolling down, fill a cache with the widths of the views
• Reuse this calculated widths for laying out the items correctly
• you could even cache "calculated" row breaks (those must be cleared on rotation of course) => this helps otpimising calculations, as rows without changes can be ignored for calculations of other rows
• With this information, you could make fast recalculations when moving views that are fully correct

Get the idea? What do you think about it? Do I oversee something?

[Oleg-Beloy]

Yes, i've got an idea. Currently i have a cache of row endings to properly place views on scrolling up and it should be possible to recalculate it with your suggested cache of widths. It shouldn't take much memory or processor time with limited cache. About screen rotation.. With implemented recalculation feature It should be also possible to use it due to orientation change. This enhancement may take valuable amount of time