2

Build variant is a really powerful tool for creating different variant of your codes by specifying minor difference and I largely use it in my projects. But I wonder if it is possible to select a specific variant as a base for another variant rather than main.

For example, lets assume my app has 3 variants: A (main), B and C. Variant B has a lot of different resource file from variant A, so I add them into B variant folder and everything goes well when I compile variant B. But for variant C, it has a very small changes based on variant B. Now I wonder what is the best approach for creating variant C. The simplest approach is to copy all changed files of B variant (in comparison with A variant) to variant C and apply small change to them for variant C. I personally don't like this approach, because I need to apply all changed to variant B to variant C too which is prone to mistakes and bugs.

Is there anyway to connect variant C to variant B, so while aar trying to create C variant's resources, it uses variant B as base rather than variant A? I think it will be possible with adding another dimension to variants, but I prefer to do this without adding new dimensions.

Phantômaxx
  • 37,901
  • 21
  • 84
  • 115
Afshin
  • 8,839
  • 1
  • 18
  • 53

1 Answers1

0

You could config next BuildType based on other by e.g.

debugWithAnalytics.initWith(buildTypes.debug)

But you should use flavors and flavor dimensions in terms of functionality - it's possible to merge different flavors into one configuration because buildTypes mean difference in build configuration. BuildTypes should contain info about build proccess, e.g signconfigs, basic build flow configs etc.

flavorDimensions("devbeta", "mainmirror")
productFlavors {
    // Beta API enviroment
    beta {
        dimension = "devbeta"
        buildConfigField "String", "SOCKET_REMOTE_PATH", "\"/beta\""
    }

    // Dev API enviroment
    dev {
        dimension = "devbeta"
        buildConfigField "String", "SOCKET_REMOTE_PATH", "\"/dev\""
    }

    // Prod API enviroment
    prod {
        dimension = "devbeta"
        buildConfigField "String", "SOCKET_REMOTE_PATH", "\"/prod\""
    }

    mainhost {
        dimension = "mainmirror"
        buildConfigField "String", "CONFIG_REMOTE_HOSTNAME", "\"mainmirro1\""
    }

    mirrorhost {
        dimension = "mainmirror"
        buildConfigField "String", "CONFIG_REMOTE_HOSTNAME", "\"mainmirrow\""
    }
}

In this case possible build variants will be ...MainhostBeta MirrorhostDev etc.

dilix
  • 3,761
  • 3
  • 31
  • 55
  • Hi, I wrote that I think it is possible with dimensions, but I wonder if there is another approach too or not. Because I already have a 3D dimension, I prefer another approach if possible rather than adding 4th dimension... – Afshin Aug 06 '18 at 09:09
  • @Afshin you could config build type with another buildtype, check beggining of the answer, so in your case C could extend B – dilix Aug 06 '18 at 09:11
  • Yea,saw reply update. a question, when I use `initWith`, will resource directories changes to then one mentioned in `initWith` as base too? – Afshin Aug 06 '18 at 09:13
  • You could define any type of source dirs as you wish: https://stackoverflow.com/a/32758837/527808 using inherited folders should not work out of the box just because you could define your own folder for each buildtype. – dilix Aug 06 '18 at 09:24