Nella scorsa parte stavamo analizzando gli scopi e utilizzi dei valori targetSdkVersion e target framework in Xamarin.Android.
Come accennato questi valori servono per gestire il fatto che le nuove versioni di Android propongono non solo nuove funzionalità e nuovi template, ma anche in alcuni casi possono eliminare o modificare istruzioni e funzionalità preesistenti.
>> Osservazione 9
Il targetSdkVersion è usato solo a runtime, e indica la versione di Android per la quale la nostra app è ottimizzata.
Detto in altri termini dice qualcosa tipo
“Ehi, questa app l’abbiamo scritta e testata per Android versione Y, e sappiamo che con quella versione tutto funziona tutto alla grande”
Ovviamente si ha: Y = targetSdkVersion
Detta così in effetti non si comprende molto l’utilità di questo valore, ma Vi prego, andate avanti con la lettura e capirete cosa voglio dire. Inoltre questo è quello che troverete scritto su questo argomento in giro…..
Come più volte accenato in versioni successive di Android alcune chiamate API possono essere variate (cioè si può cambiare qualche comportamento) o addirittura alcune di queste possono proprio essere eliminate.
Però per evitare problemi di compatibilità Android “ci mette una pezza” ed è in grado di attivare tutta una serie di ausili per evitare al massimo problemi di retrocompatiblità.
Più in dettaglio se la versione di Android su cui gira la app è successiva a quella dichiarata nel valore di targetSdkVersion presente nel manifest della app stessa, allora il sistema operativo potrebbe attivare tutta una serie di ausili che preservano il comportamento nonchè la presenza delle API sicuramente presenti in questa versione.
Quindi in altri termini Android tenta di rendere disponibili chiamate e comportamenti presenti nella versione targetSdkVersion anche se queste sono eliminate o variate successivamente.
Detto in tecnichese: Android quando mette in esecuzione una app può o meno azionare dei “compatibility behaviors” per introdurre “forward compatibility”.
Quindi perchè far azionare questi ausili se non necessari ? Per evitarlo è sufficiente dare un valore sensato a targetSdkVersion.
Ma in pratica che valore dare ??
Semplice: come detto sopra occorre dare il valore della versione di Android del dispositivo su cui testiamo abitualmente e con successo la nostra app: nel caso in cui si usino più dispositivi è corretto assegnare quello che ha la versione maggiore.
Occorre dire qualcosa in più sui temi/template, che sono l’altra parte che entrano in gioco nella valutazione di targetSdkVersion.
Se a partire dalla versione di Android Y è stato introdotto un nuovo tema, allora questo sarà applicabile solo sulle app che hanno nel manifest un valore di targetSdkVersion >= Y.
Infatti quanto sottende a una scelta di questo genere è che potrebbe accadere che il tema in parola potrebbe portare problematiche ad app testate con versioni precedenti di Android.
Quindi in definitiva con il valore che occorre dare a targetSdkVersion si certifica che la nostra app è perfettamente in grado di funzionare in ogni sua parte, ivi compreno l’applicazione di temi, dalla versione midSkVersion sino a targetSdkVersion, e quindi se in esecuzione su versioni di sistema operativo in questo range non solo non è necessario azionare alcun compatibility behaviors, ma anche tutti i temi sono applicabili.
Chiaro no ? E’ come quando si esce con gli amici e si dichiara: io questa sera torno a casa con qualche numero di telefono di qualche bella ragazza….. e quindi è impossibile che qualcosa possa andare storto, poichè lo si è dichiarato pubblicamente, o no ?!
A quanto detto sopra occorre poi aggiungere alcuni casi particolarissimi di utilizzo del valore: per esempio anche se si è detto che il valore targetSdkVersion viene valutato solo in fase di runtime poichè inserito nel file file manifest dell’apk, in effetti ha il suo utilizzo anche in fase di creazione dell’apk (pacchetto di installazione della app), quando aapt (=asset packaging tool) esegue la sua parte.
Come noto aapt è delegato in fase di compilazione a mettere insieme le risorse e manifest, e in tal caso “dà uno sguardo” anche a targetSdkVersion e può decidere alcune cose in base al valore assunto da questo parametro.
Quindi esistono casi veramente particolari in cui per utilizzare particolari direttive nei file risorse occorre dare almeno un determinato valore al targetSdkVersion.
Ricordatevene la prossima volta che la Vostra app funziona alla grande in debug, ma la creazione dell’apk finale dà un errore bizzarro….
Spero di avere scritto cose comprensibili e, sopratutto, corrette: mi scuso in anticipo per eventuali strafalcioni, che Vi prego eventualmente di comunicarmi.
Grazie della lettura.
Linkografia
Android Developer Documentation: uses-sdk
Xamarin Android: Il grande mistero degli Android API Level – Prima parte
Follow