Molti l’avevano previsto, alcuni hanno fatto finta di non vederla, Google l’ha negata con tutte le sue forze, ma alla fine e’ arrivata: la frammentazione della piattaforma Android.

Lasciando perdere la prima release e la versione 1.1 (ormai abbandonata in tutto il mondo, tranne che sugli HTC Dream venduti da TIM), la giostra delle versioni vede il succedersi della Cupcake (1.5), Donut (1.6), Eclair (2.0, 2.0.1 e 2.1) e Froyo (2.2). La 1.5 rappresenta un netto miglioramento di prestazioni rispetto alla 1.1 ed ha introdotto gli App Widget. La 1.6 ha visto il supporto a risoluzioni diverse dalla 320×480. La 2.0 ha introdotto multitouch, Bluetooth e tante cosette belline, facendo la sua comparsa sul Motorola Droid/Milestone e ricevendo una toppa al volo con la 2.0.1. Arriva poi il Nexus One, che porta in dote la 2.1, che tra le altre novita’ ha portato i Live Wallpaper. Finche’ si arriva al maggio di quest’anno, con la 2.2 per ora disponibile ufficialmente solo per il Nexus One.

Il primo problema e’ arrivato con il passaggio dalla 1.5 alla 1.6: la gestione delle risorse, infatti, ha richiesto il suffisso -v4 per fare in modo che il runtime 1.5 non si “perdesse” tra le risorse organizzate per diverse risoluzioni dello schermo. Dalla 1.6 alla 2.x sono arrivate tante nuove API, alcune hanno semplicemente cambiato package (di veda il caso Telephony). E anche dalla 2.0/2.1 alla 2.2 sono cambiate diverse cose, tant’e’ che il team di Google ha dovuto pubblicare ben tre articoli sul blog dedicato agli sviluppatori per salvaguardare portabilita’ e compatibilita’:

Backward Compatibility for Applications
http://developer.android.com/intl/zh-TW/resources/articles/backward-compatibility.html

Android Compatibility
http://developer.android.com/intl/zh-TW/guide/practices/compatibility.html

On Android Compatibility
http://android-developers.blogspot.com/2010/05/on-android-compatibility.html

Anche loro si sono trovati nella condizione di scrivere un’applicazione d’esempio che funzionava solo sulla 2.2:

“Several weeks ago we took a look at how to handle multitouch on Android 2.0 (Eclair) and above, and by the end we had a simple demo app. That app uses features exclusive to Android 2.2 (Froyo) which as of this writing hasn’t had a chance to reach many devices yet.”

How to have your (Cup)cake and eat it too
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html

Personalmente sono giunto a questa conclusione: non potendo trascurare la base installata di terminali 1.5/1.6 (alcuni dei quali sono ancora in vendita, vedi il LinkMe o il Magic, e non saranno mai aggiornati ad una 2.x) ma volendo allo stesso tempo guardare al futuro, puo’ avere senso fare DUE versioni diverse della stessa applicazione, una per Android 1.x e una per Android 2.x, avendo cura poi, su ciascuna build, di gestire le differenze intrinseche di ciascun subset (dunque la differenza tra 1.5 e 1.6 e tra le varie 2.x). E’ senz’altro uno sforzo considerevole, ma sarebbe comunque inutile avere uno spaghetti code che tenga conto di tutte le differenze, delle eccezioni di questa o quell’altra piattaforma. Questo e’ ancora piu’ vero quando si usano API particolari, come quella per il Bluetooth (ufficiale su Android 2.x, disponibile come progetto indipendente per Android 1.x). Non ultimo, i device 2.x hanno una maggiore quantita’ di memoria per singolo processo (solitamente 24MB al posto dei soliti 16MB) e dunque si possono usare strategie diverse nella gestione della memoria. A tendere, la versione 1.x sfumera’, mentre quella 2.x potra’ essere consolidata per far spazio alle nuove feature della piattaforma. Non dimentichiamo, infatti, che Gingerbread (3.0) e’ dietro l’angolo.

Poiche’ Android distingue le applicazioni in base al package name, ho deciso di lavorare in questo modo:

– la versione per Android 1.x ha package del tipo

com.qualcosa.qualcosaltro.NOME_APPLICAZIONE.android1

e nel Manifest e’ presente una dichiarazione che vincola SDK minimo e massimo:

<uses-sdk android:minSdkVersion=”3″ android:maxSdkVersion=”4″/>

– la versione per Android 2.x ha package del tipo:

com.qualcosa.qualcosaltro.NOME_APPLICAZIONE

(oppure com.qualcosa.qualcosaltro.NOME_APPLICAZIONE.android2)

e nel Manifest e’ presente una dichiarazione che vincola SDK minimo e imposta il target alla versione piu’ recente:

<uses-sdk android:minSdkVersion=”5″ android:targetSdkVersion=”8″/>

Probabilmente non e’ la soluzione migliore per tutti i progetti, sicuramente altri sviluppatori avranno elaborato strategie piu’ efficaci e che non comportano la gestione di due progetti separati. A me semplifica la vita perche’ mi consente di isolare i due mondi Android, eventualmente decidendo che una feature per una versione non e’ disponibile sull’altra, specie se lo sforzo del porting e’ eccessivo.