Feature Request - something like GRDB's ImmediateValueObservationScheduler

[Jack Palevich]

I hacked up my toy image board viewer app to use Blackbird, and compared it to a version that uses GRDB.

Blackbird branch: https://github.com/jackpal/HD/commits/Blackbird
GRDB branch: https://github.com/jackpal/HD/commits/main

The main UX difference between the two versions is that the Blackbird-based list views start out blank, while the GRDB-based list views start out filled in.

I think this is due to GRDB's value change publisher having a default "immediate" mode that fetches the value immediately upon creation.

It makes a big difference in the perceived speed of the app.

So I would like to request similar Blackbird functionality.

FWIW the Blackbird version of my app was less code and ceremony than the GRDB version. Good job!

But, the GRDB version does more. It uses foreign keys with cascading deletes to update the local database when posts and threads are deleted on the service. I haven't tried implementing similar functionality in the Blackbird version yet.

[marcoarment]

Thanks for the feedback!

Foreign keys with cascading deletes are on my "maybe" list. I'm still brainstorming how I might do them without adding a level of complexity that I don't want in Blackbird.

I downloaded your app and tested it out to see the immediate-vs.-blank initial state. If I understand correctly, the perceived-speed difference is because Blackbird's SwiftUI wrappers load asynchronously, rather than blocking the main thread until an initial load has completed. Is that what you're referring to? (Your app seems to be making network requests for the second-level views, making it longer than just database access, right?)

Assuming so, that's a design choice that I don't think I want to make an escape hatch or exception for. Maybe this is just me always fighting the last war, but Overcast to date (via FCModel) has serialized ALL database access onto the main thread, and it causes a bunch of little performance bottlenecks and problems throughout the app.

I designed Blackbird as the opposite extreme: blocking the main thread as little as possible, and forcing client access to be async.

The intention with the SwiftUI wrappers is to use their nil/.didLoad states to detect a "loading" state and display a placeholder UI for the (hopefully very brief) time that it's waiting for the database access. In my usage so far, it's extremely difficult to visually catch the UI in this state since it's usually so fast.