Applicazioni vs. Web

Apple <3 standards#section1

Dal punto di vista di Apple, l’iPhone OS e le tecnologie web stanno sullo stesso piano. Quando visitate il loro sito per developer, il Safari Dev Center è esposto bene in vista. Tutta la stampa parla di iPhone, ma quando cliccate sul Safari Dev Center trovate una tonnellata di ottime informazioni che spiegano come usare HTML, CSS e JavaScript su un iPhone.

Quando ripensate alle vostre prime esperienze con l’iPhone, un’applicazione spicca tra tutte le altre: il web browser Safari. Improvvisamente vi trovavate liberi dall’internet mobile pieno di supporto osceno per CSS o con il livello di presentazione di bassissimo livello come WAP. Il vero browser di iPhone ed il fatto che si trovava nelle vostre tasche cambiarono il modo in cui usate il web.

Apple continua ad investire pesantemente nello sviluppo dell’engine WebKit del browser usato in Safari su iPhone, Mac e Windows. Il risultato è un browser che eccelle nel supporto di HTML5 e CSS3.

Apple, inoltre, vede il supporto per HTML5 come una parte importante del suo messaggio di marketing sia per i consumatori sia per gli sviluppatori.

Poiché è open source, il motore di rendering di WebKit alimenta altri browser per molte altre piattaforme mobili. Se state navigando in rete con un telefono Blackberry, Android o Symbian, noterete che il vostro contenuto si vede bene come lo si vede con l’iPhone. L’unica a fare eccezione è la piattaforma mobile di Microsoft Windows che usa un browser basato sul motore di rendering di IE.

Con un buon supporto per HTML, CSS e JavaScript, gli sviluppatori stanno facendo cose strabilianti sull’iPhone. Ecco qualche esempio notevole:

Pie Guy di Neven Mrgan#section2

Pie Guy usa la cache dell’applicazione offline di HTML5 così da poter funzionare correttamente quando non siete collegati a internet, così come le animazioni e le trasformazioni di CSS per gli effetti del gioco. Neven tiene inoltre traccia degli sviluppi in quest’area attraverso il sito HTML5 Watch.

Showtime di Nial Giacomelli e Benjamin Gordon#section3

Showtime è una semplice applicazione che vi permette di tenere traccia dell’orario di trasmissione dei vostri show televisivi preferiti. Usa un plugin jQuery di David Kaneda che fornisce tanti controlli ed effetti quanti ne potete trovare nelle applicazioni standard per iPhone.

Every Time Zone di Amy Hoy e Thomas Fuchs#section4

Every Time Zone è una vista molto semplice ma efficace dei fusi orari nel mondo. Lo slider che vi permette di scegliere l’ora funziona molto bene su un touch screen. Questa applicazione è particolarmente bella sul display dell’iPad.

Con così tanti ottimi tool disponibili e sviluppatori talentuosi che sanno come sfruttarli, l’iPhone dovrebbe essere strapieno di applicazioni web, no? In realtà, è vero l’opposto: ci sono più di 100.000 titoli su iTunes e solo una manciata di applicazioni popolari sono state create con gli standard web.

Apple ha promosso sia l’App Store sia il browser web come modi per permettere agli sviluppatori di portare le loro creazioni nelle mani dei clienti. Hanno perfino dato al web un anno intero di vantaggio prima di cominciare a vendere applicazioni nello store. Chiaramente c’è molto di più in gioco, qui: cosa attrae gli sviluppatori su iTunes piuttosto che sul web?

Going native#section5

Prima di analizzare le motivazioni che hanno portato alla migrazione verso iTunes, abbiamo bisogno di alcune definizioni. Gli sviluppatori sono giunti a categorizzare le due tecnologie di sviluppo per iPhone come “native” e “web” Le applicazioni web usano HTML, CSS e JavaScript e vengono caricate in Safari. Tutti gli esempi di cui sopra sono “applicazioni web (o web apps)”.

Le “applicazioni native (o native apps)” sono create usando l’ambiente di sviluppo Xcode in un linguaggio chiamato Objective-C. Tali tools sono gli stessi usati per creare le applicazioni built-in di Apple come Mail, iPod e lo stesso Safari.

Creare applicazioni native differisce molto dal processo che si usa per costruire applicazioni web. Fortunatamente, molti dei concetti base sono gli stessi. Tanti web developer trovano il cambiamento non troppo difficile:

• Come JavaScript, il linguaggio Objective-C è un discendente di C. Oltre ad avere una sintassi simile, entrambe i linguaggi sono orientati agli oggetti. Se vi trovate bene con JavaScript, vi troverete altrettanto a vostro agio con Objective-C.
• Le applicazioni native e quelle web hanno in comune degli elementi di design famigliari. Sul web, di solito si dividono le funzionalità di un’applicazione in pagine, creando una serie di elementi <div> per organizzare il contenuto su ciascuna pagina e si usa XMLHttpRequest per aggiornare tale contenuto. Con Cocoa Touch i “view controllers” sono usati come pagine, le “views” forniscono i blocchi costituenti per il vostro contenuto e gli oggetti NSURLConnection agiscono come il vostro collegamento a internet.
• I framework gestiscono gran parte del lavoro difficile. Così come fate affidamento su jQuery o Prototype quando lavorate in JavaScript, vi troverete a fare la stessa cosa con Cocoa Touch quando lavorerete in Objective-C. Entrambe i linguaggi traggono inoltre beneficio da un’attiva comunità di sviluppatori che è ben felice di scambiarsi trucchi e codice sorgente.
• Se siete sviluppatori Flash frustrati perché non c’è modo di far girare le vostre creazioni sull’iPhone, sarete felici di sapere che ActionScript, come il suo predecessore JavaScript, ha in comune la stessa discendenza di C. I meccanismi per creare animazioni ed altri effetti visivi sono diversi sull’iPhone, ma i concetti sono gli stessi. Il framework Sparrow recentemente rilasciato può esservi d’aiuto rendendo la transizione più semplice, specialmente se usate Flash per sviluppare giochi. E’ anche un grande esempio di contributi messi a disposizione dai vostri colleghi sviluppatori per iPhone.

Per darvi un’idea di quanto siano simili le cose, guardate questo frammento di codice JavaScript:

    
    var beAwesome = true;
    var myString = "chocklock";
    if (beAwesome) {
	myString = myString.toUpperCase();
    }
    
  

Adesso fate il paragone con la stessa cosa in Objective-C:

    
    BOOL beAwesome = YES;
    NSString *myString = "chocklock";
    if (beAwesome) {
	myString = [myString uppercaseString];
    }
    
  

In Objective-C, le difinizioni di variabile sono diverse e le chiamate alle funzioni sono sostituite con delle cose tra parentesi quadre. In un contesto più ampio, questi sono dettagli minori. Potete ancora comprendere la logica sottostante: per essere fantastici [to be awesome, ndt] dovete solo convertire la vostra stringa in lettere maiuscole.

Uno degli obiettivi del mio libro sullo sviluppo di applicazioni per iPhone era quello di rendere questo nuovo ambiente accessibile alle persone che vengono da altri background. Ho dedicato un intero capitolo del libro a spiegare quelle parentesi quadre in termini famigliari.

La motivazione#section6

Imparare ad usare dei nuovi tool di sviluppo richiede qualche sforzo. Quindi, perché gli sviluppatori dovrebbero passare attraverso tutte queste seccature quando potrebbero semplicemente contare sulle conoscenze di web che già hanno?

Alcune motivazioni sono puramente egoistiche: le applicazioni native danno allo sviluppatore molto più controllo rispetto all’ambiente mobile. L’altro incentivo è altruistico: un’applicazione nativa è generalmente più semplice da usare per tutti gli altri.

• Velocità: la performance di JavaScript è aumentata incredibilmente negli ultimi anni, ma essendo un linguaggio interpretato, non sarà mai così veloce come il codice che gira direttamente sul processore. In un ambiente mobile in cui i processori girano più lentamente per conservare l’energia, ogni ciclo di clock conta.
• Data Management: Cocoa Touch ha molti meccanismi che rendono semplice il salvataggio dei dati della vostra applicazione. Questo è importante perché memorizzare un’informazione raccolta dalla rete può aumentare enormemente la facilità d’uso di un’applicazione mobile. La memorizzazione persistente dei dati in HTML5 fornisce un semplice accesso key/value o il puro accesso al database usando SQL. Core Data sull’iPhone fornisce un sistema molto più sofisticato in cui le relazioni tra i vostri oggetti dati sono gestiti automaticamente.
• Animazione: uno dei marchi di fabbrica delle applicazioni iPhone sia web sia native è l’animazione che rinforza le azioni dell’utente. CSS3 fornisce dei modi per animare gli elementi di una pagina, ma degli effetti molto più sofisticati sono possibili quando accedete al framework Core Animation con il codice nativo.
• Risorse: gli sviluppatori per dispositivi mobili non hanno mai sufficiente memoria o velocità di rete o potenza di CPU. Queste risorse limitate sono molto più difficili da controllare quando vengono gestite tramite JavaScript o il browser. E’ molto più semplice per le applicazioni native individuare queste situazioni ed adeguare l’esperienza utente di conseguenza.
• Usabilità: gli utenti di iPhone si sentono più a loro agio quando possono usare i controlli standard a cui si sono abituati nelle applicazioni built-in di Apple. HTML astrae i controlli come <input> e <textarea> così da poter funzionare in molti ambienti diversi. I framework JavaScript, come il già citato jQTouch, fanno un lavoro fantastico estendendo questi meccanismi base di controllo, ma un utente iPhone noterà ancora che sembrano un po’ diversi dai controlli nativi della piattaforma.
• Produttività: dal punto di vista dello sviluppatore, è tipicamente semplice creare interfacce utente complesse usando Cocoa Touch: i framework fanno la maggior parte del lavoro e permettono a voi di concentrarvi sul problema piuttosto che sulla sua implementazione. Con uno spazio limitato sullo schermo di un dispositivo mobile, una semplice form su un desktop spesso si risolve in molteplici views il cui stato deve essere gestito dalla vostra applicazione. Apple ha sviluppato Cocoa Touch specificatamente per gestire questa situazione.
• Integrazione: un iPhone ha molte capacità che vanno oltre quelle di un browser web. Alcuni semplici esempi sono i contatti degli utenti, la libreria di foto, la registrazione vocale e il movimento del dispositivo. I framework Cocoa Touch sono l’unico modo per accedere a queste informazioni.

