Modularize for platform independent abstraction

[fardavide]

Since this is a great libs that could also fit a single-platform project ( i.e. Android ), I think that could be a great idea to separate platform specific code ( Android + iOs ) in a separate module

Why

Given an Android app with 2+ modules, where at least one is platform independent ( e.g. pure jvm domain module ) it would be a good idea to abstract our "settings" in the business roles. I.e.

// Domain jvm module: 
class AppSettings( settings: Settings ) {
    var username by settings.string( "username" )
}
// App android module:
val appSettings = AppSettings( PlatformSettings.Factory( context ).create( settingsName ) )

How

Create 2 modules:

• core: everything, but:
• platform: PlatformSettings

Then Multiplatform user could keep using implementation "com.russhwolf:multiplatform-settings:0.2", while other could use implementation "com.russhwolf:multiplatform-settings-core:0.2" and implementation "com.russhwolf:multiplatform-settings-platform:0.2"

If you think that could be a good idea, I'm willing to help

[russhwolf]

This is not a use-case I've really considered. Can you say more about what would be enabled by doing this that isn't possible with the current setup? Can you work around this with a multiplatform setup that only has a single jvm/android platform?

[fardavide]

I could workaround but I don't see as a good choice.

What I would like to achieve is to use the lib in a "standard" Android project and be able to keep the Settings implementation in my pure Java domain module, without the needing to create an interface and implement in my app module or another module ( since the implementation is already is another module, which is the lib, technically ). I could take SqlDelight as example, I've been able to keep everything in my domain module, and only build the database outside, with the standalone android-driver artifact

[russhwolf]

Ok I think I see it. One alternative fix might be if you could access the Settings interface from all platforms, even if there isn't an implementation for that platform. I think that would be possible even in a single-dependency setup after the refactors I'm thinking about in #14.

[fardavide]

Also this method should be good 👍

[SimonSchubert]

Right now I can't compile for the Linux platform because the Linux implementation is missing right? I'm ok with not using the feature on Linux(actual var settings: Settings? = null). This method would also fix this right?

[russhwolf]

@SimonSchubert yes, when this is closed the interface will be published to all platforms. This means you'll be able to reference Settings in Linux code, but you'll have to provide your own implementation to use it there.

[russhwolf]

Version 0.5 is now out with Settings available on all platforms.