Come configurare build variant in Android Studio

La flessibilità offerta da Gradle permette anche di creare delle build variant, 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.

In questo post, considereremo gli aspetti della configurazione Gradle che devono essere manipolati per permettere la creazione di più build variant, ad ognuno dei quali potrà essere fornito un insieme diverso di risorse, impostazioni e codice Java.

Build type e flavor

Una build variant è costituita dalla congiunzione di un build type e di un flavor. 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.

Se ne trova traccia nel file build.gradle del modulo:

android {
...
...
buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
...
...
}

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 {...} all’interno del nodo buildTypes {…}.

Anche la creazione di un flavor si risolve in un nodo di tipo productFlavors, da inserire all’interno del blocco android sebbene esternamente a quello di tipo buildTypes:

android {
    ...
    ...
    buildTypes {
                 ...
                 ...
               }
    productFlavors {
        firstFlavorName {
            ...
            ...
        }
        secondFlavorName {
            ...
            ...
        }
    }
}

dove al posto delle stringhe firstFlavorName e secondFlavorName andrebbero indicati i nomi che si vogliono assegnare.

A dimostrazione del fatto che un build variant è composto dall’incrocio di un build type e di un flavor, si noti che anche il suo nome risulta dalla concatenazione del nome di un flavor con quello dei vari build type. Vediamo subito degli esempi.

Risorse diverse nei vari build variant

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 e full – e supponiamo di voler un layout con sfondo rosa nel primo e viola nel secondo.
Procediamo così:

nel file build.gradle del modulo inseriamo la definizione dei flavor con eventuali impostazioni che potrebbero interessarci:

productFlavors
            {
                demo{
                    applicationId="it.devapp.esempiobuildvariants.pink"
                    versionName="1.0-pink"
                }

                full{
                    applicationId="it.devapp.esempiobuildvariants.purple"
                    versionName="1.0-purple"
                }
            }

sincronizziamo il progetto con i nuovi file di gradle;
creiamo ulteriori cartelle di risorse, a partire dalla cartella src del modulo, all’interno delle quali inseriremo le sole risorse che variano da un flavor all’altro. Nel nostro caso, predisporremo solo una risorsa colore di nome sfondo (la figura seguente riporta la visualizzazione Project):
infine, per fare in modo che la risorsa venga presa in considerazione la assegniamo all’attributo background della nostra app in relazione al layout che abbiamo fissato.

I Build Variant creati potranno essere consultati nel relativo pannello che si apre cliccando sull’etichetta Build Variants, in basso a sinistra nell’interfaccia di Android Studio:

Aprendo il file di layout dell’Activity – per noi, activity_main.xml – noteremo nell’anteprima la differenza di colore di sfondo.

Questo nel caso di un Build Variant con flavor demo:

e questo nel caso di un Build Variant con flavor full:

Diversificare i sorgenti

Oltre a fornire risorse diverse, le build variant possono distinguersi per funzionalità e per questo motivo è necessario predisporre classi con il medesimo nome in flavor diversi.

Immaginiamo che si voglia fare in modo che all’avvio dell’Activity – solo nel flavor demo – venga presentata una finestra di dialogo che porti a conoscenza che si sta guardando una versione non full del software. Dovremo creare due classi MainActivity nelle cartelle relative ai due flavor ma facendo attenzione a non mettere una classe con lo stesso nome sotto la cartella main: ciò produrrebbe un errore di classe duplicata.

Aggiungendo il seguente codice Java nel metodo onCreate della MainActivity presente sotto la cartella demo:

new AlertDialog.Builder(this)                                         
        .setMessage("Attenzione: versione DEMO dell'app!")            
        .setPositiveButton("Chiudi", null)                            
        .show();

all’avvio dell’app in una build variant con questo flavor verremo accolti dal seguente messaggio:

Ciò non avverrà passando ad una build variant con flavor full e lanciando l’app. Tra l’altro notando il colore dello sfondo, si vede che è rosa (reso più scuro dall’apparizione della finestra di dialogo) che dimostra ulteriormente che è stato utilizzato il flavor demo.

Conclusioni

L’utilizzo delle build variant dimostra come l’introduzione di Gradle in Android Studio sia stato davvero un potenziamento importante considerando la flessibilità nella configurazione che permette. Soprattutto, un aspetto molto interessante consiste nella semplicità sintattica delle direttive da fornire nei file build.gradle per diversificare i comportamenti: per il resto si tratta per lo più di una riorganizzazione di file e cartelle.