More of a DI/android discussion than dagger specific, but was just curious to hear if people try to ...

# dagger

[Colton Idle]

More of a DI/android discussion than dagger specific, but was just curious to hear if people try to wrap Android BuildConfig into some kind of wrapper class. Every time I use BuildConfig.debug or BuildConfig.someApiKey I feel like I shouldn't access it directly.

[Javier]

you can use the source sets instead of BuildConfig

[Colton Idle]

@Javier sorry, not following? Are you saying source sets as in different directories /free and /paid and stuff? I'm assuming I would do that, but I guess I'm more curious whether people feel like it's overkill to Dependency Inject BuildConfig?

[Javier]

Yeah, it is not overkill, indeed you can disable the generation of buildConfig improving the build time

[Colton Idle]

Hm. There's another idea. Just disabling buildConfig completely... that wasn't my original intent with my question... but maybe?

[trevjones]

I do data class for the value that needs to be injected down to JVM modules.

data class BuildConfigDebug(val value:Boolean)

[Jeremy]

As long as dependency is at the appropriate layer seems same tradeoffs as dependencies on Android framework. Adding more layers/abstractions can make the system harder to reason about

[wasyl]

What does the build config contain for you? For me each value is just provided from application-wide scope, maybe with a qualifier

[Jeremy]

If you have a clean architecture domain layer you shouldn't have dependencies on BuildConfig or Android framework in there

[wasyl]

So only dagger application module accesses BuildConfig, everything else uses those values as regular provided dependencies

[Jeremy]

Certain things like feature flags, configuration values (api servers) I often put into dagger qualifiers. It decouples from implementation and provides a way to provide to all modules but its more layers/abstractions so has tradeoffs

[Jeremy]

If need to provide BuildConfig.DEBUG into libraries that are pre-compiled need to inject in somehow, not much choice

[Colton Idle]

In MyApplication.kt I mostly have a bunch of configuration based on BuildConfig.

Example:

if (BuildConfig.debug){
Firebase.getInstance().getCrashlytics(disabled = true)
} else {
Firebase.init(BuildConfig.MY_FIREBASE_API_KEY)
}

So just looking at that snippet. I have this feeling that I should provide a wrapper around BuildConfig fields AND Firebase lol

[Jeremy]

^ idk personally I think that seems fine

[Jeremy]

that code is also within the android framework and probably Application.onCreate or something?

[Jeremy]

If it was under test and you wanted to provide alternate behavior you could wrap it as considering and inject in a fake... but I'm not sure you'd want to run Application.onCreate in a test...

[Jeremy]

If you're trying to test an activity or something you can load the activity in the fake application provided by dagger hilt

[Jeremy]

or if you wanted to abstract the behavior so it wasn't "if build was compiled with debug flag" but "if we are in development testing mode" where it wasn't necessarily debug variant...

[Jeremy]

that may be useful in scenarios like instrumented tests where you wanted to specify diff behavior

[Colton Idle]

Yeah, I guess I'm not even looking at testing this stuff yet. It's just that I see that I'm strongly tying myself here to BuildConfig and wanted to see if people are larger companies typically just abstract away BuildConfig and don't access it directly.

[Jeremy]

Projects I've seen we only needed BuildConfig in few places usually around err handling and Application.onCreate so just used direct

[Colton Idle]

Gotcha. Appreciate the insight and experience