Nell’ articolo di oggi prima di iniziare a vedere i vari componenti e servizi offerti da Android per lo sviluppo di applicazioni, vogliamo rispondere ad alcune domande dei nostri lettori che ci hanno fatto, e invece di rispondere singolarmente a ogni domanda abbiamo deciso di farci un articolo in modo da chiarire un po il concetto a tutti i nostri lettori.
Vi consigliamo prima di leggere gli articoli precedenti per chi non l’avesse già fatto.
Per il momento tra le domande che ci hanno fatto, abbiamo ritenuto alcune importanti per continuare lo sviluppo di un applicazione Android a livello base,mentre per le altre domande che ci sono arrivate, cercheremo di dargli una risposta durante le prossime lezioni del corso.
Ecco le domande scelte:
- Che cos’è Android ?
- Che cos’è la Dalvik Virtual Machine ?
- Comè fatta l’architettura di Android ?
Cos’è Android
Nel primo articolo del corso, abbiamo dato una definizione in modo superficiale di che cosa è Android, oggi vogliamo andare un pò più nello specifico.
Android non è un linguaggio di programmazione, ma un vero e proprio stack di strumenti e librerie per la realizzazione di applicazioni mobili. Esso ha come obiettivo quello di fornire tutto ciò di cui un operatore, o uno sviluppatore hanno bisogno per raggiungere i propri obiettivi.
Android ha la fondamentale caratteristica di essere open, viene considerato open perchè:
- Utilizza come vedremo meglio successivamente, tecnologie open, prima fra tutte il kernel di Linux nella versione 2.6.
- Le librerie e le API che sono state utilizzate per la sua realizzazione, sono esattamente le stesse che andremo ad usare per creare le nostre applicazioni (non ci sono limiti alla personalizzazione dell’ambiente se non per alcuni casi legati alla sicurezza nell’utilizzo, per esempio, delle funzionalità del telefono.).
- il suo codice è open source, consultabile da chiunque possa contribuire a migliorarlo, lo voglia documentare o semplicemente voglia scoprirne il funzionamento.
La licenza scelta dalla Open Handset Alliance (http://www.openhandsetalliance.com) è la Open Source Apache License 2.0, che permette ai diversi vendor di costruire su Android le proprie estensioni anche proprietarie senza legami che ne potrebbero limitare l’utilizzo. Ciò significa che non bisogna pagare alcuna royalty per l’adozione di Android sui propri dispositivi.
Android e Java
Il linguaggio utilizzato da Android non sia un nuovo linguaggio che gli sviluppatori sarebbero obbligati a imparare, ma Java, quello descritto dalle famose specifiche rilasciate da Sun Microsystems e che utilizziamo dal 1995.
Java non è l’unico linguaggio fornito per noi sviluppatori da Google abbiamo due ulteriori strumenti per lo sviluppo di applicazioni per Android:
- Android Scripting Environment (ASE)
- Android Native Development kit (AND)
- Librerie esterne come PhoneGap
Il primo ha l’obiettivo di semplificare lo sviluppo delle applicazioni attraverso un linguaggio di scripting di alto livello, mentre il secondo si prefigge di sfruttare al massimo le potenzialità hardware del dispositivo nel caso di applicazioni che richiedono un’elevata capacità di elaborazione, mentre il terzo l’utilizzo di librerie esterne per la realizzazione di applicazioni come PhoneGap, è uno strumento di sviluppo open source, creato da Nitobi, per fare da ponte tra le applicazioni Web e i dispositivi mobili. ConPhoneGap possiamo scrivere un’applicazione mobile sfruttando HTML, Javascript e CSS, ma anche utilizzare le principali risorse del dispositivo, quali file system, fotocamera, accelerometro, gps o multitouch.
La scelta di Java ha però un risvolto in contrasto con quella che è la natura open di Android. I dispositivi che intendono adottare la Virtual Machine (VM) associata all’ambiente J2ME (JVM o KVM, come vedremo) devono pagare una royalty, cosa in contrasto con la licenza di Apache citata in precedenza.
Sarebbe come dire che Android può essere liberamente utilizzato, però non funziona se non dispone della VM di Sun la quale prevede il pagamento di una royalty. Se ci fosse poi bisogno di una KVM tanto varrebbe, come si vedrà quando confronteremo le due tecnologie, rendere Android un particolare profilo J2ME.
Ma come può Android eseguire bytecode Java senza l’utilizzo di una JVM?
La risposta è semplice: Android non esegue bytecode Java, per cui non ha bisogno di una JVM. Per ottimizzare al massimo l’utilizzo delle risorse dei dispositivi, Google ha adottato una propria VM che prende il nome di Dalvik (nome di una località in Islanda) sviluppata. Si tratta di una VM ottimizzata per l’esecuzione di applicazioni in dispositivi a risorse limitate la quale esegue codice contenuto all’interno di file di estensione .dex ottenuti a loro volta, in fase di building, a partire da file .class di bytecode Java. La natura open di Android impedisce inoltre l’utilizzo di tecnologie con un qualche vincolo di royalty.
Le librerie standard di Java utilizzate da Android sono la quasi totalità, escluse, non a caso, le Abstract Window Toolkit (AWT) e le Swing. La definizione dell’interfaccia grafica è infatti un aspetto fondamentale nell’architettura di Android, la quale utilizza un approccio dichiarativo come ormai avviene nella maggior parte delle attuali piattaforme di sviluppo. Infatti lo sviluppo di applicazioni per Android ricorda molto lo sviluppo di applicazioni con J2SE.
Che differenza c’è tra Android e J2ME?
Un’applicazione sviluppata in Java e compilata può essere eseguita, senza alcuna modifica, in ambienti con sistemi operativi diversi a patto che per questi esista una specifica Java Virtual Machine in grado di tradurre le istruzioni bytecode in codice nativo della piattaforma stessa.
Non tutte le applicazioni sono però uguali, sia dal punto di vista funzionale, sia, soprattutto, dal punto di vista non funzionale o architetturale. Un’applicazione desktop è diversa da un’applicazione web, la quale a sua volta è diversa da un’applicazione in esecuzione su un cellulare.
Ci si è accorti quindi della necessità di creare VM o ambienti diversi in grado di ospitare tipologie di applicazioni diverse. Ecco che sono stati definiti gli ambienti J2SE, J2EE e J2ME, ciascuno caratterizzato da una VM, librerie di runtime, delle API, della documentazione e soprattutto dei tool per lo sviluppo tra cui il compilatore, il debugger e l’interprete.
La J2SE è l’ambiente utilizzato per lo sviluppo di applicazioni desktop, mentre la J2EE contiene gli strumenti per la realizzazione di applicazioni denominate enterprise, cioè applicazioni che si interfacciano a (DBMS-DataBase Management System, WebService e SOA-Service Oriented Architecture). Sebbene queste siano dedicate a tipologie di applicazioni diverse tra loro, utilizzano una stessa JVM che può essere attivata secondo due modalità di esecuzione: una client e una server.
La modalità client è quella che favorisce l’aspetto di interazione dell’applicazione con l’utente attraverso una veloce esecuzione e gestione degli eventi.
La modalità server è invece quella che prevede un insieme di ottimizzazioni a livello di interpretazione del bytecode al fine di una gestione ottimale del multithreading.
Di queste due, e dato l’insieme di librerie che si utilizzano, la J2SE è quella che vedremo assomigliare di più ad Android. L’unica differenza, già accennata, riguarda le API per la gestione dell’interfaccia grafica, che Android gestisce in modo ottimizzato.
Infine, abbiamo la J2ME che descrive l’ambiente per l’esecuzione di applicazioni in dispositivi che il più delle volte vengono associati ai cellulari.
La VM di riferimento è la CDC Hotspot implementation, più nota con l’abbreviazione Compact Virtual Machine (CVM)
Il principale problema dell’ambiente J2ME dal punto di vista delle prestazioni è legato al fatto che si appoggia su una VM, la KVM, nata come sottoinsieme della JVM.
Del J2SE si è mantenuto, sia a livello di classi sia a livello di singolo metodo di una classe, tutto ciò che poteva essere eseguito in un device, e si è buttato via il resto. Non si è pensato quindi alla realizzazione di qualcosa che fosse specifico e ottimizzato per la tipologia di applicazione, come invece è avvenuto con Android.
Da tutto questo si capisce come il fatto che un’applicazione venga compilata per un particolare dispositivo non assicura che un altro sia in grado di eseguirla nello stesso modo. Ecco che se uno sviluppatore intende creare un’applicazione con la tecnologia J2ME, si dovrà preoccupare di verificare l’applicazione in tutte le famiglie di dispositivi che ritiene possano essere commercialmente interessanti.
La soluzione di Sun, a questo e altri problemi della J2ME, si chiama JavaFX. Si tratta di una tecnologia nata per la realizzazione di Rich Internet Application (RIA), attraverso l’utilizzo di un linguaggio di scripting chiamato JavaFX Script. Appoggiandosi a un linguaggio dichiarativo, JavaFX permette l’esecuzione delle applicazioni in ambienti diversi tra cui il browser, il desktop e i dispositivi mobili.
Il tutto, questa volta, senza alcuna effettiva modifica se non nella modalità di deploy dell’applicazione. Al momento esiste un’implementazione di tale ambiente su Windows Mobile.
La VM utilizzata da Android, è la Dalvik Virtual Machine, la quale presenta caratteristiche molto importantiche, attraverso una ossessiva cura del dettaglio, permette un ottimale utilizzo delle risorse a disposizione, come vedremo nel prossimo articolo.
L’articolo vi è piaciuto? avete domande ?
