Perché i tipi di costruzione sono distinti dagli aromi dei prodotti?

Prefazione: questa non è una domanda su come utilizzare i tipi di build e le varianti di prodotto in un'app Android. Comprendo i concetti di base coinvolti. Questa domanda riguarda maggiormente il tentativo di capire quale configurazione deve essere specificata in un tipo di build, quale configurazione deve essere specificata in un sapore del prodotto e se è effettivamente necessaria una distinzione.

Questa settimana, ho imparato di più sulla configurazione gradle per le app Android. Inizialmente pensavo di avere una buona padronanza dei tipi di build rispetto ai gusti dei prodotti, ma più mi immergevo nella documentazione e più mi rendevo conto che la distinzione tra i due non mi era affatto chiara.

Poiché esiste una gerarchia ben definita (nel senso che le proprietà specificate nei tipi di build hanno la precedenza su quelle specificate negli aromi di prodotto), non capisco perché sia ​​necessario distinguere tra tipi di build e aromi di prodotto. Non sarebbe meglio unire tutte le proprietà e tutti i metodi nell'oggetto DSL di sapore del prodotto e quindi trattare il tipo di build come una dimensione di sapore (predefinita)?

Alcuni esempi concreti che hanno portato alla mia confusione:

• La signingConfigproprietà può essere impostata sia nei tipi di build che nei gusti del prodotto ... ma minifyEnabled(e, suppongo shrinkResources,?) Può essere configurata solo nei tipi di build.

• applicationIdpuò essere specificato solo nei gusti dei prodotti ... e applicationIdSuffixpuò essere specificato solo nei tipi di build !?

Le domande reali :

Dati gli esempi precedenti: esiste una chiara distinzione tra i ruoli dei tipi di build e quelli dei prodotti?

In tal caso, qual è il modo migliore per capirlo?

In caso contrario, il piano è infine quello di unire tipi di build e sapori del prodotto in un singolo oggetto DSL configurabile?

Espandendo ciò che @CommonsWare ha detto nei commenti, l'idea di base è che i tipi di build sono per build diverse dell'applicazione che non sono funzionalmente diverse: se si dispone di un debug e di una versione di rilascio dell'app, si tratta della stessa app , ma uno contiene codice di debug, forse più registrazione, ecc. e l'altro è ottimizzato e ottimizzato e probabilmente offuscato tramite ProGuard. Con i sapori, l'intento è che l'app sia notevolmente diversa in qualche modo. L'esempio più chiaro sarebbe una versione gratuita rispetto a una versione a pagamento della tua app, ma gli sviluppatori possono anche differenziarsi in base a dove viene distribuita (il che potrebbe influire sull'utilizzo dell'API di fatturazione in-app).

Ci sono sviluppatori che realizzano molte, molte versioni diverse di un'app simile per clienti diversi - un esempio potrebbe essere una semplice app che apre una pagina Web in una vista Web, con URL e branding diversi per ogni versione - questa è una buon uso dei sapori.

Per ribadire, se si tratta della "stessa applicazione", modulo alcune differenze che non sono importanti per l'utente finale, e soprattutto se tutte le varianti tranne una sono per uso personale di test e sviluppo e verrà distribuita solo una variante utenti finali, quindi è un buon candidato per i tipi di build. Se si tratta di un'applicazione "diversa" e più varianti verrebbero distribuite agli utenti, allora forse è un candidato per un sapore del prodotto.

Hai già visto che ci sono alcune differenze di funzionalità tra tipi di build e sapori, in quanto alcune opzioni sono supportate per l'una ma non per l'altra. Ma i concetti sono diversi anche se simili, e non esiste un piano per unirli insieme.

buildType configura come impacchettiamo la nostra app

• shrinkResources
• progaurdFile
• eccetera.

Flavor configura diverse classi e risorse.

• in Flavor1 MainActivity può fare qualcosa e in Flavor2 implementazioni diverse

• nome dell'app differente

• eccetera.

Ogni sapore del prodotto può avere i propri valori delle seguenti proprietà, tra le altre, che si basano sulle stesse proprietà di defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Ecco come distillare la differenza fino alla sua essenza:

• buildTypeè il come della build.
• flavorè la cosa della build.

La build typessono usati per indicare debug/releasela modalità con differenti certificati e abilitazione Proguardo debuggablebandiera.

Il flavorsvengono utilizzati per avere funzioni personalizzate (ad esempio gratuitamente o versione a pagamento), minimum and target APIrequisiti di livelli, dispositivi e API, come la layout, drawablein modo da poter avere il codice e le risorse differenti in differenti flavors.