Google Nexus One: un flop ? …inaspettato ?

La notizia non è freschissima: sono circa 2 mesi che dai blog ufficiali di Google e del Nexus One si legge della scelta di Big G, relativamente alla interruzione della commercializzazione online del loro primo (e, probabilmente, l’ultimo ?) smartphone.

Qualche giorno fa un aggiornamento: in cui si legge che è proprio di questi giorni l’ultima consegna di dispositivi e che, una volta venduti, renderanno il prodotto non più acquistabile online.  (Notate bene, il comunicato si riferisce solo alla vendita online: il Nexus One resterà comunque acquistabile mediante i vari operatori telefonici, quali Vodafone, KT, ecc).

Nel blog ufficiale di Google, invece, si legge chiaramente che i dati di vendita online del dispositivo sono stati al di sotto delle aspettative, contrariamente alla diffusione di Android.

Effettivamente, i dati di vendita del Nexus One non sono stati proprio entusiasmanti: si parlava di circa 80 mila dispositivi venduti nel primo mese …numeri molto bassi se si pensa che il neonato iPhone 4 viaggia su 1 Milione di vendite/SETTIMANA nonostante il famoso “effetto mano”.

Ma voglio chiarire l’obiettivo di questo post: non intendo confrontare i due device né decantare le caratteristiche dell’uno a sfavore delle scelte di marketing dell’altro…piuttosto gettare le basi per qualche spunto di riflessione 😉

