L’avventura con Android inizia, seguendo pedissequamente le istruzioni presenti nel sito dedicato al progetto, con Java in primis (spesso già presente) e poi l’IDE che bisogna caricare e installare, o decomprimere da qualche parte, come nel caso di Eclipse, che non richiede quest’operazione a cui siamo normalmente abituati.
L’SDK si scarica molto velocemente, ma ciò che fa perdere parecchio tempo (anche una mattinata) è la fase di scaricamento e installazione delle varie versioni delle piattaforme (API Level) e componenti vari. Sarebbe stato meglio avere un pacchetto completo con tutti i componenti (magari una ISO), dando poi la possibilità di scegliere ciò che si vuole, anche in prospettiva di un’eventuale reinstallazione.
Installato tutto, incluso l’apposito plugin per l’IDE, purtroppo il primo impatto è stato negativo: non veniva visualizza l’apposita voce per creare un progetto Android, pur risultando tutto correttamente configurato.
Fortunatamente esisteva un plugin per NetBeans, il mio IDE preferito, per cui ho potuto proseguire senza difficoltà, anche se questa piattaforma non è quella ufficialmente supportata dalla casa madre.
Il plugin per NetBeans non è comodo e completo come quello di Eclipse, mancando soprattutto una finestra/pannello di anteprima dell’interfaccia grafica a cui si sta lavorando, ma la bontà di quest’ambiente di sviluppo mi ha permesso di andare avanti ugualmente.
Successivamente ho voluto provare l’ultima versione di Eclipse con la quale, inspiegabilmente, risultava tutto finalmente operativo (misteri dell’informatica):
Quindi ho potuto sperimentare con la finestra di anteprima, che per i layout più semplici consente di sistemare gli elementi grafici senza dover ricorrere all’emulatore oppure a un dispositivo per poter prendere visione della resa finale.
Purtroppo per layout più complicati si rivela del tutto inutile, presentando uno sconfortante pannello vuoto. Mi riferisco, in particolare, a situazioni come la progettazione degli elementi visualizzati da una ListView. L’introduzione di placeholder (“segnaposto”) sarebbe già un grosso passo avanti, poiché consentirebbe di dare almeno una forma agli “item”.
Anche la disposizione del pannello di impostazione delle proprietà di un widget sarebbe da ripensare, in quanto adesso risulta più veloce modificare a mano l’XML piuttosto che spostarsi col mouse a caccia dell’apposita voce. Debbo dire che da programmatore preferirei non staccare le mani dalla tastiera, per cui se l’editing dell’XML che definisce l’interfaccia fosse più avanzato si otterrebbe senz’altro un risultato più appagante.
La più grossa pecca della piattaforma di sviluppo è, però, rappresentata dall’emulatore, che è un autentico pachiderma: anche su macchine “pompate” (una con Intel Core i-5 2,67Ghz, 8GB DDR3, e Radeon 4550 dovrebbe esserlo) impiega diversi minuti prima di divenire operativo, presentando peraltro una reattività appena sufficiente allo scopo (sempre su PC ben carrozzati, s’intende).
Una volta avviato è bene non chiuderlo mai, proprio per evitare questi lunghissimi tempi morti che trasformerebbero lo sviluppo in un supplizio tecnologico. Il tool è, infatti, in grado di accettare nuove istanze delle nostre applicazioni in tempi molto più rapidi.
In ogni caso è caldamente consigliato l’uso di un dispositivo reale anche economico, da collegare tramite porta USB, per lavorare molto più velocemente. In mancanza di un PC dotato è praticamente indispensabile, ma è sempre bene testare l’applicazione con un telefonino, perché si potrebbero scoprire bug che con l’emulatore magari non si manifestavano (ciò vale per qualunque piattaforma mobile).
Dopo aver installato l’SDK, normalmente dovrebbe essere sufficiente collegare il telefonino per renderlo visibile al PC e, soprattutto, all’SDK per utilizzarlo al posto dell’emulatore. Sfortunatamente ciò non è sempre vero, a causa di un bug nel driver in dotazione all’SDK, e ovviamente non poteva che presentarmisi. La soluzione in questo caso è di patchare il file android_winusb.inf (che si trova in extras\google\usb_driver), e forzarne manualmente l’uso quando il s.o. richiede di ricercare o selezionare il driver da qualche fonte.
Sempre rimanendo sul tema emulatore, a volte s’impalla e non è possibile lanciare l’applicazione perché viene generato il seguente errore:
emulator: ERROR: the user data image is used by another emulator. aborting
La soluzione in questi casi è cancellare alcuni file di lock (che si trovano in una cartella utente), cancellare la virtual machine e ricrearne un’altra, uccidere il processo adb.exe (il server che gestisce la comunicazione con emulatore o dispositivo), o ancora chiudere e far ripartire l’IDE. Sono tutti consigli che si possono recuperare in giro, quando si è alla disperata ricerca di una soluzione a questo problema. Qualcosa prima o poi dovrebbe funzionare, anche nel caso in cui, inspiegabilmente, alcune volte il debugger perde la connessione con l’emulatore o il telefonino…
Per concludere, aggiungo che di recente ho effettuato un aggiornamento all’SDK, avendo rilevato la presenza di alcuni pacchetti aggiornati (erano presenti quelli della nuova API Level 13, ad esempio), e il risultato è stato il seguente:
Altre volte a caccia di bug si è presentato il seguente messaggio fra i log:
E/dalvikvm( 2480): Unable to open stack trace file ‘/data/anr/traces.txt’: Permission denied
A parte il fatto che percorsi del genere mal si sposano con il s.o. utilizzato (e con le sue politiche di gestione dei dati privati e/o pubblici), trovo davvero deplorevole che a fine 2011 continuino a esserci problemi di permessi facendo uso di account limitati (che dovrebbero essere la norma da tempo, ormai), costringendo a ricorrere all’esecuzione come amministratore del gestore dell’SDK per portare a compimento l’operazione.
A completamento è apparso qualche altro problema e un piccolo difetto dovuto a una codifica dei caratteri non corretta (sic.):
Nonostante tutto, l’aggiornamento non è andato a buon fine:
Col risultato di essere stato costretto a cercare l’eseguibile dell’emulatore (si trova nella cartella tools dell’SDK), e lanciarlo da linea di comando specificando il nome del Virtual Device pur di vederlo finalmente all’opera…
Sono tante piccole cose, che però messe assieme danno fastidio e, cosa più grave, fanno perdere tempo a chi ne ha veramente poco a disposizione. Per un programmatore è importante affidarsi a strumenti comodi e solidi, che rendano veloce e produttivo lo sviluppo senza tanti mal di testa.
Non v’è dubbio che l’obiettivo finale sia mettere in mano all’utente finale un prodotto che soddisfi le sue esigenze, ma è altrettanto vero che chi deve realizzare quei prodotti dovrebbe essere in grado di farlo nel “migliore” dei modi. Pertanto mi auguro, da persona che deve lavorarci, che Google investa di più su questo fronte, su cui, a mio avviso, c’è ancora parecchio da fare.
