Implement bookmarks

[ZacSweers]

Resolves #102

Some highlights

• Using a nested Circuit screen in a list item for the bookmarks UI
• Separate composite bookmarks DB
• A little more compose KMP work
• New Bookmarks screen with some swipe to dismiss

Screen_recording_20230910_011546.mp4

[ZacSweers]

I should add an export feature

[jingibus]

Inject this. Constructing this scope internally bakes in the assumption that the class is singleton-y; not doing this is a major reason we use the DI pattern and DI frameworks like Dagger.

Also, don't inject as a val. See comments below about launches on instance methods. Launches on initialization are fine IMO, and don't require making the scope a val, either.

[jingibus]

This API probably wants to be a suspend fun! In many scenarios the caller can and should safely own this, and a suspend fun still opens the door for kicking it over to a longer lived scope if the caller really does need that

If you feel strongly opinionated that this is the right API shape, then scope.launch still isn't the right choice. Use a channel instead:

data class AddBookmark(val id: Long, val timestamp: Instant)

private val addBookmarks = Channel<AddBookmark>(BUFFERED)

init {
  scope.launch {
    for (item in addBookmarks) {
      database.transaction { database.bookmarksQueries.addBookmark(item.id, item.timestamp) }
    }
  }
}

override fun addBookmark(id: Long, timestamp: Instant) {
  addBookmarks.sendOrFail(AddBookMark(id, timestamp))
}

You might say, "I don't need a queue! Why did you make me build a queue?" But you already had a queue: it was the dispatcher, and its failure mode was "my dispatcher is full of hung bookmark add operations".

[ZacSweers]

my concern about making it suspend is that I don't fully understand what that communicates to the caller. What happens if they cancel the add? Is that something the UI gets to really decide? Does the add() always work but the UI gets to know if it successfully handed it off (synchronously) to the internal transaction handler?

[jingibus]

• When the suspend fun write completes successfully, the caller knows the write succeeded
• If the write fails, the caller will get an exception (which is good)
• If the caller cancels the addBookmark call before it completes (e.g. by navigating away), then the write will get discarded
• If the caller wants to navigate away and not cancel the write, they can still accomplish that by doing exactly what your existing code here does

All of these are valid choices, which is why I tend to prefer suspend funs for this type of thing.

[jingibus]

Same

[ZacSweers]

Thanks @jingibus!