approfondiremo il tutto piano piano, con un po di tempo e pazienza,rimetteremo mano a tutte le pagine e articoli ,così la nebbia sparirà e vedremo un cielo più limpido.
Sentiamoci nel frattempo questa melodia prima di iniziare
Una volta installato android studio creiamo un nuovo progetto dal menu file,e scegliamo empty activity.
analizziamo i file di Gradle
Gradle non compila le applicazioni android ,ma dà delle indicazioni per la futura compilazione.
Noteremo tra i tanti file due file uno è settings.gradle dentro è elencato il modulo
principale del programma ma potremo trovare elencati altri moduli aggiuntivi,poi troviamo build.gradle qui sono elencate alcune informazioni come la compatibilità dell’app e le
librerie che servono per compilare .
Proviamo ora ,dal menu file,a importare un nuovo modulo ,apriamo il file setting.gradle e vedremo
che oltre alla dicitura app compaiono altre diciture riferite ai nuovi componenti.
Questa funzione e’ molto importante ,infatti alcuni sviluppatori come GABRIELE MARIOTTI mettono
a disposizione le loro librerie sul web ,sono bellissime vi invito a provarle.
Qui puoi installare la sua demo provala! vedremo in seguito come fare.
Android studio file gradle
Il lettore prenda queste informazioni cosi come sono,facendo finta di fare una lettura leggera approfondiremo il tutto piano piano, con un po di tempo e pazienza,rimetteremo mano a tutte le pagine e articoli ,così la nebbia sparirà e vedremo un cielo più limpido.
Se apriamo il file build.gradle nella directory app,notiamo alcune voci:
-compileSdkVersion è il software con cui android compila
– buildToolsVersion è la versione del software precedente
– applicationId è il pacchetto di riferimento per play store nell’eventualità che dovremmo pubblicare l’app è una voce molto importante perchè le classi java fanno riferimento al proprio pacchetto.
– minSdkVersion 14 è il software minimo affincè l’app giri sul telefono ,telefoni che hanno un sdk inferiore ad esempio 13 non vedranno l’applicazione su play store
-targetSdkVersion 22 è la versione sdk preferita
-versionCode è la versione dell’app viene usata da play store per capire se quell’applicazione deve essere aggiornata o meno.
-buildTypes in questa sezione possiamo impostare vari modi di compilare l’applicazione.
minifyEnabled false non elimina le risorse non usate .
proguardFiles imposta un file per offuscare il codice.
E’ utile in fase di sviluppo ,se vogliamo provare delle classi ma non
vogliamo inserirle in fase finale.
Aggiungiamo allora a buildTypes una nuova directory di nome prova
prova.initWith(buildTypes.debug)
prova{
applicationIdSuffix “.prova”
versionNameSuffix “-prova”
buildConfigField “String”,”PROVA_URL”,”\”https://ultimaprovaprimadi.altervista.org\””}.
Facciamo un rebuild dell applicazione ,nella colonna di sinistra clicchiamo buildvariant e noteremo che oltre alla variante debug e release vi è anche la variante prova.
Se vogliamo testare una classe e non includere essa in fase di release,creiamo
una cartella prova e all interno di essa creiamo una cartella java che contiene la struttura del nostro package ma non i suoi file.
Praticamente non so come farlo,sicuramente c’è un comando in android studio
,ma io ho risolto cosi:tasto destro su cartella src ,creo una nuova directory,
a quel punto mi verrebbe di riprovare per creare lo stesso package che c’è in main ,ma non me lo dà.Allora mi sono spostato nella cartella java di main ,ho creato un nuovo package ,gli ho dato un nome ,poi taglia e incolla su prova
e infine con refractor ho rinominato il package.
A questo punto teoricamente e praticamente perché l’ho verificato, le classi di prova vedono quelle del main ma non possono modificarle,invece per le risorse string a il file manifest viene fatto una fusione merge,ma non per i layout e le immagini.
Questo è il file build.gradle:
apply plugin: ‘com.android.application’
android {
compileSdkVersion 25
buildToolsVersion “25.0.1”
defaultConfig {
applicationId “org.altervista.ciromelody.myapplication”
minSdkVersion 14
targetSdkVersion 22
versionCode 1
versionName “MystateChangeActivityprova”
testInstrumentationRunner “android.support.test.runner.AndroidJUnitRunner”
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
}
prova.initWith(buildTypes.debug)
prova {
applicationIdSuffix “.prova”
versionNameSuffix “-prova”
buildConfigField “String”, “PROVA_URL”, “\”https://ultimaprovaprimadi.altervista.org\””
}
}
/* productFlavors {
huawei {
applicationId “org.altervista.ciromelody.myapplication.huawei”
versionCode 2
versionName “2.0”
}
altri {
applicationId “org.altervista.ciromelody.myapplication.altri”
versionCode 1
versionName “1.0”
}
}*/
}
dependencies {
compile fileTree(dir: ‘libs’, include: [‘*.jar’])
androidTestCompile(‘com.android.support.test.espresso:espresso-core:2.2.2’, {
exclude group: ‘com.android.support’, module: ‘support-annotations’
})
compile ‘com.android.support:appcompat-v7:25.+’
compile ‘com.android.support.constraint:constraint-layout:1.0.2’
testCompile ‘junit:junit:4.12’
}
Da buildVariant selezioniamo prova e compiliamo ,se clicchiamo su android monitor nella barra di stato noteremo che il pacchetto è cambiato ,si è aggiuntola voce prova.
In poche parole con lo stesso codice possiamo lavorare su due pacchetti diversi.
scarica lo snipett e compila
Notate l’istruzione : if(getPackageName().equals(“org.altervista.ciromelody.myapplication.prova”)){
ClasseProva test=new ClasseProva(this);
test.metodo();}
}
l’istruzione if racchiude un riferimento a ClasseProva quando cambiamo il buildVariant da prova a debug o release a,android studio
segnala un errore