I've come to a realisation about MPP and intereste...

# multiplatform

[darkmoon_uk]

I've come to a realisation about MPP and interested in others thoughts - regarding the two current 'Gradle models' of achieving MPP - let's call them (1) platform-per-module and (2) platform-per-sourceSet.

Thread continues inside...

[darkmoon_uk]

Broadly; it seems that for the libraries/modules of an App, yes: (2) platform-per-sourceSet offers more concise organisation, less Gradle boilerplate to get the same job done.
For top-level Application Gradle modules though, it appears that (1) platform-per-module is the more comfortable - avoiding crowding and incompatibility between, say, Android and JavaFX plugins in the same module... alongside iOS setup - all in the same file! No; that is better split to a Gradle module per platform.

Can anyone concur with or challenge this position?

Because (2) platform-per-sourceSet came second, and appears to serve a similar purpose as (1), it's been referred to as the 'new way' of doing things by some, with the implication that one should migrate away from platform-per-module. But as I get further into the project I am setting up; I can see clear use for both ways.

Don't both have their place?

[kpgalligan]

I don’t know what JB’s plans are, but it’s the “new way” to some, but the “platform-per-module” was also the “new way” depending on when you started (see “konan” plugin). I am a little torn here. I didn’t hate the PPM layout, but adjusted to the PPSS. From a library perspective, the PPSS allows for more consolidated dependency definition, which AFAIK isn’t implemented in PPM.

[kpgalligan]

I got the impression PPM would eventually be deprecated, so that compelled the move towards PPSS. Even if not “deprecated”, it seems unlikely that all new features and capabilities will be deployed to both.

[darkmoon_uk]

I guess what I'm saying is, it doesn't have to be one or the other - they both have their place. PPSS is nice, but I've found that in all but the most trivial setups, problems arise from having so many supporting plugins for different platforms in the same Gradle configuration space.

[darkmoon_uk]

Neither does it feel desirable - trawling through the supporting configuration for essentially 3 different Apps in one file.

[darkmoon_uk]

(In this case; Android, iOS and JavaFX Desktop... possibly Web later too)

[kpgalligan]

From reading your specific case, that the java and android plugins can’t live in the same module, I’d create interfaces rather than expect/actual classes, which is largely what we’re doing now for testability, and create one “base” module, then platform specific ones that do a project dependency.

[kpgalligan]

The only explicitly incompatible ones are android and java, which I’ve hit in other contexts. It’s crap. That android plugin is complex, and finicky. Not necessarily saying I agree or disagree with your position. Just thinking it unlikely that both plugins will get the same attention at JB, so we focus on the PPSS.

[kpgalligan]

Not to knock the android plugin. They get constantly criticized for being “slow” so they super optimize it (they being Google).

[kpgalligan]

Our “sample project” has been morphing over time. We have an android lib in the shared module, but I’ve been considering just making that a java dep. The testing situation now means we probably don’t need it to be an android lib https://github.com/touchlab/DroidconKotlin/

[jw]

When you have a bunch of libraries, the old way was terrible. Maintaining 3 parallel sets of dependencies for every module. Having 4 modules instead of 1 for each library. It was awful.

[darkmoon_uk]

Thanks for the input Kevin, that makes sense; I'm keen to find out what JB's intentions are for the kotlin-platform-* plugins - it's hard to find a clear answer on whether they're deprecated or not. My suspicion is that there are so many ideas in the wash with Kotlin at the moment, that they don't have a clear answer themselves and are seeing what remains useful over time.

[kpgalligan]

Yeah, I suspect that is how the decision will be made on the 2 plugins. See how it goes.

[darkmoon_uk]

I can definitely see that for Libraries @jw. Conversely, it also feels pretty bad having all the config for several top level Apps in the same gradle file without any explicit scoping - so I'm hoping both ways continue to be supported.

[jw]

Yeah I still put the apps in their own modules. The plugin is smart enough to figure out that an android module, a java module, or a js module depending on a MPP one should choose the correct artifact

[jw]

I don't have any expect/actual at that layer

[kpgalligan]

Our internal multiplatform learning arc has been learning how to put expect/actual everywhere, then learning how to take it out.

[ian.shaun.thomas]

^ that feeling when you realize you really only needed interfaces the entire time

[alec]

ive found expect/actual useful for library development but not for application development

[darkmoon_uk]

Having been back and forth on this a couple of times now in my project setup (now willing to accept a compromise and move on...), concluded a couple more things:
1. It does look like JB are firmly guiding us towards Platform per Source Set as supporting plugins for iOS like xcode-compat are for multiplatform, and there is no kotlin-platform-ios or kotlin-platform-native etc. making iOS setup, in particular, more difficult and unsupported without multiplatform.

[darkmoon_uk]

2. The clash between java and android plugins remains a horrible limiting factor of the Platform per Source Set model - meaning it's currently impossible to use expect/actual between Android and Java targets defined in the same module.

[ian.shaun.thomas]

I have started keeping android solo from everything else. It's the only one that can't play nice with others so far in my experience.

[darkmoon_uk]

I've arrived at keeping all the top-level App definitions separate too now; the compromise I mentioned, is that I was hoping to at least have a common library where each platform could have expect/actual definitions. That's now limited to just having a jvm target covering both Desktop and Android.

[darkmoon_uk]

...back to what @kpgalligan and @ian.shaun.thomas both said then, the solution to abstracting has to be interfaces, and not expect/actual 🙄

[ian.shaun.thomas]

Well expect actual is fine you should just prefer interfaces as it simplifies your life.