Android SDK

Jeff LaMarche e’ un programmatore e autore attualmente impegnato nello sviluppo di applicazioni per iPhone e Mac, nonche’ autore di un seguitissimo (e autorevole) blog e del libro “Beginning iPhone Development”.
Riportiamo in questa pagina la traduzione dell’articolo Android SDK from an iPhone Developer’s Perspective. Ringraziamo Jeff per averci concesso l’autorizzazione a riportare la traduzione del testo integrale.
Riconosciamo l’onesta’ intellettuale di Jeff nel sostenere che le sue opinioni sono polarizzate da un amore sviscerato per l’ambiente di sviluppo per iPhone. Nonostante cio’ condividiamo in gran parte le sue affermazioni e siamo perfettamente d’accordo con lui nel ritenere l’SDK per Android meritevole di attenzione se non altro per le sue enormi potenzialita’ di sviluppo.
Vi lascio adesso alla lettura del testo, davvero istruttivo.

Ho gia’ riportato la mia opinione sul dispositivo Nexus One (leggi l’articolo originale oppure la nostra traduzione delle parti salienti). E’ arrivato il momento di veder le cose dal punto di vista della programmazione. E’ arrivata quindi l’ora per una mia opinione sull’ambiente di sviluppo (SDK) di Android.

Permettemi di cominciare dicendo un’ovvieta’, dato che conosco alcune persone che dimenticheranno quanto segue: sto per formulare la mia opinione personale e assolutamente soggettiva riguardo l’SDK di Android. Questa opinione puo’ differire dalla vostra, e questo va bene. Veramente. E’ proprio cosi’. La terra continuera’ a girare anche se voi pensate che io mi stia sbagliando al 100%.

Permettetemi anche di porre in evidenza i miei punti di vista: io non amo Java. Ho usato Java per molto piu’ tempo di Objective-C e ho tutto sommato fatturato molte piu’ ore e guadagnato molto piu’ denaro usando Java piuttosto che Objective-C, ma dal momento in cui ho letto i volumi sul linguaggio e la programmazione in Objective-C, negli anni 1997 e 1998, ho avuto l’impressione che Java stesse intraprendendo la direzione sbagliata. Ogni passo nell’evoluzione di Java ha rinforzato questa sensazione. L’approccio usato in NextSTEP (il quale si e’ evoluto in Cocoa e quindi Cocoa Touch) avvalora il mio pensiero. Io credo in questo approccio. Sia la metodologia che il linguaggio mi piacciono cosi’ tanto, infatti, che ho preferito tagliare i miei guadagni in maniera sostanziosa pur di poter lavorarci sopra a tempo pieno. Cosicche’, basandovi su questo, dovreste capire che Android parte gia’ svantaggiato dal mio punto di vista.

Ho cercato di rimandare il piu’ possibile la pubblicazione di questo articolo per evitare di cadere nell’errore commesso da molte persone con l’SDK di iPhone e Xcode, che e’ quello di scrivere un articolo relativamente al fatto che non funziona nella maniera che desidero io e che quindi non va bene. Dato che ho una notevole esperienza con il linguaggio e l’ambiente di sviluppo (IDE) e dato che ho gia’ alcune settimane alle spalle con l’SDK di Android, posso tranquillamente fornire un’opinione che non e’ esclusivamente una mia protesta per il fatto che non e’ quello che io so fare e che mi piace fare, anche se ovviamente il fatto che faccia molte cose in una maniera che a me non piace certamente influisce sulla mia opinione.

Quindi, dopo aver speso diverse settimane con Android, cosa ne penso?

Sicuramente non e’ male. E’ decisamente un SDK potente. Ha quasi tutto quel che ti serve e, essendo basato su Java, esiste una quantita’ notevole di codice e di librerie su cui fare affidamento. Il progetto dell’SDK e’ un tantino inconsistente (tutto sommato come l’esperienza del sistema operativo). Vi sono alcune parti che ricordano l’iPhone SDK molto da vicino, per quanto possibile date le differenze tra i linguaggi, e vi sono altre parti del tutto aliene.