Fermo restando che, come ho sempre pensato, non basta il sistema operativo a rendere appetibile un prodotto (come per i PC non basta infilare schede in un case per fare un PC 🙂 e che il Nexus One, a mio avviso, non poteva diventare l’anti-iPhone, quello che a me fa riflettere, a valle della decisione di Big G, è l’approccio con il quale il gigante delle ricerche sul web abbia “sondato il terreno” del mobile.

Terreno molto battuto ultimamente e che, sono più che convinto, costituisca ormai il pensiero dominante dei colossi che di servizi e contenuti ne fanno il proprio business.

Ma facciamo un passo indietro: Google inizia a sviluppare un sistema operativo che finisce negli smartphone di Samsung, Motorola, ecc…sistema operativo che integra tutti i servizi di Big G e che, per poter contare su applicazioni custom, va nella direzione degli sviluppatori più smaliziati (sviluppo in Java, con installazione del SDK per Eclipse).

Poi realizza un dispositivo che, per il motivo di cui sopra, alimenta il desiderio degli utenti “geek” e tenta il grande passo commercializzando il prodotto, sia con gli operatori telefonici che mettendolo in vendita online.

Ma perché il Nexus One, probabilmente come gli altri dispositivi Android, non si diffonde con la stessa rapidità dell’iPhone ?

  • Difficoltà nello sviluppo delle applicazioni ? …a cominciare dal’ installazione della suite di sviluppo per Android ?Beh, sicuramente, a mio avviso, costituisce un deterrente per gli sviluppatori (magari quelli alle prime armi) dedicare almeno 1h del proprio tempo (o le prime 90 pagine di un famoso manuale per Android), solo per installare Eclipse+Android SDK…ma non credo affatto sia questo il punto 😉
  • Eterogeneità dei dispositivi (per citare il mio amico Gianfranco), per cui essendoci troppe varianti di cellulari Android, gli sviluppatori hanno difficoltà a lavorare su un dispositivo di riferimento ?Mah…probabilmente questo potrebbe creare qualche non banale problema di compatibilità di una stessa applicazione su dispositivi diversi: ma, se vogliamo, accade qualcosa di simile anche su iPhone/iPod touch a causa delle varie versioni tutt’ora in commercio (non vi dico quanto rosico per la mancanza della bussola sul mio iPhone 3G: non posso user le app di augmented reality!!! 🙂
  • Marketing totalmente differente ?Molto probabile, ma non credo che questo possa indurre in così poco tempo Big G a gettare la spugna sullo sviluppo di un device ad appena 6 mesi dalla commercializzazione.
  • Obiettivi differenti ?Ci siamo quasi 🙂 …ma allora perché commercializzare un prodotto, dotato di un sistema operativo veramente evoluto (perché come qualcuno che segue il mio blog ricorderà, io ne ho apprezzato ampiamente i pregi sul fronte tecnico).

OK, vi dico la mia: Android, incarnando tutti i servizi, compresa la ricerca di Google, si basa sulla FORNITURA DEI SERVIZI, NON DI CONTENUTI!!!

Ed è in quest’ultimo punto che secondo me c’è nocciolo della questione: la differenza sostanziale tra Google ed Apple, in questo settore, è che mentre il primo fornisce servizi e li estende al mobile mediante Android, il secondo ha catalizzato la vendita dei dispositivi basati sulla riproduzione di contenuti che, con iTunes Music Store (di cui App store ne è una naturale evoluzione), Apple rende accessibili su qualsiasi dispositivo, ivi compresi PC Windows.

Alla luce di questo, nonostante il Nexus One possa essere stato utilizzato (IMHO) come un cavallo di Troia pieno di robottini verdi, è fin troppo evidente la difficoltà di Google  nel innescare una azione di concorrenza ad un “dispositivo” Apple: sto pensando ai contenuti… per i servizi, invece, resto dell’idea che Google abbia tra le mani il più potente cluster al mondo su cui indicizzare contenuti, far girare applicazioni web e fare storage (se pensate a quanto spazio ci mette a disposizione per la sola Gmail 🙂 )

Del resto, nel comunicato del 14 Maggio scorso è chiaro che l’utenza cui Google si è rivolta con il proprio device, è interessata ad avere dei servizi, necessariamente legati ad un operatore di telefonia…

Quindi, se condividete la mia corrente di pensiero, convenite sul fatto che Google abbia cercato di promuovere ulteriormente Android con un dispositivo ? …la cui vendita non è andata benissimo, ok…ma se si guarda questa azione come una azione di marketing, probabilmente l’esito delle vendite di Nexus One diventano quasi trascurabili a fronte dell’obiettivo di promuovere Android, no ?!

Torniamo per un istante ad Apple: se guardiamo i dati relativi alle revenue per segmento di prodotto/servizio non è fin troppo evidente che, pochi mesi fa, la maggior parte del fatturato Apple derivava dalla vendita di dispositivi che fondamentalmente consentono la riproduzione, piuttosto che la creazione, di contenuti audio/video ?

Sono il solo che pensa che Apple, in definitiva, stia assecondato le esigenze degli utenti di creazione di contenuti in secondo luogo rispetto alla fruizione degli stessi ? …guardate l’iPad
…certo, è anche vero che sull’iPhone 4 si possono registrare e montare video in HD…ma è proprio di questi giorni la notizia che iTunes inizierà a vendere contenuti in alta definizione, proprio per il nuovo gioiellino.

…insomma, per quanto mi riguarda, sembrerebbe fin troppo evidente ciò che sta accadendo in questo momento epocale di lotta alla conquista delle tasche degli utenti (…ma che banali!!! 😀 …non mi riferivo al costo degli smartphone! …piuttosto a dove si tengono in genere: in tasca! ;))

…ma, a parte gli scherzi, questa è la mia idea (magari fantasiosa o amplificata dai fumi dell’alcol contenuto nel mio Jager con 2 cubetti di ghiaccio :D) , voi che ne pensate ?

[l’immagine è tratta da wired.com]

HTML5 e la geolocalizzazione

Una delle novità introdotte in HTML5 è la GeoLocation, ovvero la possibilità di ottenere dal browser le informazioni sulla posizione geografica dell’utente.

Funzionamento

In breve, come funziona: lo standard (per cui vi rimando alla pagina del W3C)  prevede che il browser possa esporre le coordinate geografiche dell’utente fornitegli dal sistema operativo su cui è installato, qualora quest’ultimo consenta di determinare la posizione geografica mediante antenna GPS o WiFi.

Pertanto, affinché un’applicazione web ottenga la posizione geografica, è necessario che il sistema operativo ed il browser supportino tale funzionalità.

C’è da dire, inoltre, che la richiesta della posizione geografica, da parte dell’applicazione web in questione, è sempre preceduta da una richieste esplicita fatta all’utente pertanto, sulla questione privacy, è l’utente a dover accettare esplicitamente di voler fornire al browser questo dato.

Sul discorso compatibilità dei browser: Safari e Chrome supportano pienamente le API per questa funzionalità (aggiunta di recente al draft di HTML5), altri browser potrebbero supportarla, magari con l’utilizzo di Modernizr , sull’uso di alcune istruzioni del CSS3) per cui vi rimando su diveintohtml5 (sito dalla grafica molto grunge ma pieno di spunti per avvicinarsi all’HTML5).