Man mano che il web matura, le sue applicazioni verranno naturalmente suddivise in due parti: il front end ed il back end. I servizi di back end gestiscono i dati degli utenti e sono generalmente alimentati da rack di potenti server. Il front end di un’applicazione web prende questa informazione e la presenta nel browser: HTML, CSS e JavaScript riguardano tutti l’esperienza utente. In molti casi, questo front end è un layer abbastanza sottile che sta sopra un back end molto più grande.

Con le applicazioni per iPhone, questo sottile layer di presenzazione viene sostituito. L’accesso alle API basate su REST implementate dal back end è esattamente lo stesso. Sì, state duplicando tutti gli sforzi di sviluppo del front end che avete già affrontato per il browser, ma questo sforzo extra ha i benefici che abbiamo citato prima.

In pratica#section7

Ci sono così tanti approcci allo sviluppo quante sono le applicazioni in iTunes. Ciascun prodotto e le persone che lo hanno creato sono differenti. Detto ciò, l’evoluzione di un prodotto dal web all’iPhone tipicamente funziona più o meno così:

1. Progettare il prodotto. Non importa quale piattaforma sia il vostro target: sia che si tratti del web o di uno smartphone, il primo passo è sempre quello di pensare al problema che state cercando di risolvere. Dovete capire cosa vogliono i vostri utenti prima di arrivare alle specifiche di implementazione.

2. Implementate il prodotto usando gli standard web. Usate i tool che vi sono più familiari: in questo modo avrete anche una soluzione che avrà la più ampia portata e potrà essere visto su ogni piattaforma con un browser standard-compliant. Cercate di usare CSS e JavaScript che ottimizzano l’esperienza per gli utenti sui dispositivi mobili (inclusi iPhone, Android e BlackBerry).

   Come punto di partenza, leggete Put Your Content in my Pocket e Put Your Content in my Pocket, Part II.

   Man mano che implementate il vostro prodotto, fate molta attenzione a come l’interfaccia utente del front end comunica con i servizi di back end. Cercate di usare una API REST fornita da terze parti oppure una vostra soluzione più specifica per la piattaforma.

3. Lanciate il prodotto. Fate arrivare il vostro lavoro nelle mani degli utenti il prima possibile. Quando le persone cominciano ad usare la vostra creazione, cominceranno a darvi un feedback. Questo dà il via al ciclo virtuoso di iterazione e raffinamento.

4. Affrontate i problemi. Alla fine, vi imbatterete in situazioni che non possono essere risolte con gli standard web. Potrebbe trattarsi di qualcosa come una richiesta di feature da parte degli utenti che vogliono caricare delle foto o accedere alla loro lista di contatti. Alcuni utenti chiederanno esplicitamente un’app per iPhone perché tanti dei loro siti preferiti hanno creato soluzioni personalizzate.

   Ci potrebbero anche essere pressioni interne da parte dei vostri stessi designer e sviluppatori. Potrebbero trovare la navigazione e la gestione dei dati più difficile man mano che lo scopo dell’applicazione cresce. Quando comincerete ad avvertire la sensazione di star reinventando la ruota, a volte è meglio usare semplicemente la ruota che Apple ha già creato.

5. Traducete il progetto del prodotto in una app per iPhone. Troverete che molte delle decisioni che avrete preso mentre implementavate le pagine web erano state prese in nome della neutralità di piattaforma. Entrando nel mondo piattaforma-specifico di iPhone, rivaluterete alcune decisioni. I layout e l’interazione con l’utente dovrebbero essere fatte su misura, per farli sentire a casa in una app nativa.
6. Lanciate il prodotto su iTunes. Dopo aver sviluppato l’applicazione per l’iPhone, avete ora un nuovo importante modo per far sì che gli utenti trovino il vostro contenuto o servizio. Il che ci porta alla prossima sezione…

