I'm looking at the multiplatform sample on SqlDelight. It only has the common code in the common lib. Platform specific (Android/iOS) drivers are added in top level app module. My question is that how would this work on a Multiplatform library. Let's say we have a library where the persistence is an implementation detail. Is it possible to keep it all in the "common" module and all users will automagically get the correct version?

If I'm understanding question correctly then that's what's being done in following for example https://github.com/joreilly/PeopleInSpace

Heh, you are storing Context in a top level property in the shared module 😀

your driver initialization has to be platform specific

yes, but still contained within common module (using expect/actual mechanism)

Saving context in app's onCreate has a few cons: 1. The dependency on context is hidden, 2. Integration testing is much harder, 3. It may crash if used from a BroadcastReceiver, 4. Brakes hot reload

yes, expect a function to return a SqlDriver

Context is mandatory to instantiate the Android driver, right?

Context is required, yes.

Depending on what level of abstraction you're going for, you could have the user pass a context and generate driver from that. But then need to expose different API for Android then for other platforms.

That was also what I was gonna write just now

So would put database in a separate module and depend on this module and on a driver. Clients should have the database in an app scope.

It does. There's a jdbc driver

Thanks, good to know

i added platform-specific init methods, which create the driver and pass it along where it needs to go

So you have to call it before use. This works in most of the cases. However has same issues same as saving context in a static field.

In an app sure. That's what I would do. Library is different. I want to keep it as implementation detail.

There are scenarios where the IDE gets confused, but Gradle generally can handle it

Yes, I need everything in one module 😊

Then abstract from SQLDelight. Even better. Create your own interface and depend on it. Then SQLDelight will be implementation detail. Clients will use whatever they want. E.g. a shared module with SQLDelight database. Or Room on Android.

You mean clients would have to implement that abstraction?

Actually, the multiplatforms settings sample does have all in one module if you want to look at that. https://github.com/russhwolf/multiplatform-settings/blob/master/sample/shared/build.gradle.kts

Thanks.

re context, lifecycle, abstraction: I think it generally makes sense for a library to provide initializer methods that may be platform-specific. Can also add teardown methods if lifecycle is a concern. Then client apps can integrate it into whatever DI strategy they have. But ideally the initializer just exposes high-level stuff and not library implementation details. So you could take a context in there, and if there's concern about it being long-lived (which there might not be, if it's application context), then null it out in a teardown method and document that as best practice

That sounds like a better architecture but to be honest none of the common libraries are doing that including at least 4 from AndroidX & Firebase.

yeah most of the google stuff is going the contentprovider path these days. As long as it's an application-level thing and there's no lifecycle concerns I think that's reasonable. It's a bit of a tricky balance between wanting things to be configurable (maybe a user only wants this thing in-memory for a certain application flow and wants to be able to clear it out later) and wanting it to be simple

i assume by content provider path, you mean they're putting one in their manifest just to init during app startup?

yeah

fairly clever, but modules typically need some kind of configuration

You can do both. Have some default that works out-of-the-box and then extra config API for the people who need it. WorkManager does this, where you can pass dependencies to your workers by disabling the default content provider initializer and supplying your own instead.

In my use-case, I don’t think users will ever be configuring something.