In realtà eseguendo l’esempio che riporterò a breve, potrete verificare direttamente se la vostra versione del browser supporta la geolocalizzazione.

Come utilizzarlo

Ma tornando sul pezzo: come facciamo ad utilizzare le api di HTML5 relative alla geolocation ?

Premesso che per le API applicative HTML5 richiedono l’uso di Javascript, per verificare la compatibilità del vostro browser relativamente a geolocation basterà inserire in una pagina il seguente script:

[sourcecode language=’js’]

[/sourcecode]

In questo esempio memorizzo in due variabili globali (latitudine e longitudine) i rispettivi valori mediante una callback.

Le API di GeoLocation non si limitano alla latitudine ed alla longitudine – nel momento in cui vi scrivo, infatti, sono previste le seguenti proprietà:

  • latitude
  • longitude
  • altitude (optional)
  • accuracy
  • altitudeAccuracy (optional)
  • heading (optional)
  • speed (optional)
  • timestamp

L’accuracy, ad esempio, si rivela molto utile per stimare il grado di precisione della lettura dei parametri latitudine e longitudine: se pensate di integrare sulla vostra web app la geolocalizzazione, con l’accuracy, ad esempio sarebbe utile riportare tale valore dato che, soprattutto in assenza di una antenna gps, la lettura della posizione potrebbe avere degli scarti anche dell’ordine di centinaia di metri.

Mentre scrivevo questo articolo mi sono, ovviamente, divertito a creare uno script leggermente più complesso, che visualizzi una Google Map con un marker sulla posizione rilevata dal browser.

Potete vedere qui lo script in azione 😉

Un dettaglio sul codice dell’esempio: nell’inclusione del javascript per la mappa di Google, ho disabilitato il sensor (che era un metodo alternativo di geolocalizzazione basato su Gears).

Inoltre, ho utilizzato tutti i parametri che è possibile passare alla funzione navigator.geolocation.getCurrentPosition:

  • la callback in caso di esito positivo della lettura della posizione
  • la funzione per l’esito negativo
  • l’array di opzioni (io ne ho inserite due: timeout della richiesta e flag sull’accuratezza della lettura)

Considerazioni

Non vi nascondo che sono sempre stato scettico sul fornire ad una web app la posizione geografica e, come me, gran parte degli utenti potrebbero avere delle remore a fornire queste informazioni durante la navigazione di un sito web.

In realtà esistono svariati contesti in cui la geolocation si rivela molto utile e, secondo me, è in quegli ambiti che può trovare applicazione:

Come raggiungerci

Pensate ad esempio alla classica pagina “Dove siamo/Come raggiungerci” di siti relativi ad esercizi commerciali – leggendo la posizione dell’utente gli si può presentare una mappa con il percorso per raggiungere in auto la vostra sede, cosa sicuramente più evoluta rispetto alla classica mappa.

Geotagging