Vi e’ sicuramente una mancanza di consistenza nella progettazione dell’SDK se confrontata con quella di iPhone. Molte parti dell’SDK sembrano scritte da gruppi completamente differenti che non necessariamente hanno comunicato o si son messi d’accordo sul modo migliore di far le cose. Vi sono alcune inconsistenze anche nell’SDK di iPhone, ma ci sono comunque dei principi guida e dei design pattern cosi’ dominanti nell’iPhone SDK che non hanno una controparte in Android. L’effetto finale e’ un Android un po’ caotico e disunito, ma comunque ancora valido.

Android ha anche un compito difficile da assolvere: esso e’ stato progettato per girare su una vasta gamma di dispositivi e si puo’ sviluppare su molti sistemi operativi e molte macchine. Google ha fatto un lavoro davvero ammirevole date le difficolta’ che occorre affrontare quando non hai opzioni hardware limitate e sulle quali hai il pieno controllo.

Uno dei modi in cui e’ stato affrontato il problema e’ stato nella realizzazione dell’emulatore. E’ possibile configurare l’emulatore per simulare differenti dispositivi con differenti caratteristiche e dimensioni dello schermo, permettendo quindi di impostare diversi dispositivi virtuali. Cio’ significa che puoi testare la tua applicazione su un “Nexus One virtuale”, quindi passare a un nuovo dispositivo virtuale a testarla su un “Motorola Droid virtuale”. Lavorare con l’emulatore e’ facile, ma non tanto quanto come il simulatore di iPhone. Ad esempio, quando lanci un’applicazione sull’emulatore, esso non diventa l’applicazione corrente e l’emulatore non si sblocca automaticamente. Ad ogni modo l’esperienza e’ accettabile, specialmente se si tengono conto delle sfide aggiuntive dovute al fatto che si tratta di una piattaforma aperta.

La stessa applicazione eseguita sul dispositivo ha girato molto bene. Sorprendentemente bene, in effetti. Ancora, l’esperienza non e’ agevole come quella di lanciare un’app sull’iPhone. Ci si imbatte in piccoli inconvenienti, ad esempio quando esegui un programma sul dispositivo il telefono non si sveglia o si sblocca cosi’ come fa l’iPhone. Ma alla fin fine esso lavora piuttosto bene e senza il peso di dover fornire profili di distribuzione o certificati di sviluppo.

Ho scoperto che il debugging su Android non e’ affatto agevole, ma questo magari e’ dovuto al fatto che conosco GDB molto meglio di JDB/ADB (Android Debugging Bridge) e che conosco le potenzialita’ di debugging di Xcode molto meglio di quelle di Eclipse.

Anche se non e’ necessario usare Eclipse per programmare per Android, di fatto esso e’ la scelta di default. O almeno e’ la scelta che presentera’ meno ostacoli al momento di effettuare il setup dell’ambiente. Eclipse e’ molto bene integrato con Android e i suoi tool. L’esecuzione e il debugging sul device o sull’emulatore sono un bijoux e vi sono addirittura dei tool per forzare dei dati all’interno del dispositivo virtuale in esecuzione, come la posizione geografica.

Ma odio Eclipse con tutto il cuore. Esso non si sposa minimamente col mio modo di lavorare. Considero la sua interfaccia utente imperscrutabile e le sue prestazioni sul Mac non proprio eccellenti. Se dovessi sviluppare molto su Android investirei molto probabilmente su qualche IDE alternativo con una buona integrazione di Android, o al limite lavorerei con TextMate e linea di comando.

Mi sento come se potessi scrivere ogni applicazione di cui ho bisogno con Android. Renderla bella e’ una sfida e ho speso piu’ tempo leggendo la documentazione di quanto abbia mai fatto per l’iPhone. Conoscere ogni dettaglio dell’SDK di Android non necessariamente fornisce dei suggerimenti su come puo’ lavorare un’altra parte e anche se si e’ degli esperti sviluppatori Java non si ottiene un vantaggio aggiuntivo a tal fine.