Curare gli affari#section8

L’altra attrattiva per gli sviluppatori che guardano alle app native è semplice: ci sono più di 100 milioni di clienti in iTunes che possono acquistare la vostra app cliccando su un singolo pulsante. Possono anche pagare per il vostro contenuto con la stessa facilità. Se avete un’azienda, ci sono alcuni vantaggi netti nel costruire applicazioni che si affianchino al vostro sito web.

Brand marketing#section9

Per i brand marketers, l’App Store è un altro importante canale per mettere un prodotto o un servizio davanti agli occhi di milioni di persone. I grandi brand citati all’inizio dell’articolo continuano ad avere una forte presenza: le loro app per iPhone integrano la loro posizione.

Molte tra queste aziende vedono le applicazioni native per iPhone come una forma economica di pubblicità: 30 secondi durante il primetime possono costare fino a mezzo milione di dollari. Una app per iPhone vi costerà molto meno e quando un venditore vede la sua icona apparire in iTunes, gli sembra meglio della mattina di Natale!

Gli sviluppatori più piccoli possono anche usare l’App Store per trovare un nuovo pubblico e per rifinire l’esperienza per gli utenti attuali. Avete già fatto il lavoro duro con il vostro back end, pertanto lo sforzo e le spese per costruire un nuovo front end sono di solito minime.

I media contano#section10

Molti siti web trovano difficile far pagare per accedere ai propri contenuti. La radice di questo problema sta nella mancanza di un meccanismo di pagamento conveniente per l’end user. C’è anche la storia dell’accesso libero all’informazione sul web. Come risultato, molti siti fanno affidamento sulla pubblicità per pagare i propri costi.

iTunes offre un modo semplice per far pagare agli utenti i contenuti. Può essere un pagamento una tantum al momento dell’acquisto della applicazione oppure un pagamento ricorrente (come un abbonamento) con il meccanismo In-App Purchase. In entrambe i casi, un cliente deve solo toccare con il dito un pulsante di acquisto ed immettere la propria password. Apple gestisce tutti i processi di pagamento e di fatturazione. Dovete solo aspettare il deposito sul vostro conto corrente da tutto il mondo alla fine di ogni mese.

Con la recente realizzazione di iPad e la sua popolarità, gli editori sia grandi sia piccoli trovano remunerativo riconvertire i propri contenuti per iPhone OS. Il recente debutto del magazine Wired nell’App Store ha generato 24.000 vendite nelle prime 24 ore. A cinque dollari a copia, non ci vuole un genio della finanza per capire che c’è una seria richiesta da parte dei consumatori per del contenuto distribuito in maniera innovativa via iTunes.

Se ci pensate su ancora un pochino, ha completamente senso dal punto di vista del consumatore. Siete abituati a comprare musica e video da iTunes. Adesso con l’iBookstore i titoli principali vi possono essere spediti in formato elettronico. Aggiungere il vostro contenuto a questo ha senso per voi e per i vostri clienti.

Procedete con cautela#section11

Mettere il proprio contenuto nell’App Store include anche uno step a cui probabilmente non siete abituati nel selvaggio web: Third-party review [revisione da terze parti, ndt]. Qualunque cosa mandiate su iTunes dovrà essere controllata e potrà essere cancellata a discrezione di Apple. Ogni app che vedete su iTunes è passata attraverso questo processo.

La revisione da parte di iTunes tende ad eccedere sul lato della cautela. Ad un certo punto dei cartoni a sfondo politico non sono stati ammessi perché mettevano in ridicolo una figura pubblica. Apple ha da allora allentato la morsa delle restrizioni, ma ci sono ancora dei limiti di cui dovete essere a conoscenza. Queste condizioni ed altre sfumature di iTunes sono ulteriormente esplorate nel mio libro.

Se il vostro contenuto contiene del nudo o qualunque altra area che è proibita, avete solo perso del tempo a leggere questo articolo. Le cose non sono tutte negative, tuttavia, perché potete ancora usare Safari per aggirare l’intero processo dei curatori.

Impacchettate#section12

Ecco qui, un rapido riassunto di cosa significano oggi per i produttori di contenuto web le app per iPhone. Spero che le informazioni contenute in questo articolo siano abbastanza per determinare se un’applicazione mobile dedicata è quel che serve al vostro sito. Se decidete di mettervi di buzzo buono su questo percorso di sviluppo, spero che troviate nel mio libro un’utile guida che vi illustra il processo dall’inizio alla fine.

Illustrazioni: {carlok}