Come qualcuno di voi saprà dall’ormai lontano 2009 sto sviluppando due applicazioni per android, da quando mi sono laureato (quasi otto anni fa!) sviluppo in Java applicazioni web e non. Da un po’ di tempo mi sto avvicinando all’Objective C per sviluppare per iOS, per favore non ditelo in giro, non vorrei rovinarmi la reputazione! 😛 In questo post cercherò di raccontare questa mia esperienza, cercando di essere obiettivo e non di parte (dubito di riuscirci!).

Ambiente di sviluppo: Xcode vs Eclipse

La prima cosa che si fa quando si vuole programmare è aprire un ambiente di sviluppo (qualcuno affezionato a vi potrebbe non essere d’accordo, ma questo é un altro discorso e meriterebbe un post a parte). Una volta installato Xcode, dopo un “comodo” download di circa 4Gb, la prima impressione che ho avuto aprendolo è stata “dove sono le altre voci di menù?”. E’ vero che la filosofia Apple è quella di fare cose semplici e immediate da usare, ma il target degli utenti di un IDE è composto solitamente da professionisti dell’informatica e qualche opzione in più non avrebbe spaventato nessuno.

Eclipse è l’esatto opposto, ci sono così tante opzioni nelle preferenze che hanno dovuto inserire un campo di ricerca per filtrarle! Però nel lungo periodo secondo me la produttività usando Eclipse è superiore (e ripeto un IDE di solito non si usa un pomeriggio ogni tanto).

Visto che siamo a parlare si sistemi operativi una cosa da sottolineare è che per sviluppare su iOS può essere usato solo su Mac. Per me non è un grosso problema visto che sviluppo su Android usando un MacBook (potrei essere considerato un traditore anche per questo!) ma può essere una limitazione grossa. E’ possibile farsi una macchina virtuale con Mac OS X ma non è la stessa cosa.

Editor grafico: interface builder vs Eclipse con ADT

Su questo punto non ho dubbi, l’editor grafico di interfacce di Xcode è il migliore che io abbia mai usato: quello disponibile per Android in confronto è molto più immaturo. Non c’è nient’altro da aggiungere.

Anzi un paio di cose da aggiungere ci sono. Per svariati motivi (molti dei quali per ignoranza mia mi sfuggono!) gli sviluppatori iOS esperti preferiscono creare le interfacce “a mano” invece di usare interface builder. Magari quando imparo qualcosa in più inizierò anche io a creare le interfacce da codice, per adesso uso con piacere questo tool!

Altra cosa, l’editor è così comodo perché l’unico layout utilizzabile quando si sviluppa per iPhone è quello con posizionamento assoluto. Tutti i componenti vengono posizionati a una coordinata fissa e con larghezza e altezza fissa, modalità deprecata in qualunque altra piattaforma nata dopo il Cobol: su iOS invece è l’unico modo per creare una UI! Ora capite perché su iOS c’è solo una risoluzione (il retina è il doppio del precedente display) e perché molte applicazioni non funzionano in landscape?

Ma l’editor di interfacce che mette a disposizione ADT all’interno di Eclipse come è? Dopo le prime versioni molto scarne sta migliorando molto ma è ancora abbastanza lontano dalla perfezione. Dopo un po’ di drag and drop (soprattutto con layout complessi) è sempre bene andare nella visualizzazione del codice xml per capire cosa è stato generato. La cosa positiva è che l’editing di un file xml di layout è molto semplice, c’è l’autocomplete ovunque (sia nei nomi dei tag che nei valori degli attributi) e ci sono perfino alcuni comandi refactoring. Di solito io tendo a scrivere il layout in xml e ad usare l’editor grafico per avere una preview di quello che ho scritto, altra gente tendono a usare molto di più l’editor grafico. Soprattutto all’inizio è molto utile avere una palette di tutti i componenti a portata di mano.

Componenti

I componenti disponibili su iOS sono di alto livello in tutti sensi, sia perchè sono realizzati estremamente bene sia perchè sono completi e molto vicino a ciò che si aspetta l’utente finale. In pratica un progetto Hello world su iOS fa già la sua figura, magari non fa niente, ma è già molto carino e accattivante. L’equivalente Hello world su Android è abbastanza squallido e renderlo presentabile richiede parecchio lavoro.

Vediamo per esempio uno dei progetti di demo disponibili, si chiama TheElements e mostra la tavola degli elementi. In basso possiamo vedere i classici tab usati in tante applicazioni per iPhone, si tratta di un TabBarController ed è già così senza bisogno di personalizzazioni. Se ci sono troppi item appare in automatico il tasto more che apre un menu con gli item non visibili permettendo di riorganizzarli con il drag and drop. L’effetto dell’icona dell’item selezionato è gestito direttamente dal componente, non c’è bisogno di fare niente e basta scegliere una sola icona (non la versione normale e quella selezionata). Non provo neanche a confrontare questo componente con i classici tab presenti su Android, secondo me sono semplicemente inguardabili!

