Channels
#multiplatform
Title
# multiplatform
d
darkmoon_uk
05/03/2019, 1:41 PMI'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...
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?
k
kpgalligan
05/03/2019, 1:53 PMI 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.
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.
d
darkmoon_uk
05/03/2019, 1:55 PMI 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.
Neither does it feel desirable - trawling through the supporting configuration for essentially 3 different Apps in one file.
(In this case; Android, iOS and JavaFX Desktop... possibly Web later too)
k
kpgalligan
05/03/2019, 1:56 PMFrom 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.
👍 1
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.
Not to knock the android plugin. They get constantly criticized for being “slow” so they super optimize it (they being Google).
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/
j
jw
05/03/2019, 2:03 PMWhen 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.
➕ 1
👆 1
d
darkmoon_uk
05/03/2019, 2:03 PMThanks for the input Kevin, that makes sense; I'm keen to find out what JB's intentions are for the
kotlin-platform-*k
kpgalligan
05/03/2019, 2:05 PMYeah, I suspect that is how the decision will be made on the 2 plugins. See how it goes.
d
darkmoon_uk
05/03/2019, 2:06 PMI 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.
j
jw
05/03/2019, 2:07 PMYeah 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
✔️ 1
I don't have any expect/actual at that layer
👍 1
k
kpgalligan
05/03/2019, 2:22 PMOur internal multiplatform learning arc has been learning how to put expect/actual everywhere, then learning how to take it out.
😅 1
i
ian.shaun.thomas
05/03/2019, 3:08 PM^ that feeling when you realize you really only needed interfaces the entire time
a
alec
05/03/2019, 11:38 PMive found expect/actual useful for library development but not for application development
👍 1
d
darkmoon_uk
05/05/2019, 10:58 PMHaving 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-compatmultiplatformkotlin-platform-ioskotlin-platform-nativemultiplatform2. The clash between
javaandroidi
ian.shaun.thomas
05/05/2019, 11:00 PMI 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.
d
darkmoon_uk
05/05/2019, 11:03 PMI'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/actualjvm...back to what @kpgalligan and @ian.shaun.thomas both said then, the solution to abstracting has to be interfaces, and not expect/actual 🙄
i
ian.shaun.thomas
05/05/2019, 11:29 PMWell expect actual is fine you should just prefer interfaces as it simplifies your life.
7 Views