Author is a professional software developer providing android and iOS development services. More info here.
Checkout the code at the github repo.
Big shout-out to the guys creating libs for all the stuff Google promotes but doesn’t give us code for just yet, but the fact of the matter is I prefer not to use those libs unless I absolutely have to. The lib you include in your project might be doing a lot more than you need it for and with that comes a burden on your precious method limit count, possibly longer builds, another lib you and your coworkers need to keep in your heads…
The other day I had to implement “swipe to delete” feature. I wasn’t very happy about that since I feel that it’s not very discoverable and that those kind of gesture based actions shouldn’t be the only way to access the feature, but that’s another story. Still remembering how difficult this was couple of years back on a
ListView I’ve started googling and soon enough there was a simple SO post with a simple solution and the best part – no 3rd party lib needed! However, it wasn’t to be so easy in the end.
First issue I had was what happens after the swipe? Sure I’d like to draw something below the swiping view, but once the view is swiped and the deed is done, it was kind of anticlimactic :/
I wanted just to draw red background over empty space as items are animating to their new positions but I couldn’t do it inside the
ItemTouchHelper class. I had to introduce another
ItemDecorator in order to do so. The results were satisfying.
I was curious if I could easily implement the “undo” option, similar to the one GMail app provides. I had an idea how to do it and sure enough it worked!
But all the time I was seeing a weird issue: When I would swipe delete the row, scroll around and come back, the row above the previously deleted row would be gone. Debugging showed that it was x translated off screen, as a result of the swiping as it turns out. Note how I swipe delete Item 2 but afterwards Item 1 is gone!
I’ve sunk several hours into this issue, actually more than I’d like to admit. During that time I found several hacks to make this go away but no proper solution. In the end turns out it’s a regression bug in a recyclerview-v7 support library and the bug is gone in the newest version 3.1.1.
That’s all folks!