Handling minor differences in build variants

Question

I have an application with 2 product flavors and as a result 4 build variants:

1) freeDebug
2) freeRelease
3) paidDebug
4) paidRelease

I have a Fragment that contains an ad, and it takes 2 lines to implement:

@Nullable @BindView (R.id.bottomsheet_ad) AdView mAdView;
mAdView.loadAd(adRequest);

So because of 2 lines, I have to potentially maintain 2 or more files.

I'm considering 2 solutions:

1) Check flavor at runtime:

if (BuildConfig.FLAVOR.equals("flavor123")) {
    ...
}

2) Create a common flavor and point needed variants in gradle, as explained here:

android {
    ...
    productFlavors {
        flavorOne {
            ...
        }
        flavorTwo {
            ...
        }
        flavorThree {
            ...
        }
        flavorFour {
            ...
        }
    }
    sourceSets {
        flavorOne.java.srcDir 'src/common/java'
        flavorTwo.java.srcDir 'src/common/java'
        flavorThree.java.srcDir 'src/common/java'
    }
}

Which solution would be better? And is checking flavor at runtime as above considered polluting the code?

IMHO, a better option than those two is to use `buildConfigField` to define a custom flag in your Gradle script, then branch your code based on that flag. In other words, do not depend on `BuildConfig.FLAVOR`, but `BuildConfig.DO_WE_SHOW_AN_AD_HERE`. — CommonsWare, Jul 01 '19 at 19:45
If your only concern is about this `Ad`, I'd use stubs and provide an empty impl per flavor (and wouldn't bother making the project more complicated). But it really depends on so many factors it's hard to tell. I wouldn't do the `if` in the code. Or as suggested above ^ use buildConfig flags (tho I usually use these to turn features off for debug, not per flavor) — Martin Marconcini, Jul 01 '19 at 19:45
@CommonsWare Thanks a lot for the suggestion, I'll give it a go, looks like a more neat way to do it. — Suleyman, Jul 01 '19 at 19:53
@MartinMarconcini That's a really nice option, I haven't thought of that. I'll try CommonsWare's suggestion and this one as well. Thank you! — Suleyman, Jul 01 '19 at 19:56

score 4 · Accepted Answer · answered Jul 01 '19 at 19:48

4

You can add something like following to appropriate flavor in your build.gradle

buildConfigField "boolean", "showAds", 'true'

And then use like following (your main src files will still be used for additional flavors you add):

if (BuildConfig.showAds) {

}

answered Jul 01 '19 at 19:48

John O'Reilly

10,000
4
41
63

Looks like a clean way to do it! Thank you! I just have a small, maybe stupid question, is this technique something you would use in a "production ready" application? – Suleyman Jul 01 '19 at 20:14
I'm using it here fwiw. Seems to be a common enough pattern. – John O'Reilly Jul 01 '19 at 20:38
That's a valid point :D Thanks a lot for the answer again, will definitely use it! – Suleyman Jul 01 '19 at 20:51
This is a valid pattern. Do not abuse it :) – Martin Marconcini Jul 01 '19 at 22:30
@MartinMarconcini I'll try not too :D But would it be possible to change those values and remove the ads if the apk is decompiled, or am I thinking too much? – Suleyman Jul 01 '19 at 22:34
@MartinMarconcini That is all I needed to hear :D thank you! – Suleyman Jul 02 '19 at 05:09

Handling minor differences in build variants

1 Answers1