Pensate a tutte le applicazioni di ugc (user generate content) dove pubblicare contenuti corredati di una posizione geografica può fare la differenza – geolocalizzare il contenuto o l’azione di pubblicazione del contenuto consente di sviluppare web app come quelle di Flickr e Twitter che basano alcune delle loro funzionalità sulla posizione geografica dei contenuti e che in questo caso verrebbero valorizzate senza ulteriore intervento da parte dell’utente.

Around me

Citando il nome di una famosissima app su iPhone, sfruttando la posizione geografica si potrebbero suggerire contenuti, servizi, esercizi commerciali e tutto quanto ci viene in mente, da quelli più vicini alla posizione dell’utente.

…provate a immaginare il tipo di applicazioni che potremo sviluppare quando a questa funzionalità si va ad aggiungere la ricerca semantica dei contenuti: potrei, ad esempio, cercare il negozio più vicino che vende un libro con un dato codice ISBN!!!

…incredibile, no ?! 🙂

HTML5 e tag video: l’inizio della fine per i player Flash ?

Ormai se ne parla un po’ ovunque: l’HTML 5 apporterà davvero tante novità, la maggior parte di queste, sicuramente diventeranno gioie e dolori per chi del web ne sviluppa le interfacce, chi realizza il markup…altri aspetti, altrettanto innovativi, danno origine a speculazioni di vario genere.

Ma prima di arrivare al punto, una piccola parentesi: dovete sapere che quando nel lontano 1996 Google non era ancora l’indice della Rete, una delle mie attività preferite sul web (oltre a scrivere un blog in inglese sulla realtà virtuale immersiva 🙂 ) consisteva nel praticare ore (notturne) di netsurfing selvaggio: semplicemente partendo da un sito che mi interessava, proseguivo senza alcun freno verso i link in uscita da quella pagina…questa attività, molto spesso, conduceva su pagine sperdute nella rete, dove mi ritrovavo a leggere di chissà quali argomenti.

Ebbene, nel corso degli anni (per motivi di facile comprensione), ho un po’ abbandonato questa pratica, ma capita che avendo sempre con me un “cellulare connesso alla rete” (se mi sentisse Steve Jobs… 🙂 ), di tanto in tanto riesco a riprovare questa esperienza.

Di recente, infatti, sono incappato in un sito dove il tema principale è l’approccio all’imminente html5 ( Dive Into HTML5 ) e, in particolare, mi ha colpito la completezza con cui vengono descritti i protocolli di codifica, le questioni di licenze annesse e connesse e le alternative open per realizzare e riprodurre contenuti video su pagine conformi al nuovo standard.

Di cosa si tratta: in poche parole, con l’avvento dell’HTML 5, sarà possibile inserire video all’interno delle pagine html utilizzando un tag (<video>, per l’appunto), esattamente come avviene ora per le immagini (mediante il tag <img>).
Attualmente, invece, l’inserimento di un contenuto video in una pagina html prevede l’inclusione di un oggetto (il player) preposto alla riproduzione dei video: negli ultimi anni, infatti, la diffusione di player video in Flash hanno fatto la fortuna di progetti com YouTube e Vimeo e, in virtù della loro notorietà, aumentato enormemente la diffusione di contenuti video in rete.

Di pari passo con la diffusione di player Flash per i video, è altrettanto diffuso proprio il formato di codifica dei video compatibile con Flash: l’FLV (FLash Video).

Attualmente, per inserire un player flash e riprodurre video flv in una pagina html, infatti:

  1. I video da riprodurre vanno convertiti (o transcodificati, come direbbe il mio prof di Elaborazione Numerica dei Segnali 🙂 ) nel formato FLV
  2. Il player (che di fatto è un programma flash, compilato, con estensione .swf) va reso disponibile sul server
  3. All’interno della pagina html dove inserire il video (ed il relativo player), vanno aggiunte le istruzioni di embed necessarie ad informare il browser che dovrà eseguire un programma, in flash, con determinati parametri (il percorso del file al punto 2 e, generalmente, anche il percorso del video .flv al punto 1)
  4. L’utente deve avere installato un plug-in per eseguire nel browser applicazioni flash (come le animazioni, i banner animati…i player flv)

