Ok, so benissimo cosa staranno pensando i mei amici/colleghi che mi conoscono come un Apple dipendente …e decantare i pregi di un sistema operativo per palmari alternativo ad iPhone OS, dovrebbe rientrare in quel meccanismo di auto-censura che spesso mi vieta di divulgare, ad esempio, la mia passione per le Spice Girls 😀 (…ops, l’ho detto)
Ma ci tengo a chiarire subito che:
- Questo post, anche se dai presupposti ironici, è tutt’altro che “leggero” (cercherò di illustrare anche alcuni dettagli sull’architettura delle applicazioni per Android, dopo aver sviluppato qualche applicazione di test)
- Android NON è il sistema operativo anti-iPhone (ma rischia di diventarlo)
…e proprio da quest’ultimo punto voglio partire: pensare che i dispositivi che montano Android siano in concorrenza con iPhone, a mio avviso, è come pensare che un qualunque set di hardware con un sistema operativo Open Source sia in concorrenza ad un iMac con Snow Leopard 🙂 (ma in fondo a questo post ci sono un po’ di considerazioni che possono cambiare le cose…)
Il punto è proprio questo e, man mano che snocciolerò la mia idea, sarà ancora più chiaro: Android è un sistema operativo, basato su kernel Linux 2.6, corredato di un middleware (ovvero un sistema di accesso alle singole caratteristiche hardware/software del dispositivo su cui è installato) che consente l’esecuzione di applicazioni…applicazioni sviluppate in Java, che sfruttano dati e servizi di Google, che però vale la pena descrivere nel dettaglio del loro ambiente di esercizio:
Android, come dicevo, è un sistema operativo basato su kernel Linux…pertanto tutto il sottosistema di driver e adapter, i servizi, ecc sono sviluppati in C++ e compilati, assieme al kernel, per eseguire su dispositivi conformi all’architettura hardware definita e condivisa dall’ Open Handset Alliance.
I dispositivi conformi a questo standard di architettura hardware vanno dai più semplici telefonini a palmari con display multitouch ai prossimi tablet pc…e questo è il motivo per cui, secondo me, pensare ad Android OS come ad un concorrente di iPhone OS ha poco senso.
O meglio, che Apple, ad esempio, possa integrare una versione customizzata di Mac OS X nel prossimo (?) tablet come ha fatto per l’ iPhone, è una possibilità ma, a mio avviso, la linea di sviluppo di una versione custom del loro sistema operativo tende a spingersi nella direzione del dispositivo stesso… come dire: ad ogni dispositivo nuovo, corrisponde una specifica personalizzazione del sistema operativo dove Apple (bravissima in questo) sviluppa nuove interfacce utente e meccanismi di human interaction via via più specifici.
Che poi questi dispositivi diventino degli ottimi prodotti (prima) e delle ottime piattaforme di sviluppo (poi), nonché delle galline dalle uova d’ora (se si pensa al fatturato dell’App Store)…questo è, secondo me, il maggior merito attribuibile a Steve Jobs ed all’ottimo marketing di Apple.
Android non è questo e, tornando all’architettura del sistema operativo, è per l’appunto un sistema che, ad un livello di astrazione più alto, fornisce tutte le librerie di accesso a funzioni vitali per lo sviluppo di qualsiasi applicazione (dai programmi di gestione personale, ai giochi): viene fornito agli sviluppatori il supporto a librerie grafiche (una versione di Open GL, pensate un po’…), a SQLite per i database, Freetype per il rendering e il pluri-premiato WebKit per il browser web.
Le applicazioni per Android sono sviluppate in Java e, a dirla tutta, richiedono l’installazione di Eclipse, di un sdk, di un plug-in di Eclipse, la configurazione di un emulatore…non proprio affascinante come X-Code per iPhone e tutti gli strumenti forniti dai Developer Tools di Apple, con tanto di tool di debug dalla grafica accattivante (anche qui, Apple sa ammaliare anche gli sviluppatori 🙂 ).
Le applicazioni vengono compilate e racchiuse in pacchetti con estensione .apk (mentre su iPhone, ci sono i file .ipa).
…ma prima di andare più nel dettaglio di una tipica applicazione Android, un’ultimo sguardo all’ambiente di esecuzione: ogni applicazione, di default, viene eseguita in una sua Virtual Machine (un po’ differente dalla sandbox di iPhone), su un unico processo Linux, cui viene assegnato un unico userId…questo vuol dire che ogni applicazione è, da un punto di vista esecutivo, isolata dal resto delle altre, scongiurando eventuali interruzioni derivate da segnali generati da un medesimo utente (e su questa considerazione, mi spiace, ma un corso di Sistemi Operativi è propedeutico 🙂 ).
Ciò non è tassativo, è possibile anche fare in modo che più applicazioni condividano userId e virtual machine, per ovvii motivi di concorrenza (se richiesta dall’applicazione) ma anche per una questione di performance (non dimentichiamoci che, per ogni processo, viene eseguita una virtual machine…).
Com’è fatta l’architettura di una applicazione Android ?
Un’applicazione Android si basa su 4 componenti:
- Activities: ovvero ciò che descrive il flusso di esecuzione delle singole funzionalità dell’applicazione. Esempio, un editor di testo avrà come sola attività quella di interagire con un area di testo modificabile (come una textarea, una textbox, ecc). Un programmino per leggere le previsioni meteo, invece, avrà come sola activity la rappresentazione di informazioni prelevate da una fonte.
Ciò che cambia in una activity è la view , ovvero l’attuale interfaccia che si presenta all’utente. Nel caso di un programmino di previsioni meteo, ad esempio, avremo per lo meno una view per rappresentare le previsioni ed un’altra per scegliere la località di cui ottenere le previsioni.
La presentazione delle view è gestita delle activites che, come un proiettore di diapositive, sceglie quale rappresentare (in funzione delle azioni dell’utente e/o del flusso di esecuzione)…in ottica MVC, le activities espletano il ruolo del controller (ma non solo).
- Services: ovvero servizi che possono essere avviati/interrotti, che non necessariamente devono essere sincronizzati con le activites. Il classico esempio è quello di un player di brani: il servizio di riproduzione di un brano è, di fatto, asincrono rispetto a ciò che l’utente fa (tipo scorrere playlist, leggere i testi dei brani, ecc). L’interazione con il servizi avviene allorquando l’applicazione (o un evento broadcast, come l’arrivo di una telefonata) ne altera lo stato.
- Broadcast receivers: un componente in ascolto rispetto agli eventi del sistema: una chiamata in arrivo, il livello della batteria scarica, ecc… (nulla di nuovo rispetto alla gestione degli interrupt dei processi Linux 😉 )
- Content providers: ovvero contenitori di dati resi disponibili nelle modalità più disparate e su dati di qualunque natura. Ad esempio, l’elenco dei contatti della rubrica è un content provider, l’elenco di nodi di un file XML contenente le previsioni meteo. Ogni content provider può specializzare il proprio modello dei dati e le modalità di get e/o set dei dati stessi (…qualcosa di molto simile al concetto di model ma più vicino ai Java Bean)
Ora, senza scendere ulteriormente nel dettaglio dei singoli componenti (tanto, per questo c’è un’ottima fonte di riferimento, la pagina di Application Fundamentals di Android), per completare il quadro sulla struttura di un programma Android e sulla sua esecuzione, basta sapere che:
- I Content Providers sono attivati/disattivati mediante degli oggetti chiamati Intents
- Le Activities ed i Services hanno anch’essi dei metodi/funzioni di controllo ma sono tipicamente di avvio/arresto o di acquisizione del controllo di esecuzione.
- Le modalità di esecuzione e i parametri relativi al funzionamento dell’applicazione (ad esempio, l’esecuzione in modalità portrait o landscape, il nome del programma, ecc) sono definiti in un xml (chiamato Manifest) …qualcosa di molto simile a quanto già presente nei progetti di applicazioni iPhone.
Ok, ma ora veniamo al sodo…
Come mai Android mi ha incuriosito, affascinato e spinto a dedicarvi del tempo a svilupparne applicazioni ?
Per la semplicità nello svilupparne applicazioni ? non direi 🙂 (ci si impiega del tempo solo a installare e configurare il tutto)
…semplice, perché “rischia” di diventare la piattaforma di riferimento di tutti i dispositivi mobile che non hanno alle spalle una accurata attività di ricerca e sviluppo in ambito di OS, come possono essere invece Apple, Nokia, e così via…non è una mia previsione, ma di fatto è già una scelta siglata nel momento in cui aziende come Motorola, HTC, Samsung, SonyEricsson, ecc hanno preso più o meno parte alla Open Handset Alliance.
Badate bene, ognuna di queste aziende di telefonini ci sta mettendo il proprio contributo (di recente ho visto il video dell’imminente SonyEriccson Experia X10…con una interfaccia veramente incredibile) : ognuna sta sviluppando le proprie GUI sfruttando le primitive di Android.
Ma quello che a me più interessa e che sta dando i primi frutti in virtù della vastità delle informazioni e dei servizi offerti da Google, è proprio la disponibilità out of the box di servizi/programmi che, tutti i possessori di dispositivi Android, avranno a disposizione, di volta in volta che Google li rende disponibili.
Una delle più recenti feature disponibili su Android 2.0 è, ad esempio, il programma di navigazione turn-by-turn, che consente di avere PRATICAMENTE GRATIS l’equivalente di un TomTom o Navigon per ottenere indicazioni GPS.
La vera svolta nella realizzazione di un servizio simile su dispositivi mobile è la possibilità di accedere alle informazioni che Google già possiede e che vanno, dalle mappe ai riferimenti e i contatti di attività commerciali, di persone che hanno condiviso in rete le proprie informazioni mediante microformati.
Questo vuol dire che, a differenza degli attuali software di navigazione su cellulari, sfruttando ad esempio anche il software Google Voice, potremo chiedere al nostro cellulare “portami al ristorante cinese più vicino”, come si vede in questo video.
Non finisce qui: provate a cercare un contatto in rubrica e Google suggest vi suggerisce il nome e cognome, eventualmente cercando riferimenti anche in rete.
Considerate pure la possibilità di aggiungere un contatto in rubrica, partendo da informazioni presenti in rete o arricchite dai profili di quest’ultimo sui social network.
Pensate alla possibilità di andare su un contatto e vederne, aggregate, tutte le sue attività in rete e sui social network (come promette il già citato SonyEricsson X10), ovvero, una VERA integrazione del nostro mondo digitale con il resto della rete, con i suoi servizi, i social network.
Per non parlare dei servizi push costantemente attivi per fornire in tempo reale: email, notifiche, aggiornamenti di notizie e dei tweet.
Tutto questo è Android: una piattaforma che in meno di un anno è passata dalla versione 1.0 alla 2.0 (e già hanno annunciato la 2.1) aggiungendo migliorie su migliorie ad un sistema operativo che, anche se oneroso in termini di risorse hardware (la maggior parte dei dispositivi montano CPU da 500MHz) e che, c’è da riconoscerglielo (ad Apple), strizza parecchio l’occhio alla filosofia (di Apple) “The touch is the new click” (prima dell’iPhone i palmari erano degli scomodi dispositivi da usare con un pennino).
In più le applicazioni sono in Java, scelta (credo) fortunata dato il numero di sviluppatori che già conoscono il linguaggio ed i framework MVC che ricalcano molto le scelte architetturali delle applicazioni Android.
Cambierei il mio iPhone per un cellulare Android ?
Hmmm…è dura: l’iPhone è dannatamente semplice, bello e, per quanto mi riguarda, è un iPod touch con telefono e gps…con un OTTIMO negozio di musica ed applicazioni online che mi permette di avere sul mio iPhone un brano che mi viene in mente, pochi minuti dopo averne ricordato il motivetto 🙂
Ormai sono un iTunes-dipendente, quindi la mia musica è naturalmente sincronizzata sul mio iPhone…ed ormai è naturale che sia così.
..certo, se qualcuno tira fuori un cellulare con:
- Risoluzione schermo doppia rispetto all’iPhone
- Maggiore velocità
- Autonomia almeno doppia rispetto all’iPhone (che fa al max 1h di conversazione)
- Integrazione con Google come sopra
- Prezzo contenuto
beh…a quel punto un pensierino ce lo faccio 😉