Disegnare le viste con Android e’ una delle aree su cui inequivocabilmente affermare trattarsi di un’esperienza peggiore che nell’iPhone, su ogni singolo aspetto. L’approccio utilizzato da Android per creare le viste non ha un qualsiasi valore che possa riscattarlo. Disegnare l’interfaccia per iPhone e’ facile, divertente e intuitivo. Su Android, e’ un casino. Sembra di lavorare con la stirpe maledetta di GridBagLayout e XML. E’ assolutamente orribile. Ma dopotutto Java non ha mai lavorato bene con le UI e la cosa non e’ mai stata particolarmente divertente, cosicche’ posso dire di non essere sopreso, anche se attualmente esso ha superato le mie aspettative nell’essere anche peggiore di quanto pensassi fosse umanamente possibile. L’intero processo e’ contro-intuitivo e richiede un sacco di tempo, e tutto questo per avere qualcosa che funzioni e basta. Il tutto e’ ancora piu’ dispendioso e penoso per ottenere qualcosa che non faccia schifo.

Ma questa e’ l’unica area finora che ho trovato orribile in Android. Complessivamente e’ un SDK abbastanza buono. Sicuramente non e’ divertente (almeno per me). Manca totalmente di ogni aspetto divertente. L’SDK non si toglie mai di mezzo quando voglio creare. E’ un continuo ostacolo. Non grande o insormontabile, ma sempre presente. L’SDK per iPhone, d’altro canto, e’ davvero divertente. Una volta capito l’aspetto generale di come fare le cose, e’ diventato facile per me dimenticare l’SDK e occuparmi semplicemente di creare le mie app.

Ho cercato di capire esattamente dov’e’ la differenza; che cos’e’ che rende una cosa divertente e l’altra no, e penso di averlo capito. L’SDK di Android in genere fallisce nel seguire un principio che Apple segue dannatamente bene, e cioe’:
Rendi sempre facili le cose che fai.
Come risultato, su Android le cose che tu non fai quasi mai sembrano essere ugualmente difficili e dispendiose quanto quelle che fai di continuo.

Un esempio: data la dimensione dello schermo relativamente piccola, una delle cose che fai continuamente nelle applicazioni per telefonini e’ muoverti tra le varie schermate. Nell’iPhone effettuiamo questo nella seguente maniera:

  1. Creare un’istanza della classe view controller per la vista che vogliamo mostrare
  2. Impostarne le proprieta’ per fornire i dati di cui ha bisogno per funzionare
  3. Mostrare la vista aggiungendo il view controller alla gerarchia delle viste, inserendola in una pila di navigation controller o presentandola in maniera modale, il tutto di solito in una sola linea di codice

Invece in Android questo non e’ cosi’ immediato:

  1. Aggiungere un riferimento all’Activity (l’analogo di UIViewController, anche se non esattamente la stessa cosa) nell’Android Manifest della tua applicazione per consentire ad Android di sapere quale classe puo’ essere lanciata
  2. Creare un Intent basato sulla classe dell’Activity
  3. Assicurarsi che ogni dato che si vuol passare all’altra Activity sia serializzabile oppure sia un tipo di dato di base
  4. Iniettare l’informazione che si vuol passare all’Activity come un “extra” all’Intent, serializzando gli oggetti
  5. Far partire l’Activity
  6. Nella classe dell’Activity riscrivere onActivityResult e recuperare gli extra di cui si ha bisogno, de-serializzando quelli che non sono tipi di dati nativi.
  7. Nell’Activity scavalcare il metodo onCreate() per specificare la vista che deve essere usata

