How much of a bad idea would passing -Xmulti-platf...

# multiplatform

[Florian Eula]

How much of a bad idea would passing -Xmulti-platform, -Xcommon-source and -Xexpect-actual-classes manually to the compiler to have expect/actual behavior with android variants be ?

• This is not a multiplatform project. It's a regular, com.android.library/application project.
• Variants are, for the vast majority of it, used to isolate environments (different APIs, package IDs to avoid sending debug builds to prod, debugging tools enabled in dev & qa, but not in preproduction or production, etc). Pure code isolation offers more guarantees than just build time parameters that turn things on or off.
• Having to maintain exact API shape across variants and only discovering you made a mistake when building that particular variant (or even better, crashing at runtime) isn't a pleasant experience
• API/Noop gradle modules suffer from the same problem, except that now you're also introducing gradle module resolution into it.
expect/actual however is very pleasant, and I'd love to make use of it across variants. src/main (or src/expect, or anything else) carries the expect fun component(...), src/debug has actual fun component() { DebugBehavior() } and src/main has a noop implementation. These compiler arguments are currently used across KGP, so I'm not too worried about them disappearing, altough you never know.

Tests show that it works quite well on 2.4.20! At the very least, it resolves the things I want, complains when APIs don't match, etc. If someone at JB wants to scream really loudly "oh god please don't do that" , I'd love to hear why (for any reason aside from me abusing the compiler, doing unsupported things, etc.)

[Ciaran Sloan]

In my experience, expect/actual is not your friend. I generally prefer to go with a simple interface and concrete implementations instead

[Florian Eula]

Interface/impls suffer from the same silent failure mode as variants in my experience, and the only thing catching it is eventually your DI complaining at build time when it assembles the tree. It's also not super pleasant to use when it comes to UI code, having to inject something down a tree of callers instead of just saying hurr durr Button() is red in prod and blue in debug.

What issues have you encountered with expect/actual ?

[Ciaran Sloan]

Expect/actual gets complex when each implementation requires different dependencies or platform dependencies. I use expect/actual for top level functions, but generally for classes I'd go with an interface instead