On Sun, Nov 16, 2014 at 1:32 AM, Daniele Segato <[email protected]> wrote:
> > > On Saturday, November 15, 2014 10:23:01 PM UTC+1, Xavier Ducrohet wrote: >> >> 1. I'n not sure how a single buildConfigField is boiler plate. >> > > It's not the single buildConfigField a boilerplate. > > When you have many parameter to inject, with different values per variants > you end up with many buildConfigField. > > Each have the same data type and key. Meaning you duplicate your key on > multiple properties and your values spread across the build file in > different places. If you edit something you have to remember to edit > everywhere. > You can create local variables in your build script and uses this to synchronize the type and name of the resources. It's not as pretty, or object-oriented I suppose, as what you describe in https://code.google.com/p/android/issues/detail?id=73396 but it's good enough for 1.0 > > >> >> 2. the priority order if explained in the guide and applies to everything >> (resources, manifest overlays) >> It's Build Type > Flavors > default Config. >> >> So if you set the same buildConfigField in all 3, the build type will >> win, always >> > > oh, I see. sorry I missed this in the guide. Thanks. > > >> >> 3. This is not currently supported. You cannot have per-variant values. >> We take a combination of build type, flavors, defaultconfig and take the >> highest priority one. It's something we want to fix but no ETA. >> > > That's the main issue. > At least now I know it is not possible yet. > > Thank you very much for your replies and time. > Daniele > It'll be possible in the next version of the plugin to add per-variant buildConfig and resValues: android.applicationVariants.all { variant -> variant.buildConfigField "type", "name", "value" variant.resValue "type", "name", "value" } These ones will obviously have a higher priority than the ones set from the build type/product flavor/default config. > > >> >> >> On Sat, Nov 15, 2014 at 10:15 AM, Daniele Segato <[email protected]> >> wrote: >> >>> Thank you Mark. >>> >>> What I want is just a way to define buildField values more flexible >>> choosing the value by flavor / build type. >>> >>> I want to be able to set those values differently for every combination >>> of flavor and build type, possibly setting a default if I do not want to >>> override. >>> >>> The reason I want this are 3: >>> 1. having to set those value over and over again for each variant is >>> tedious and create lot of boilerplate code >>> 2. it is not straightforward to me how defaultConfig, variant config and >>> build type config relate with each other, if I set the same variable as >>> build config in all of them which is applied? the variant one? the build >>> one? >>> 3. I don't know how to have 4 different value for the combo free+debug, >>> free+release, pay+debug, pay+release (to simplify I just used 2 variant and >>> 2 build types as an example) >>> >>> Your message helped me understand better how gradle works, I still >>> didn't get it very well. >>> Now I understand all those setting are in evaluated in a phase that do >>> not yet have anything to do with the actual compile of a single variant. >>> And the code they contains is executed regardless of which variant I build. >>> But I still don't have any idea on how to solve the 3 things I wrote >>> about above. >>> >>> Thanks, >>> Daniele >>> >>> >>> -- >> Xavier Ducrohet >> Android SDK Tech Lead >> Google Inc. >> http://developer.android.com | http://tools.android.com >> >> Please do not send me questions directly. Thanks! >> > -- > You received this message because you are subscribed to the Google Groups > "adt-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
