Swipe remove with in-place undo and "leave-behind"

[mattiasbe]

Request for enhancement: Swipe remove with in-place undo and "leave-behind" The UndoHelper is great (snackbar undo of removal of item), but Gmail and other apps have a swipe to remove/archive/whatever that instead of showing a snackbar with UNDO shows what happened "in-place" where that item was along with providing an UNDO action "in-place" where the item used to be. Furthermore, starting the swipe reveals an icon indicating what will happen if swiping further (and in some implementations also colors the background accordingly, red for deleting etc).

See also the material design guidelines ragarding "leave-behinds" for indicating what happens when swiping: https://www.google.com/design/spec/components/lists-controls.html#lists-controls-types-of-list-controls Scroll down to "leave-behinds".

Implementation idea for a first shot at it could be to enable a choice of swipe directions in the ItemTouchHelper. Upon swipe of item, swap out the displayed item in the adapter and replace back that on timeout similar to the current UndoHelper. The replaced item could have an action. Of course handling the "leave-behinds" requires better integration with the actual swipe.

[mikepenz]

@mattiasbe hi. thanks for your suggestion.

I am afraid this feature is "out-of-scope" of this library. The FastAdapter is here to manage your items, to provide all the API's you need for selection, expandable items. It allows you to add, remove, move, change items. And provides all the required methods to make your RecyclerView as fast as possible. The FastAdapter also provides the Items interface, which contains the methods how to display a specific item, but itself does not know about how an item looks like.

So having an item which provides the above logic is in the scope of the dev using the library.

I would love to have something like this in the sample. But right now I do not see this in the core of the FastAdapter may as additional addon.

Surely I would love to see a pull request adding something like this to the sample.

There are also already other libraries out which implement this kind of behavior. https://github.com/daimajia/AndroidSwipeLayout

[mattiasbe]

@mikepenz I understand completely, I initially dismissed the idea of creating the RFE for that exact reason (out of scope), but figured I had to ask anyway since the UndoHelper with the Snackbar undo UI is there in the project.

I've used that library in a few projects, including one with FastAdapter now. Never combined that particular project with the swipe to dismiss/remove though, just to reveal actions. Maybe it can be done, but as that is not the purpose of that library I prefer not to (ab)use it that way. Rarely ends up well further down the lifetime of the projects (again makes me thankful you have very focused libraries).

By the way for anyone wishing to use that swipe library with FastAdapter, please note that to get the swipe and click to work together, don't use the withOnClickListener from FastAdapter, instead set it on the item yourself (at viewholder creation time), and make sure to set the onClickListener on the top surface only.

I'll see what I can find time for. Thanks for another great library and support.

[Rainer-Lang]

Maybe you want to add an example?

[mikepenz]

@mattiasbe thanks for the detailed answer. If you find some time for a PR... just open it ;). I would really love to have something like this in the sample

[mattiasbe]

Looked into adding it into the sample app a little bit. Raises a few questions, multiple ways to do it, api design, not adding any support into the FastAdapter or doing so, how customizable, all features, or just parts and if so make it easy to use some of it (only leave behinds, no actions, only actions, only swipe). Ability to combine with drag.

Question 4 below pretty much sums it up about what I'm currently consider implementing for the sample app if anyone would be interested.

@mikepenz What would your preferred way of discussing for example API alternatives be (even for sample app only stuff)? Nothing major just that I prefer iterating/feedbacking it with someone.

Initial questions:

1. I started off adding it into the SimpleItemListActivity but as long as it is just one extra feature it might be OK but if adding multiple alternatives (actions or not etc) it might clutter that example too much. Add another activity now or maybe later. See also question 4.
2. For the "leave-behind" I'm considering an API just specifying a color and icon and/or text. Not a proper layout. At least to start with.
3. For the revealed actions I think I would eventually regret not making it proper layout. The mentioned swipe library uses a bottom layout in the same framelayout and assuming position 0 and 1 are the layouts in question. While that seems easy enough it clashes a bit with the onClickListener in FastAdapter (would be attached to the FrameLayout and trigger on all clicks). Could perhaps re-assign it as the FastAdapter keeps track of it but maybe have a separate layout. Thoughts? Maybe need some better examples to explain the issue?
4. Sample app, I'm thinking of somewhere adding at least three steps regarding swipes. A) Adding a basic swipe custom action. B) Adding a swipe action with a material design "leave-behind". C) Like B but the item also changes to a UNDO or other custom action(s). Possibly with options of how to timeout (gmail does it on scroll and similar, or on just pure time like the snackbar does). Does that sound ok, even if A) is pretty trivial it could be a nice example for many if they don't know much about ItemTouchHelper etc?

[Rainer-Lang]

@mattiasbe I would suggest to make better a new example - than merging all together. Could end up a bit confusing. :)

Would be also better to discuss....PR...

[mattiasbe]

@Rainer-Lang I forked and started some work on it. Can see the current state in the fork, I'll do a PR to get feedback at some point(s). From the state of my fork at the moment I'll next:

• Change the api with the background color and the leave behind drawable in the constructor to withX-style to more easily accommodate support of different swipe directions.
• Implement the different swipe directions (icon location for leave behind etc)
• Start using a swipe example specific item layout instead of the SampleItem to have a proper/usable UNDO "state". Update the example with undo.

See the attached screen cap for the current state of the implementation:

[Rainer-Lang]

Looks awesome.

[mikepenz]

@mattiasbe sorry for not yet answering your questions. The preview video you have added looks already really promising

Looking at your current implementation, it really might be something I would add to the core. Really clean, and also works without deep wires, so it stays very flexible.

I really like it!

[mattiasbe]

Thanks for your kind words @mikepenz Current state:

There are some api issues that can be tweaked etc, and could benefit from some support in the actual lib, like a Swipeable interface and support for that for easier API and built in features. Instead of having to add such a pattern by yourself (no example of a Swipeable interface given there yet, it's implicit only). The use/setting of swipedActionRunnnable is a bit clunky and could benefit from this.

But maybe good enough for a sample now so will do a PR, hopefully tomorrow, and later on it can be improved or even partly added to the core.

[mikepenz]

@mattiasbe I added notes to the PR. The changes are fine, but it seems like you merged the master into the develop which resulted in all the releases being part of the PR so i can't merge it :/

[mikepenz]

@mattiasbe the base is now part of the fastadapter-extensions module. Now we can improve the API. or even add deeper integration (as far as possible without altering the FastAdapter)

[mattiasbe]

Excellent :smile: @mikepenz

[mikepenz]

Will close this now as the base is included. I'm still open for improvements ;). But this might should find a new issue or PR then ;)