When creating a compose desktop app using the wiza...

# compose-desktop

[Colton Idle]

When creating a compose desktop app using the wizard and selecting "Multiplatform" I was actually really surprised that android/build.gradle.kts and common/build.gradle.kts both have android deps in them.

android has

dependencies {
    implementation(project(":common"))
    implementation("androidx.activity:activity-compose:1.3.0-alpha03")
}

Which makes sense. android module depends on common module. and also activity compose lib. cool.

But then common has

val androidMain by getting {
            dependencies {
                api("androidx.appcompat:appcompat:1.2.0")
                api("androidx.core:core-ktx:1.3.1")
            }
        }

That seems... wrong? Should appcompat and core be directly in android build file?
As an experiment I just commented out those /common android deps and placed them in /android build file and everything works. again... leaving me confused as to why have the android deps in two places?

[jim]

I believe this is correct (demonstrates how to declare platform-specific dependencies in a common module), although those particular dependencies are unused and thus not technically necessary.

Why this is necessary: You may be developing a module which is intended to be an MPP module (let's call this module foo-library) which can be invoked from common code. Most of the time, your implementation of foo-library can hopefully only depend on other common libraries, and thus is platform-independent. However, sometimes, your foo-library might need to use some platform-specific implementations under the hood in order to behave properly. In such cases, the module still exposes a platform-independent API, but internally it uses expect-actuals for each of the supported platforms. The expect-actuals must live in the same compilation unit which effectively means they must be in the same module, which means you need to have platform specific dependencies in your foo-library module as an implementation detail.

[Colton Idle]

Gotcha. Yeah. I feel like in this case the (and this may only be my perspective) setup should be as simple as possible. And actually having them be separated actually caused me confusion because the app was crashing due to an old dependency but I did not see the dependency in the android app module. Little did I know that my global find was selected to the module and not the whole project and so it was pulling in a dep from a common module... Which just seems weird.

Anyway. I see your point but yeah, I'm sticking to my original thought that it should be a simple wizard and if you want to have common code that calls into some sort of lib, so be it but you can leave that as an exercise to the reader. 😁

[jim]

It's a balance. We also want people to easily be able to do pattern matching on the sample and use it to get started without their app, without just being thoroughly confused about how to take the next step. Unless it is part of the sample, what you would do if your common module needs an expect-actual is somewhat undiscoverable.

[jim]

But once you know how it works, it seems obvious how you would find such a thing. But it's not obvious if you don't already have the right mental model or know which terms to search for.

[Colton Idle]

Yeah. I guess what I'm really after is "show me the simplest working compose Android and desktop project so I can try to make it work with my current project"
😁