When you build mobile apps, it’s necessary to think of the user. What happens if they want to drag that entry but then accidentally delete it?
They delete the app and just go back into their cave taking notes on the rear side of a shop receipt.
Just kidding. We are in the third millennium. All they do is: They tap on Undo and that’s it.
Here is a bit to what happens behind the scenes when you undo something in an app.
Preparation
Preparation: We add a widget with a text telling the user where to tap if they like to undo something.
In my case, this comes as a SnackBar, a small and temporary overlay widget.
The lazy idea
The lazy one. I added a return; in the onPressed callback of the SnackBar action.
Well, while this looks neat, it just doesn’t work at all. It leaves the onPressed callback of that SnackBar, but not the onPressed callback of the delete button. So after Undo, the item has been deleted anyway.
Delete later
First approach: We postpone the deletion of that item until the snack bar has gone without the Undo event.
Yeah, okay, but … this feels quite slow if you are about to delete multiple notifications on a large social media app (be careful, try it on LinkedIn app if you have that, because if you delete a Substack app notification, you delete the comment, too, afaik).
Delete but bring back
The solution which feels best is to define a local variable to backup the deletable data in the background so that we then can restore it if marked as Undo.
In the video, all there is stored is a string, but it’s just a small change.
Side note: We still cannot undo spilled coffee, for me at least it’s a sign that we don’t live in a Matrix.
