1.4 – Processo di sviluppo per applicazioni Android
SDK 4.x per vari sistemi operativi: Windows, Linux, Mac OS X Osservando
il contenuto del pacchetto software, possiamo notare che Google fornisce molteplici strumenti di supporto come add-on, driver USB, esempi e documentazione offline e anche SDK di terze parti (ad esempio gli SDK
40
proprietari di Sony e Samsung). Ovviamente, essendo le applicazioni Android scritte in linguaggio Java, la macchina su cui installeremo l’Android SDK dovrà poter compilare il codice, quindi possedere il kit di sviluppo Java JDK 5 o JDK 6 (non basterebbe disporre esclusivamente dell’ambiente esecutivo JRE, Java Runtime Environment). Le diverse versioni del kit di sviluppo
Android sono disponibili all’indirizzo
http://developer.android.com/sdk/index.html (James & Nelson, 2010). Dopo
averne eseguito l’installazione, possiamo aggiungere il direttorio, dove abbiamo estratto gli strumenti di sviluppo, alla variabile d’ambiente PATH in modo da poterne usufruire da riga di comando, da qualunque posizione nel filesystem ci trovassimo.
Passiamo ora in esame le principali sotto-cartelle dell’archivio generale che abbiamo scaricato per esaminarne le caratteristiche:
Add-on: contiene i classici componenti aggiuntivi come ad esempio le API aggiuntive di Google.
Platforms: questa cartella, inizialmente vuota, andrà a contenerne altre per tutte le rispettive versioni della piattaforma (ad esempio ci saranno due cartelle separate per la versione 10 delle librerie, Gingerbread, e la più versione un po’ più recente 15, Ice-Cream Sandwich e l’ultima release 16, Jelly Bean).
Platform-Tools: cartella che compare con l’installazione di particolari piattaforme e che contiene degli strumenti aggiornabili con ciascuna piattaforma.
Tools: contiene una serie di strumenti di sviluppo e di analisi, indipendenti dalla piattaforma usata per quanto riguardo il loro aggiornamento o utilizzo stesso.
SDK Manager e AVD Manager: sono rispettivamente due strumenti utili a
lanciare l’SDK, con la possibilità di decidere successivamente quali pacchetti scaricare e installare; o a gestire gli AVD (Android Virtual Device). Tramite questi agenti è possibile anche configurare alcune impostazioni aggiuntive come il Server Proxy.
41
Dopo aver installato l’Android SDK con i relativi pacchetti e piattaforme, siamo abilitati a creare applicazioni Android; le quali, tuttavia, non potranno essere eseguite fino a quando non avremo generato anche un Android
Virtual Device (AVD). Questo interessante simulatore riproduce, e mette a
disposizione dell’ambiente di sviluppo, tutte le caratteristiche di un dispositivo reale, ma eseguito sulla nostra macchina da lavoro. Durante la creazione di questo strumento, bisogna tuttavia assicurarsi che la piattaforma di destinazione abbia un livello API uguale, o superiore, al livello di API richiesto dalle applicazioni che ci appresteremo a testare, o semplicemente eseguire, tramite questo specifico AVD. Ognuno di questi dispositivi virtuali rappresenta un terminale indipendente con propria connessione, memoria per i dati utente, schede di memoria e quant’altro. Android supporta 16 diversi dispositivi in esecuzione contemporanea (per i quali è fortemente consigliato il supporto della virtualizzazione hardware). Ai vari dispositivi sarà assegnato un numero di porta pari, per permetterne la connessione e l’accesso a Internet, partendo dalla 5554. Il successivo numero di porta verrà invece sempre assegnato al relativo Android Debug Bridge (ADB).
42
Figura 12 - Il simulatore appena avviato
1.4.2 – Android Debug Bridge
La gestone degli emulatori, o eventualmente di dispositivi reali collegati alla macchina di sviluppo per eseguire test, può essere fata da un tool chiamato
Android Debug Bridge (adb); un versatile strumento a riga di comando
(shell, con molti comandi simili a quelli usati in ambienti Unix) che si mette in comunicazione con uno specifico dispositivo. È un programma Client/Server fondamentalmente composto da tre diversi agenti: un Cliente in esecuzione sul computer di sviluppo; un Server, in esecuzione in background sulla stessa macchina, che garantisce la comunicazione tra il Client e il
Demone adb in esecuzione sull’emulatore in background anch’esso. Lo
strumento è reperibile all’interno della cartella <sdk>/platform-tools/.
All’avvio di un Client adb, esso controlla in primo luogo se vi è un processo Server adb, in esecuzione, per avviarlo qualora non ci fosse. All’avvio, il Server invece si collega alla porta locale TCP 5037 mettendosi in ascolto dei
43
comandi inviati dai Clienti adb i quali utilizzeranno tutti la porta di default 5037 per comunicare con il Server. Inoltre esso provvede al settaggio di tutte le opzioni riguardanti le connessioni con ogni emulatore/dispositivo collegato scansionando le porte assegnate dal sistema operativo (5555-5585). Se il Server trova un demone adb, imposta una connessione verso quella porta. Ricordando la regola sull’acquisizione dei due numeri di porta consecutivi da parte degli emulatori facciamo un breve esempio di come operano:
Emulator 1, console: 5554 Emulator 1, adb: 5555 Emulator 2, console: 5556 Emulator 2, adb: 5557 Device 1, console 5558 Device 1, adb 5559 …
Una volta superato il passaggio di connessione, possiamo inviare messaggi di controllo alla shell per controllare le diverse istanze da qualsiasi Client o tramite script. La riga di comando di invocazione è la seguente: adb [-d|-e|-s
<serialNumber>] <command>; il parametro –s serve se siamo in presenza
di più istanze di emulatori: adb -s emulator-5556 install helloWorld.apk. Possiamo interrogare lo strumento, a proposito del numero di emulatori/dispositivi collegati, in questo modo: adb devices, che genererà un output simile:
$ adb devices
List of devices attached emulator-5554 device emulator-5556 device emulator-5558 device…
44
È possibile eseguire tutte le operazioni necessarie da riga di commando, ma vediamo in seguito come operare con un più comodo ambiente integrato.
1.4.3 – Eclipse
Qualora fossimo abituati a lavorare in un ambiente di sviluppo integrato (Integrated Development Environment), possiamo avvalerci del valido plug- in disponibile in Eclipse. Per prima cosa bisogna controllare che la versione di Eclipse che ci apprestiamo a installare sia compatibile tanto con l’Android SDK, quanto con il plug-in che integra l’SDK con il nostro IDE, l’Android
Development Tools (ADT).
Sebbene sia possibile sviluppare applicazioni Android in Eclipse senza l’uso del plug-in ADT, il suo utilizzo agevola il processo di sviluppo, rendendolo più veloce e più facile da testare. Questo particolare componente aggiuntivo ci consente di creare velocemente nuovi progetti Android compilando automaticamente una versione standard dei file di base di cui abbiamo bisogno; inoltre ci collega con utili strumenti di sviluppo, come, ad esempio, il DDMS (Dalvik Debug Monitor Server), che consente di gestire il nostro dispositivo di debug direttamente dall’IDE Eclipse, abilitandoci ad esplorarne il filesystem, scattare screenshot (foto della schermata) e trasferire file. Grazie a questa configurazione, disponiamo anche di un editor di file XML, utile nella composizione del manifest file, dei layout e di altre importanti risorse del nostro progetto. Sarà anche possibile, alla fine del processo di sviluppo, esportare automaticamente la nostra nuova applicazione in un file installabile .APK (Application Package) firmato, distribuibile agli utenti.
Il plug-in è reperibile da internet tramite la procedura di installazione di nuovo software all’interno di Eclipse, indicando come repository quella di Google https://dl-ssl.google.com/android/eclipse/. Nelle ultime versioni dell’SDK è inclusa anche una versione di Eclipse Juno preconfigurata con il plugin adt pre-installato.
45