Pocket Notes 5 — swipe to delete, with undo

Four chapters in, and nothing can be removed

Pocket Notes writes notes and edits them. It has never deleted one. You can prove that unpleasantly: open it now and count the "Test note" rows chapter 2 left behind, which you have no way of getting rid of short of uninstalling the app.

Adding delete is easy. The @Delete function has been sitting unused in the DAO since chapter 1. What is not easy is the question that arrives with it:

How do you stop somebody deleting the wrong thing?

There are two answers, and almost every app picks the worse one.

Why undo beats "are you sure?"

A confirmation dialog looks like caution. Look at what it actually does.

It taxes the right answer to catch the wrong one. Ninety-nine deletes out of a hundred are meant. All hundred get interrupted, so the ninety-nine correct ones are made slower and more annoying in order to slightly inconvenience the one mistake.

It stops being read almost immediately. A dialog that appears every single time trains you to dismiss it without looking. By the fiftieth note you are tapping "Delete" before your eyes have focused on the words — which means the one time it mattered, you tapped through that too.

It cannot answer the question you actually have. The mistake in a list is almost never "I did not mean to delete anything". It is "I did not mean to delete *that one*". A dialog saying "Delete this note?" does not tell you which note, and by the time you find out you have already answered.

It arrives at the worst possible moment. You are mid-gesture, thumb moving. The dialog stops the motion to ask a question you already answered by starting the gesture.

Undo inverts all four. The common case costs nothing. The message is passive — you only engage with it if something went wrong. It appears after the result is visible, so you can see what happened before deciding. And it costs one tap on a button that is already on screen.

That is an optimistic update: do the thing, show the result, offer the way back.

The delete is genuinely a delete

This is worth being precise about, because there is a tempting shortcut here and this chapter does not take it.

The shortcut is to hide the row for four seconds, start a timer, and only really delete when the timer runs out. It sounds safer. It is worse in three ways:

• The list is lying. For four seconds the screen shows one thing and the database holds another. Everything downstream — a count, a search, a widget — has to be told about a state that only exists in one composable's head.
• It does not survive being killed. Android can stop your app at any moment. If the note is only "pending deletion" in memory, closing the app during those four seconds resurrects it, which is not what anybody asked for.
• Undo gets harder, not easier. You now have two ways a note can be absent and two ways to bring it back.

Here, vm.delete(note) removes the row the instant your finger lifts. The Note object is still sitting in memory in the snackbar's lambda, complete with its id and its original timestamp — and putting it back is nothing more exotic than saving it again.

Wrapping a row in a gesture

One new file. It knows nothing about notes.

Two functions in the ViewModel

1    fun delete(note: Note) {
2        viewModelScope.launch { repo.delete(note) }
3    }
4
5    /**
6     * Undo. The note still carries its old id and its
7     * old timestamp, so it slots back into exactly the
8     * place it came from - not to the top of the list.
9     */
10    fun restore(note: Note) {
11        viewModelScope.launch { repo.save(note) }
12    }

Look at how little restore does. It is save — the same @Upsert the editor uses — handed the whole original Note.

That is the entire reason undo works, and the reason it works well. The note still carries:

• its id, so @Upsert updates the row it used to be rather than inserting a new one with a new number;
• its updatedAt, so the query's ORDER BY updatedAt DESC puts it back in the same position in the list.

Compare the editor's save(id, title, body), which deliberately stamps a fresh System.currentTimeMillis(). Editing a note should move it to the top. Un-deleting one should not — the note has not changed, it has come back. Two functions, because they are two different ideas, even though both end at repo.save.

Delete, then offer the way back

The Scaffold needs somewhere to put it. One new parameter:

        snackbarHost = { SnackbarHost(snackbars) },

That is another Scaffold slot, exactly like topBar and floatingActionButton. Material knows where a snackbar belongs, knows to lift the FAB out of its way while it is showing, and knows to keep it above the navigation bar. You supply the state; it supplies the choreography.

Wrapping every card

Three things happen in twelve lines, and NoteCard is not one of them — it is untouched from chapter 3.

The snackbar is inverseSurface — #362F27, a dark brown against a warm cream page — with inverseOnSurface text and the action in inversePrimary. Those three tokens exist so that a message laid over your app can be legible without being a foreign colour, and they flip together in dark mode.