Currently, a fast swap within the same list will make bulk animations, meaning that 3 or 4 items will move all at once together instead of one by one concurrently.

ItemTouchHelper has a concurrent animation style which looks more responsive and fluid. We need to investigate ways to make our animations like this.

Make an example that looks and feels as close as possible to Trello's board to demonstrate the power and ease of the library and also to show that it will look better than Trello's.

Make sure we also have another example or two to show that the library is not only for Trello clones, but is versatile and customizable while being performant and functional

Swapping ViewHolders across lists using the default ItemAnimator makes the alpha of the newly added VH be 1.0, thus making it visible for a few frames before we can force it to be transparent again.

We need to solve this using a custom ItemAnimator that will be aware of when swaps are happening in order to efficiently and correctly animate things as expected.

The main goal is to trick the user into thinking they are dragging the ViewHolder. They are actually dragging a Shadow and the ViewHolder has become transparent but must remain that way until the drag has ended no matter where it is dragged.

A custom ItemAnimator that can be notified of swaps and behave correctly would be the ideal solution to this.

This mainly includes scroll speed because callers can currently disable and enable it fairly easily by using BaseRecyclerView.isScrollEnabled.

But scroll speed is somewhat fixed and different implementations may require different speeds, however this may not be as easy as just adding a multiplier to current scrollBy(...) calls. I may be wrong though!

When switching between modes, animations can be sluggish or behave in an incorrect jarring way.

Look into a fix for this.

This is not a high priority because this feature in itself is a nice to have and can technically be done by the user, so on the off chance we have no luck solving it, we can leave it up to the user to do.

Weird behavior happens when a swap is made with the 0th child of a BoardList. This includes swaps in the same list and swaps across the list.

This is likely related to LinearLayoutManager's strange behavior and relation with the 0th child of the RecyclerView, read this for more.

I still don't fully know what's causing these and will have to investigate further

ItemDragShadow doesn't always animate back to the correct return point.
This is because of timings and stuff to do with ItemAnimator. We tell ItemDragShadow to return to the points of the target ViewHolder but when those are calculated they were mid-animation, hence ItemDragShadow will return to mid-animation points instead of actual points.

We need to make sure we compute the return point's values at the correct time or at least compensate for this animation stuff somehow.

A good idea would be to do it last second, basically in onReleaseDrag, but this too can be prone to the mid-animation issue.
Another thing would be to compute them before a swap is made at all but confirmed that it will be made.

Currently the touch point detection algorithm used when drag is started checks only if the touch point is over a valid ViewHolder that is not the currently dragging one, it ignores margins and empty areas. See the gif below:

This needs to be changed so that when the touch point is in the bounds of (margin and padding included) another ViewHolder that is different from itself, it should trigger the swap. This means if callers have VHs with large margins or padding the swaps will still work as expected.

This also means that when a drag is happening over an empty area of a BoardList, like if it is empty or has few items (and thus an empty space at the bottom) swaps won't be triggered until the touch point is over another ViewHolder. This an old issue from Waqti that was hackily solved quite poorly before but we need to properly solve this here in a scalable manner.