Providing different implementations (based on build Variants or flavors?) on Android / Gradle.

[Gryzor]

Context: The Android app I'm working on is quite big, hundreds of dependencies are provided and injected everywhere, in over 100 gradle modules; the app is bound by moderately strict legal requirements and regulations; it currently (ab)uses Koin 4.x

I'm evaluating the cost (effort, time, feasibility, etc.) of migrating to a Compile-Time DI solution. I've considered: kotlin-inject, Hilt, Dagger (w/out Hilt), and as I was about to dive deep in Anvil, I found Metro.

I'm in the Metro proof of concept phase, and I would like to know what is the "correct" approach in Metro to these issues.

Due to the dynamic (aka: runtime) nature of Koin, the current app is able to do this:

/src/main/java/some/package/aKoinModule.kt
/src/develop/java/some/package/aDevelopKoinModule.kt

Both Main and Develop sourceSets are merged at compile time by design, but because they have different names, and because there are different : Application() implementations on each one, only one is really included at runtime; and that implementation only adds the corresponding modules (since they have different names anyway). Sneaky...

With solutions like Dagger/Hilt this is not possible, since the sources would be merged and they would collide (multiple Provides implementations, duplicated object name, etc.). The solution offered by Hilt developers was to do something like this (YouTube Video where they were asked a similar question):

@Module
@InstallIn(SingletonComponent::class)
object SomeModule {

    @Provides
    fun providesSomething(): Something {
        return if (BuildConfig.DEBUG) { 
            DevelopSomething()
        } else {
            ProductionSomething()
        }
    }

Needless to say, we do not like this approach at all for multiple reasons.

Considering the app currently has two build types:

• Debug
• Release

And Three Flavors:

• Develop
• Production
• Another

Using sourceSets directly is... something we'd like to tame/avoid where possible (at least try to avoid touching this as much as possible).

So... finally to the question:

• How can Metro solve this? Using extensible DependencyGraphs? (isExtendable = true) Something else?

tl;dr

What is the best practice to have dependencies per build variant in Metro?

Think of:

interface Thing {}

and then

DevelopThing() vs. ProductionThing().

Note this is not about unit tests (that's a whole other world covered by DependencyGraph.excludes + replace in Metro's world).

Thanks

[ZacSweers]

I was going to point you at excludes and replaces, but I saw at the end that you dismiss that as specific to unit tests. Any reason you don't think they're valid options for this case? That's how we've done this since Anvil times as well - basically you would have your debug module replace the standard (i.e. implicitly "release") equivalent module.

[Gryzor]

@ZacSweers Thanks for the response. You're right that I maybe dismissed that too fast perhaps based on the initial (and wrong) premise that they worked similarly to Hilt testing artefacts, that are only applicable during testing via the @TestInstallIn(...) annotation; I automatically assumed it was the same here.

My first attempt was this:

In main:

@DependencyGraph(AppScope::class)
interface AppGraph

Somewhere in main too:

@ContributesTo(AppScope::class)
interface NetworkProviders { 
    @Provides
     fun someThing(): Thing = ProductionThing()  // This is what I hypothetically wanna replace in Develop
 }

Now in develop [main]

@DependencyGraph(
   scope = AppScope::class,
   excludes = [NetworkProviders::class]
)
interface DevelopAppGraph { 
    @Provides
     fun someThing(): Thing = DebugThing()
 }

But it had a problem, because My DebugThing and ProductionThing both took a constructor injected dependency that was defined in the main AppGraph like:

@DependencyGraph(AppScope::class)
interface AppGraph {
    @Binds
    val SomeImpl.bind: Something 
}

// These are the 'involved' classes here for 'reference'
@Inject
class SomeImpl : Something { ... }

@Inject
class DebugThing(something: Something) : Thing { ... }

@Inject
class ProductionThing(something: Something) : Thing { ... }

And this caused the DebugThing above to miss a provides/binds for 'SomeImpl'.

I then tried this other approach, inmain:

@ContributesTo(AppScope::class)
@BindingContainer
interface MainNetworkProviders {
    @Binds
    val ProductionThing.bind: Thing
}

And in debug:

@ContributesTo(AppScope::class, replaces = [MainNetworkProviders::class])
@BindingContainer
object DebugNetworkProviders {
    @Binds
    val DebugThing.bind: Thing
}

This worked. But I'm a bit confused (still) about the differences and practical applications of various replace/extend/exclude options.

Would a hypothetical 'test' do a similar thing? Would it expose something like this?

@ContributesTo(AppScope::class, replaces = [MainNetworkProviders::class])
@BindingContainer
object TestNetworkProvider {
    @Binds
    val FakeThing.bind: Thing
}

?

I've read the documentation multiple times so please accept my apologies if these sound like silly questions, but without a cohesive example highlighting why you'd want to do one or the other (which may be obvious once you grasp it), it's a bit difficult to figure out which the best/correct/only approach is and I'm trying to grasp all this new knowledge while thinking of the implications each decision may have in a big project like this one.

Is the above 'the way to go'?

I saw at the end that you dismiss that as specific to unit tests. Any reason you don't think they're valid options for this case?

I'd say because in Aggregation's docs, it says:

This is useful for cases like tests, where you may want to contribute a test/fake implementation that supersedes the “real” graph.

Perhaps it could be expanded to '...for cases like tests or different build variants, where you may want to contribute a test/fake or a different implementation that supersedes the "real" graph'

Practically nowhere in the entire documentation I found are 'source sets' mentioned like that (or I missed it) but 'testing' is covered in various pages, so my decaffeinated brain probably didn't do 1+1 properly.