…ed è proprio su quest’ultimo punto che vorrei soffermarmi: fermo restando che qualunque contenuto video, affinché sia “riproducibile”, in un modo o nell’altro, prima o poi, andrà transcodificato e che, anche sull’inserimento di tag nella pagina non ne possiamo fare a meno, ciò che attualmente è legato alla specifica tecnologia (di riproduzione) utilizzata, richiede:

  • L’esistenza di un player sul server
  • L’esistenza di un plug-in sul client

Questo è quanto accade ora, con Flash.

…e qui arriva la mia speculazione: se HTML5, con l’avvento del tag <video> ed il relativo demand al browser della scelta del miglior player (disponibile dal sistema operativo), per riprodurre filmati non solo in flv ma anche (e, credo, soprattutto) in H.264, in un certo senso tenderà a “liberare” la questione dell’embed di video dai punti 2 e 4 dell’elenco di sopra,
è plausibile che il predominio di Flash, per la riproduzione di video, ne sarà influenzato ?

La mia risposta è: FORSE, soprattutto perché se è vero che convertire e riprodurre video in FLV non è esente da costi/condizioni di licenza a favore di Adobe, la situazione non è molto differente se, anziché usare Flash Video, si usa Windows Media, QuickTime e persino H.264 (come riporta quell’articolo su DiveIntoHtml5)…ovviamente esistono soluzioni open e questo scenario, magari, farà da cassa di risonanza proprio ai formati di codifica open source.

Ma la considerazione immediatamente successiva è quella relativa all’accesso dei dispositivi dotati di browser web, sinora sprovvisti di plug-in per Flash, a contenuti video su pagine conformi allo standard HTML5:

In questo momento, ad esempio, la versione di Safari per iPhone non supporta Flash in quanto Adobe non ha rilasciato un plug-in che consenta al gioiellino di casa Apple di riprodurre filmati Flash e, di conseguenza, player .flv qualora questi siano presenti nelle pagine…

Ma il motivo per cui sto spostando l’attenzione di questo post sul discorso mobile non è casuale 🙂

…vediamo se riesco a rendere l’idea:

  • Attualmente un Nokia N97, ad esempio, a differenza di altri palmari, può riprodurre contenuti Flash ed ha un supporto di terze parti (Adobe) a contenuti quali Flash e Pdf
  • Google, anni fa ormai, acquista YouTube: decisamente il più diffuso portale di video sul web…che sinora usava esclusivamente Flash
  • Ma Google sta sviluppando Android quindi, al pari di YouTube, potrebbe ritrovarsi a “dipendere” da una tecnologia proprietaria (non sua 🙂 ) per riprodurre filmati sul browser dei dispositivi dotati di Android

…e ora un po’ di domande:

  1. Che succede se YouTube inizia a sposare la causa dell’HTML 5 e, magari in poco tempo, iniziare a testare i video in HTML5 a scapito di Flash Video ?
  2. E’ un caso che Chrome (il browser di Big G, alla base anche del futuro Google OS) sia basato su WebKit, attualmente il framework per lo sviluppo di client web che meglio supporta HTML5…e che questo framework sia lo stesso su cui è basato Safari (sia su Mac che su iPhone) ?
  3. E’ un caso che su YouTube sia costantemente suggerito l’uso di Chrome ? (ovviamente, il primo motivo per farlo è quello di risicare quote di utenti a IE, Firefox ed altri…ma, secondo me, il motivo è più profondo…)
  4. Se Google (e tutti i progetti in suo possesso) ed Apple non avranno più necessità della tecnologia di Adobe, in virtù dell’alternativa derivante dall’utilizzo di HTML5 per il supporto del video sul web, chi ne trarrà i maggiori benefici ?