Anche una semplice lista su iOS è molto curata anche senza nessuna customizzazione. Il componente TableView fornisce già il supporto ai raggruppamenti di elementi e molte altre cose fra cui una serie di layout utilizzabili per le singole celle. Lo stesso componente può essere usato anche per mostrare una classica schermata di dettaglio, infatti impostando lo stile a grouped ogni gruppo di elementi è separato dagli altri e può essere aggiunto un header e un footer. Anche in questo caso l’equivalente componente su Android (il tanto odiato o amato ListView) ha bisogno di un po’ di lavoro di personalizzazione per essere resto presentabile.

Cliccando su un elemento della lista viene mostrato una schermata di dettaglio, in alto possiamo vedere all’opera un NavigationView classica di iOS. Anche questo componente è disponibile nativamente ed è molto semplice da utilizzare, per esempio per aggiungere un button a destra o a sinistra del titolo. Anche il button back in alto a sinistra viene gestito in automatico dal componente, su Android questo button non è necessario (e non aggiungetelo anche se state effettuando un porting da iOS!) in quanto è già presente l’apposito tasto (fisico su Android 2.x o software su Ice Cream Sandwich).

Sfruttando questi tre componenti è possibile creare una app per iOS che segue la user experience del sistema operativo Apple in pochissimo tempo. E per fare la stessa cosa su Android? Fino a un po’ di tempo fa c’era da faticare molto per ottenere un risultato simile, per fortuna ultimamente stanno nascendo varie librerie (alcune distribuite da Google e altre da sviluppatori indipendenti) che agevolano il lavoro. Per esempio usando una ActionBar con un ViewPager per gestire i tab lo scheletro di una app può essere creato facilmente. L’ActionBar è disponibile nell’sdk Android solo da Honeycomb ma includendo in un progetto ActionBarSherlock è possibile usarla anche nelle versioni precedenti di Android. Per sfruttare al massimo il ViewPager (anche questo disponibile da Honeycomb ma fortunatamente incluso nell’Android compatibility library) vi consigliamo di usare la libreria ViewPagerIndicator.

Simulatore iPhone e iPad vs emulatore Android

Per sviluppare una applicazione mobile è fondamentale avere un qualcosa per testare la propria applicazione, un device vero è l’ideale ma non sempre è disponibile per diversi motivi. In questi casi è fondamentale avere a disposizione un software sul pc/mac per testare l’applicazione, ovviamente sia in ambiente iOS che Android questo software è disponibile.

La differenza fra i due ambienti è notevole, per iOS è disponibile un simulatore mentre per Android è possibile usare un emulatore e questo approccio è radicalmente diverso. Cosa vuol dire in pratica? Il simulatore iOS è velocissimo, ma alcune caratteristiche potrebbero non essere disponibili o leggermente diverse rispetto a un dispositivo reale. Per esempio la memoria disponibile sull’emulatore non è limitata (si può usare tutta la memoria del mac!) e ci sono leggere differenze grafiche per esempio nella rotazione del device. L’emulatore Android è un po’ più lento ma è un sistema operativo completo o quasi, ovviamente l’hardware (gps, telefono, bussola, …) è difficile da emulare completamente. Quanto è la differenza in termini di tempo speso a guardare una progress bar? Sul primo avvio la differenza si vede ma per fortuna l’emulatore Android non deve essere riavviato a ogni modifica dell’applicazione.

Le prestazioni dell’emulatore Android fino a poco tempo fa dipendevano molto dalla versione del sistema operativo, quello della versione 2.x è sempre stato decente, quello di Honeycomb e Ice Cream Sandwich erano quasi inutilizzabile! 🙁 Le cose sono fortunatamente cambiate con la release 17 del plugin Android per Eclipse che contiene il supporto per le immagini per x86 e all’hardware acceleration. A partire da questa release installando un software esterno e abilitando la gpu emulation sull’emulatore è possibile testare tranquillamente la propria app su un emulatore con ottime prestazioni. Era l’ora!

Conclusioni

Finisce qui la prima parte di questo viaggio, per adesso abbiamo visto gli ide usati per sviluppare, i componenti utilizzabili per creare le interfacce grafiche e l’emulatore/simulatore da usare per testare le nostre applicazioni. Nella seconda parte vedremo in dettaglio un confronto fra i due linguaggi di programmazione, ovvero Java vs Objective C. Se per adesso sono stato abbastanza neutrale (nel limite del possibile!) nel prossimo post lo sarò molto meno… A presto!