Hi, I am working on a library that will be used fo...

# multiplatform

[Blaž Vantur]

Hi, I am working on a library that will be used for mobile platforms, and later on it will be extended to support other platforms. I want to design library as easy as possible for developers to include it into the project, so the perfect use case would be to have only 1 implementation call for common source set in build.gradle file, and then only small chunk of code to provide some additional configuration which should also be located only in common code.

The problem that I am currently having is that library needs Android context in order to successfully create separate database with SqlDelight on Android side and I don’t know how to do that, to achieve above written design. Currently I am passing database driver directly to the library to avoid having to deal with context, but configuration for developers now is a bit more complex to what I want to achieve. Does anyone have an idea how to include Android specific objects in project common code and how to then use that object in library common code?

[Devanshu Pathsariya]

You can create a actual/expect implementaion for creating the your database instance for the platforms you are targeting.

[Swapnil Musale]

You can't access platform specific code in commonMain sourceSet.

For my one of library to access context useing StartUp library to get the context and saved it in global variable.

I think you need to use expect actual approach to satisfy your requirement for every functionality of which library user wants to access while working.

[Devanshu Pathsariya]

What I understand from your problem statement is that you Context on Android platform to create the database instance which means you are supporting the android target, you create a database initializer for you library.

[Blaž Vantur]

That is a really interesting idea to use StartUp library to get context on library side @Swapnil Musale. I didn’t thought about such approach. Thank you. I think it could work with your approach, yes.

[Blaž Vantur]

@Devanshu Pathsariya yes, my only need for android context is because I want to create library specific SqlDelight database.

[Devanshu Pathsariya]

You can use actual/expect classes for the database initializer and to make your library more platform adaptive you can also create actual expect implementation to use Plateform native databases(A ssugestion only if i am undestanding you requirement correctly).

[katz]

common main

expect class InitInfo
fun myLibFun( initInfo:InitInfo)

android

actual typealias InitInfo = Context

others

actual typalias InitInfo = Unit

Keep in mind - you can not use platform specific classes in common code

[Blaž Vantur]

Yes @Devanshu Pathsariya, you understand it correctly. 🙂 What you have written is what I am doing now in my project. Whenever you include library to the project, you also need to provide database platform specific configuration directly on the project side. But this is something I want to avoid and I think Swapnil recommendation could enable me to design library as I written in my first message.

Also @katz, your idea looks interesting as well. 🤔

Thank you guys, you gave me a lot information to think on them now 😉 😄

[David Wasser]

Another option is to pass a Map containing key/value pairs into your library containing platform-specific information. This map can then be made available to all code within your library. For Android you could require a key/value pair for "Context". On other platforms you may need other things. Your common library code will never look at this Map because it contains only platform-specific information. The platform-specific code within your library can use the Map to access specific platform information. Using a generic Map for this is a neat way to pass platform-specific information from the user of the library down into the platform-specific parts of your library.

[Arjan van Wieringen]

The expect/actual mechanism should allow you to expect some sort of implementation of an interface in platform code. Just define this implementation in such a way that you can work with it in your common code.

Unless I am completely missing the point of the post, I don’t see any reason why this shouldn’t work. The interface should just expose some way to initiate the SQLDelight connection. The platform specific code for Android implements that.

[David Wasser]

@Arjan van Wieringen The usual problem is that the platform-specific code is called, not from the user of the library, but from the library itself (to do platform-specific stuff inside the library). In this case, the platform-specific code NEEDS the Context from Android, but the common code in the library doesn't have this, because Context is Android-specific. So the library somehow needs to get a hold of the Context without knowing anything about it, and pass it through to the platform-specific code. This is a common problem with multi-platform libraries.