Hi everyone, what is the easiest way to distinguish between different Android flavours in a multipla...

# multiplatform

[Márton Matusek]

Hi everyone,
what is the easiest way to distinguish between different Android flavours in a multiplatform project? I would like to have a Huawei and a Google target. Thanks

[Nacho Ruiz Martin]

Do you mean that you want to have different code in the shared module/s depending on the Android target?
If that’s the case, you could use something like BuildKonfig or a custom solution injecting a target enum depending on the Android flavour.

[Márton Matusek]

I would like to build a different version for the 2 flavours.

[Nacho Ruiz Martin]

Both solutions work in that case.
With BuildKonfig you will need to set a different value in gradle.properties (for instance) depending on the target.
The cleanest solution (for me) is to inject some value into the class in which you have a difference depending on the Android flavour. This is easily doable if you are using some DI mechanism. For example, I’m using Koin and I create a custom app module that injects this value.

[Nacho Ruiz Martin]

For example:
initCore is the function that will initialize the DI in the shared module/s.

[Nacho Ruiz Martin]

This is run in the Application class.

[Márton Matusek]

Thank you! This is a good solution I think! It also look scalable because there is no conditional logic outside the DI container

[Nacho Ruiz Martin]

Yeah K

[Márton Matusek]

I first thought of a gradle based solution with separate modules but that’s probably not necessary

[Nacho Ruiz Martin]

Oh, that would make sense but I feel it’s more complex and probably unnecessary. Interface/implementation pattern is good enough here.

[Márton Matusek]

Yes, thank you!

[electrolobzik]

Guys, but is it possible to include different versions of the same class/function for 2 different flavours? In my case I have some development stuff which I would like to see as prefilled in the debug builds, but it should be not present in the codebase in production. (not even not work, but also be absent in the class file)

[McEna]

move that stuff to a couple separate modules, stuff-debug & stuff-prod. The former depends on the latter. Then, in gradle, import stuff-prod for release builds and stuff-debu for everything else. That would allow you to remove the classes based on build variants/flavors/whatever you can check from the script.

[Márton Matusek]

One more question guys. If someone uses my project as a library that has huawei and google specific parts injected based on the target flavour, how do I let the library consumer decide which flavor they want to use when building their app? It means passing configuration from the app gradle build down to my library.

[Márton Matusek]

Do I simply publish 2 libraries and they decide in their build?

[Nacho Ruiz Martin]

All the proposed solutions work in that case.
It only depends on how you want the API to look like. Do you have a method or class that your users will use to initialise the SDK? Then the parameter still applies.
If not, the two different artifacts solution looks quite cool.