{"id":12506,"date":"2017-05-29T18:19:22","date_gmt":"2017-05-29T16:19:22","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=12506"},"modified":"2017-05-29T18:19:52","modified_gmt":"2017-05-29T16:19:52","slug":"configurare-build-variant-in-android-studio","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/configurare-build-variant-in-android-studio\/","title":{"rendered":"Configurare build variant in Android Studio"},"content":{"rendered":"

La flessibilit\u00e0 offerta da Gradle permette anche di creare delle build variant<\/em>, versioni diverse della medesima app all’interno dello stesso progetto. Se ne possono immaginare vari casi di utilizzo come la produzione di una versione demo ed una completa, una gratuita e una a pagamento e molti altri ancora.<\/p>\n

In questo post, considereremo gli aspetti della configurazione Gradle che devono essere manipolati per permettere la creazione di pi\u00f9 build variant, ad ognuno dei quali potr\u00e0 essere fornito un insieme diverso di risorse, impostazioni e codice Java.<\/p>\n

Build type e flavor<\/h2>\n

Una build variant \u00e8 costituita dalla congiunzione di un build type<\/strong> e di un flavor<\/strong>. Per quanto riguarda i primi, al momento della creazione di un nuovo modulo, ne vengono creati due in automatico da Android Studio: i build type release e debug.<\/p>\n

Se ne trova traccia nel file build.gradle del modulo:<\/p>\n

android {\r\n...\r\n...\r\nbuildTypes {\r\n        release {\r\n            minifyEnabled false\r\n            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'\r\n        }\r\n    }\r\n...\r\n...\r\n}<\/pre>\n
Gli attributi che vengono inseriti al loro interno rappresentano un diverso atteggiamento del build type rispetto a quello di default. Se, ad esempio, volessimo inserire un aspetto differente per il build type debug ci basterebbe inserire un blocco debug {...}<\/code>\u00a0all’interno del nodo buildTypes {…}<\/em>.<\/p>\n
Anche la creazione di un flavor si risolve in un nodo di tipo productFlavors<\/em>, da inserire all’interno del blocco android<\/em> sebbene esternamente a quello di tipo buildTypes<\/em>:<\/p>\n
android {\r\n    ...\r\n    ...\r\n    buildTypes {\r\n                 ...\r\n                 ...\r\n               }\r\n    productFlavors {\r\n        firstFlavorName {\r\n            ...\r\n            ...\r\n        }\r\n        secondFlavorName {\r\n            ...\r\n            ...\r\n        }\r\n    }\r\n}<\/pre>\n
dove al posto delle stringhe firstFlavorName e secondFlavorName andrebbero indicati i nomi che si vogliono assegnare.<\/p>\n
A dimostrazione del fatto che un build variant \u00e8 composto dall’incrocio di un build type e di un flavor, \u00a0si noti che anche il suo nome risulta dalla concatenazione del nome di un flavor con quello dei vari build type. Vediamo subito degli esempi.<\/p>\n
Risorse diverse nei vari build variant<\/h2>\n
Immaginiamo che per qualche motivo vogliamo che una nostra app abbia un colore di sfondo diverso a seconda del flavor che stiamo considerando. Definiamo pertanto due flavor – assegniamo loro nomi tipici per esempi di questo tipo come demo<\/em> e full<\/em> – e supponiamo di voler un layout con\u00a0sfondo rosa nel\u00a0primo e viola nel\u00a0secondo.
\nProcediamo cos\u00ec:<\/p>\n