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.

you can use the source sets instead of BuildConfig

@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?

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

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

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

data class BuildConfigDebug(val value:Boolean)

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

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

If you have a clean architecture domain layer you shouldn't have dependencies on

BuildConfig

or Android framework in there

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

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

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

^ idk personally I think that seems fine

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.

Projects I've seen we only needed

BuildConfig

in few places usually around err handling and

Application.onCreate

so just used direct

Gotcha. Appreciate the insight and experience