Personalmente piuttosto che addentrarmi nelle speculazioni su risvolti commerciali, mi piace concentrarmi sull’effetto che un simile ipotetico scenario avrà sui dispositivi che tutt’ora utilizziamo e che, ancora di più, avremo magari in tasca, in borsa, in ufficio e con cui accederemo alla rete nei prossimi mesi:

il mio MacBook Air non potrà che ringraziare se anziché stressare i due core del processore per far andare un player flash, demanderà l’esecuzione dei contenuti video, anche in HD, a Quartz e fratelli 🙂

Insomma, dal punto di vista dell’utente, io credo che i cambiamenti (soprattutto se nella direzione degli standard) non possano che produrre miglioramenti e, cosa piuttosto usuale sul web, favorire l’open source a scapito di tecnologie proprietarie…ma dov’è che l’utente davvero ci guadagna ?! sicuramente quando le aziende, man mano che prendono coscienza di tale processo, si staccano dal concetto di royalty a favore dei servizi da poter offrire: IMHO su questo Big G è davvero lungimirante,
staremo a vedere.

Android, ovvero Google in mobilità

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:

  1. 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)
  2. 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:

  1. 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).
  2. 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.
  3. 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 😉 )
  4. 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:

  1. I Content Providers sono attivati/disattivati mediante degli oggetti chiamati Intents
  2. 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.
  3. 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 😉

Il lato oscuro della rete…

Ci riflettevo l’altra sera, davanti una pizza (pesantissima) e una birra (rossa rigorosamente): si parlava del più e del meno, su come il web si sia evoluto in questi anni, su come una semplice tesi sia diventato il motore di ricerca più famoso sul web…e su come i social network stiano cambiando le abitudini e gli stimoli dei fruitori della rete.

…e fin qui tutto bene: il punto è che, tralasciando le visioni in pieno stile da film di spionaggio, viene da fare alcune considerazioni su come alcuni strumenti in rete abbiano ormai dissacrato l’unico vero patrimonio umano (visto che ormai anche quello genetico è noto :)… LA PRIVACY.

E’ incredibile: lo stesso inventore di Napster, del primo software peer to peer, si inventa un social network con l’obiettivo di “collegare” persone (Facebook)…peccato che poi ci si lascia prendere la mano e si iniziano a pubblicare foto, esprimere i propri giudizi, partecipare a sondaggi, dare il proprio consenso a cause “virtuali”, ecc…insomma, su Facebook ormai c’è tutto ciò che consente di profilare l’identità di coloro che utilizzano il web.
Per carità, trovo GENIALE l’idea di aver concepito un social network in cui siano gli utenti a creare l’applicazione, è geniale quanto è incredibile che Accettando i termini del servizio… ci si iscriva ad un network che profila la tua identità e che va a braccetto (visto che, nelle logiche di Google, Facebook è uno dei siti più Trust al mondo) con il motore di ricerca che di fatto detta le regole su come debba essere il web.

…e già che ci siamo, vogliamo parlare proprio di Google?! Anch’io uso Gmail, la mia rubrica e il mio calendario sono su Google: in quanto utente ho un servizio ineccepibile (Gmail è a quota 7GB per la posta) ma l’idea che un’unica azienda detenga le comunicazioni, le abitudini, i contatti di centinaia di milioni di persone…beh, a me fa un po’ riflettere.

Cos’è che attualmente potrebbe minare il masterplan di Google? beh, gli utenti non connessi, quelli che continuano ad essere scollegati dalla rete (semmai ce ne siano), in generale, coloro che la propria digital life la tengono ancora archiviata sui loro PC.

Nessun problema, anche questi ultimi si convinceranno a fare il grande salto quando vedranno che con il loro cellulare possono scrivere documenti, elaborare fogli di calcolo, far vedere le loro foto a parenti e amici (o magari a compagni del liceo).

I tempi cambiano, ma l’obiettivo di chi ha successo è sempre lo stesso: ottenere il controllo!

… Troppo catastrofico?!?!?!? 🙂

naaaa…giusto uno spunto di riflessione, meglio andare a lavare la macchina va… 😉