In realta’ le due liste precedenti non rendono giustizia alla differenza di lavoro effettivamente impiegato. Questo compito diventa una seconda natura per lo sviluppatore iPhone poiche’ e’ intuitivo, fortunatamente. Queste sono le classiche tre o quattro linee di codice che inizi a scrivere senza neanche pensarci su. Su Android la quantita’ di cose che devi fare per ottenere lo stesso risultato e’ sparpagliata attraverso i tuoi file di progetto e il compito difficilmente puo’ diventare una seconda natura o quantomeno facile.

Ora, le persone che amano Android diranno che gli Intent sono potenti – molto piu’ che nell’approccio di iPhone – dato che gli Intent possono essere utlizzati per consentire ad altri programmi e al sistema operativo di avvantaggiarsi delle funzionalita’ del tuo programma.

In effetti gli Intent sono potenti. Il problema e’ che essi forniscono un potere di cui non hai bisogno nella maggior parte dei casi e delle applicazioni. E fanno tutto questo al costo di rendere qualcosa di cui hai bisogno tutto il tempo piu’ complicata e complessa di quel che dovrebbe essere (e quindi piu’ probabilmente fonte di bug). E’ una complessita’ indiscriminata, che non e’ una virtu’. Come OpenDoc e CyberDog possono confermare, dei concetti apparentemente buoni non sempre si manifestano in buone implementazioni o esperienze utente, e l’iPhone non ha mai sofferto molto per la sua mancanza di una funzionalita’ di condivisione tra le applicazioni.

A mio avviso, gran parte dell’SDK di Android (soprattutto le parti che non sono state pesantemente influenzate dall’SDK per iPhone) sembrano essere sovra-ingegnerizzate. Molta della complessita’ delle caratteristiche di Android sembra sia dovuta a un intento di complessita’. Quindici anni fa avrei amato tutto cio’ dato che ero nella mia fase di programmatore macho super ingegnerizzato1 e tutta quella complessita’ e la potenza teorica ad essa associata mi avrebbero fatto sentire davvero bene.

Oggi mi fa solo scuotere la testa e pensare che gli ingegneri di Google dovrebbero smetterla di mostrare quanto sono bravi e cominciare a scrivere codice elegante e complesso alla giusta maniera. Essi dovrebbero disegnare l’architettura del loro SDK con la consapevolezza del fatto che non tutti i compiti sono creati alla stessa maniera e che la semplicita’ e’, a volte, la scelta migliore in assoluto.

Ma, nonostanze la sensazione riguardo l’eleganza di Android, esso e’ senza dubbio un SDK per applicazioni mobili accettabile. Vi sono un sacco di funzionalita’ e un numero incredibile di librerie e codici di esempio su cui ti puoi basare senza dover re-inventare la ruota.

Non mi ci vedo a lavorare a tempo pieno su Android. Non mi ci vedo neanche nella ricerca attiva di lavoro basato su Android che non sia parte di un progetto piu’ grande che coinvolga un’applicazione iPhone. Ma, detto tra noi, non e’ male. A volte e’ poco elegante, inutilmente complesso e convoluto, ma e’ giovane e tutte le potenzialita’ per diventare un gran SDK.

Android decollera’? Probabilmente si’. Vi sono un sacco di telefoni Android pronti a entrare sul mercato. Le compagnie telefoniche e di telecomunicazioni amano i sistemi operativi gratuiti dato che incrementano i loro margini di profitto. E, non appena abbastanza persone disporranno di telefoni Android, allora le persone cominceranno veramente a scrivere applicazioni per tali telefoni. Non credo che si assistera’ mai allo stesso fenomeno dell’iPhone, in cui persone di tutti i generi e senza esperienza di programmazione hanno sviluppato un desiderio di imparare a scrivere software, ma credo che vi sara’ comunque un buon mercato per le applicazioni per Android e, parimenti, per gli sviluppatori Android.

Son contento di lasciare questo mercato agli altri.

1Ogni programmatore e’ passato per questa fase se ha lavorato con la programmazione abbastanza a lungo. Se tu stai programmando da un bel po’ di tempo e pensi di non essere passato per questa fase, allora vi sono ottime probabilita’ che tu ci stia proprio dentro.