C'è un modo per avere una sezione comune con buildConfigField e resValue in gradle?

Ho un prodotto con più sapori di prodotti come:C'è un modo per avere una sezione comune con buildConfigField e resValue in gradle?

buildTypes { 
    debug { 
    } 

    release { 
    } 

} 

productFlavors { 
    flavor1 { 
     buildConfigField "String" "country" "se" 
     buildConfigField "String" "language" "sv-SE" 
     buildConfigField "String" "appName" "Flavor1" 
    } 
    flavor2 { 
     buildConfigField "String" "country" "se" 
     buildConfigField "String" "language" "sv-SE" 
     buildConfigField "String" "appName" "Flavor2" 
    } 
    flavor3 { 
     buildConfigField "String" "country" "se" 
     buildConfigField "String" "language" "sv-SE" 
     buildConfigField "String" "appName" "Flavor3" 
    } 
    flavor4 { 
     buildConfigField "String" "country" "se" 
     buildConfigField "String" "language" "sv-SE" 
     buildConfigField "String" "appName" "Flavor4" 
    } 
    flavor5 { 
     buildConfigField "String" "country" "se" 
     buildConfigField "String" "language" "no-NO" 
     buildConfigField "String" "appName" "Flavor5" 
    } 
}

io preferirei una sezione comune con tutte le proprietà e solo ignorare coloro che sono diversi. È possibile?

Vorrei anche mettere tutti i sapori (e forse buildTypes) nel proprio file per renderlo più leggibile. Quindi ogni volta che devi cambiare un aroma, puoi facilmente trovarlo nel suo file e non dover scorrere migliaia di righe che saranno se avrò tutti i sapori e buildTypes insieme a tutto il resto nel file di build principale.

fonte

2014-09-23 peuhse

'defaultConfig' – Selvin

ho pensato che, ma sembra disordinato aggiungere resValues e buildConfigFields a quella sezione. Ma forse è l'unico modo. Che ne dici di spostarlo in un file separato? – peuhse

'debug' e' release' di 'buildTypes' dovrebbero fare anche il trucco, ma devi mettere i valori in entrambi ... comunque perché è disordinato? la configurazione di default conterrà valori predefiniti ... su più file ... non lavoro mai con em – Selvin

Selvin è corretto, utilizzare la chiusura defaultConfig - non esiste un modo più ordinato! Nell'esempio seguente, sapori 1, 2 & 5 impostare il paese e la lingua predefiniti su de. Flavors 3 & 4 sostituisce questo con le proprie lingue.

defaultConfig { 
    buildConfigField "String", "country", "de" 
    buildConfigField "String", "language", "de" 
} 

buildTypes { 
    debug { 
    } 

    release { 
    } 
} 

productFlavors { 
    flavor1 { 
     buildConfigField "String", "appName", "Flavor1" 
    } 
    flavor2 { 
     buildConfigField "String", "appName", "Flavor2" 
    } 
    flavor3 { 
     buildConfigField "String", "country", "uk" 
     buildConfigField "String", "language", "en_GB" 
     buildConfigField "String", "appName", "Flavor3" 
    } 
    flavor4 { 
     buildConfigField "String", "country", "fr" 
     buildConfigField "String", "language", "fr" 
     buildConfigField "String", "appName", "Flavor4" 
    } 
    flavor5 { 
     buildConfigField "String", "appName", name.capitalize() 
    } 
}

NOTA

Solo una cronaca che è possibile utilizzare name.capitalize() per trasformare il nome di qualsiasi sapore, ad esempio, flavor5, nel nome dell'app Flavor5 utilizzando il metodo capitalize(), che capitalizzerà il primo carattere nella stringa. Tuttavia, questo DEVE andare nel sapore, non defaultConfig

fonte

2014-10-20 22:26:31

C'è un modo per avere una sezione comune con buildConfigField e resValue in gradle?

risposta

Problemi correlati