Il costo di un' App per iPhone & iPad

Riportiamo la traduzione integrale dell’articolo Dear business people, an iOS app actually takes a lot of work!, scritto da Kent Nguyen che ringraziamo per averci concesso il permesso.

This is the italian translation of the article Dear business people, an iOS app actually takes a lot of work!, written by Kent Nguyen. Thanks Kent for giving us permission to publish this translated article.

Il grande quesito: quanto costa un’app per iPhone?

Questa è una domanda estremamente comune che viene sempre chiesta da un sacco di persone che lavorano nel mondo degli affari oppure da clienti non molto esperti di tecnologia. Senza dubbio, ogni volta che ho fornito una stima iniziale prima ancora di formalizzare e analizzare in dettaglio le specifiche, ho potuto vedere sui loro volti l’espressione di shock a causa della inaspettatamente alta quotazione.

Inoltre nessuna delle mie quotazioni si è lontanamente avvicinata ai valori discussi in, nel quale vengono discussi i costi di sviluppo dell’app Twitterific. Nonostante il fatto che la domanda originale fosse stata posta nel 2008 e la migliore risposta (da uno degli sviluppatori di Twitterific) fosse arrivata nel 2010, è ancora molto precisa all’inizio del 2012 ed è facile prevedere che lo sarà almeno fino alla fine dell’anno.

Cosí, con il crescere del numero di imprese che desiderano avere un’app per iOS, penso che sia una buona idea spiegare perché i costi siano effettivamente alti cercando di dividere i vari passi e spiegare le variabili coinvolte. Spero che questo articolo sia di beneficio per i non sviluppatori e gli uomini d’affari che devono prendere delle decisioni o semplicemente vogliono comprendere il processo. Le idee in questo articolo ovviamente non sono ristrette al solo mondo iOS ma possono essere estese ad altre piattaforme (Android, Windows Mobile, forse Blackberry).

Checklist: prepararsi ad un’app per iPhone

Il procedimento non è affatto semplice e cerco innanzitutto di informare il cliente a fare tutte le considerazioni guidandolo attraverso questi passi:

PRIMO: Una delle maggiori scoperte che ottengo parlando con i clienti è quanto siano inconsapevoli delle grande infrastruttura necessaria per un’app per iPhone. Dato che essi assumono che un’app sia semplicemente un’app, si aspettano che gli venga fornito il prezzo di fare qualunque cosa con l’app senza tener conto di problematiche quali: avere un server di supporto col quale l’iPhone comunichi, dove immagazzinare i dati dell’utente. La prima volta che incontrai un tale cliente ero furioso ma in seguito ho realizzato il fatto che il concetto di client-server non deve essere dato per scontato tra i non programmatori. Avevo sbagliato, i manager di solito non hanno il senso-tecnico comune che noi programmatori ci attendiamo.

Perciò, cari lettori non tecnici: è necessario che disponiate di un server nel quale memorizzare i dati per qualunque tipo di app che come minimo debba fare qualche autenticazione (login) o qualunque tipo di personalizzazione che volete cambiare in seugito o comunque qualunque operazione che richieda il recepimento di informazioni dall’utente (sto cercando di usare il linguaggio il più semplice possibile).

SECONDO: Dato che avete bisogno di un server, bisogna fare in modo che l’iPhone possa comunicare con tale server, inviando e ricevendo dati. Non esiste una maniera standard, non esiste nessun componente plug-and-play per fare questo, ogni cosa va customizzata. Questo è analogo a creare il vostro linguaggio personalizzato: non volete che gli altri comprendano ciò che state dicendo ma le due estremità, telefono e server, devono capirsi.

Questo processo consiste nella creazione di API (Application Programming Interface) per la vostra app. Queste API devono esistere prima che si proceda con lo sviluppo dell’app. Perché? perché prima di cominciare a comunicare occorre definire il linguaggio! Questo ci porta al prossimo passo, come creare queste API.

TERZO: Non prendere questo passo alla leggera, le API hanno un’importanza pari al 50% dell’intera soluzione. Fare un’API è come mettere in piedi un sito web. Prima devi definire i dati, quindi la logica di business, quali sono i parametri di ingresso a tale logica, come interagiscono fra loro i vari moduli quando accade un evento. Per semplificare, il risultato finale è un sito web completo dove però le pagine non mostrano risultati grafici ma solamente del testo che verrà compreso dalla nostra app: ad esempio una pagina di autenticazione conterrà, in caso di successo, la semplice parola YES.

L’iPhone quindi farà una serie di richieste a questi punti terminali predefiniti (pagina di login) usando il formato di ingresso predefinito dall’API (nome utente + password) e quindi interpreterà il risultato fornito da queste pagine in risposta alla sua richiesta (YES/NO). L’app senza questo non potrà mai registrarsi e fare il login magicamente da sola.

Ci sono *un sacco* di variabili che devono essere prese in considerazione in questa fase, come preparare un server, selezionare il linguaggio di programmazione con cui scrivere le API, dove immagazzinare i dati per minimizzare i tempi di comunicazione, ecc.

QUARTO: Queste API o sono già pronte e ben documentate dal vostro team interno per essere fornite allo sviluppatore iPhone oppure preparatevi a pagare di più che solo per la pura app. In funzione delle conoscenze dello sviluppatore che avrete contattato per farvi l’app, egli/ella potrebbe avere o meno le capacità per fare ciò di cui avete bisogno. Se lo sviluppatore è in grado di fare questo lavoro, allora vi consiglio fortemente di affidargli anche questa parte del progetto dato che egli sa esattamente quali API servono per far funzionare l’app al meglio.

Nel caso abbiate già le API dovrete dare allo sviluppatore la possibilità di parlare apertamente e liberamente con il vostro team di back-end e non limitarvi a dargli la documentazione; questo perché il più delle volte egli richiederà che venga fatto del lavoro in più (più API) per supportare l’applicazione mobile in maniera appropriata.

Adesso, la parte iPhone

Caspita, tutto questo per essere appena pronti a sviluppare l’app e non siamo ancora partiti! In generale, qualunque cosa riguardo iOS è molto restrittiva. Dovete quasi sempre aver definito circa il 100% dello scopo e del design prima che lo sviluppatore possa partire con la programmazione; diversamente dallo sviluppo di siti web, lo sviluppo di un’app per iOS sotto contratto ha pochissimi margini di cambiamento:

Disegnare l’interfaccia: La scelta se si devono utilizzare i componenti grafici standard o personalizzati deve essere presa già dall’inizio, dato che l’architettura dell’intera app dipende da come si vuole l’interfaccia e da come la utilizzeranno gli utenti.Un esempio è la Tab Bar in basso: se si vogliono i bottoncini colorati invece di quelli monocromatici standard, la modifica al codice è sostanziale!

Il codice è fortemente integrato: Con i siti web voi potete aggiungere semplicemente una pagina in più, quindi create un link a quella pagina ove richiesto. Non potete fare questo con un’app per iOS, dato che ogni cosa va decisa all’inizio e ogni cambiamento può risultare in cambiamenti significativi in altre parti dell’app. Il modo in cui il codice iOS è strutturato è come quello di una breadboard (le basette sperimentali per circuiti elettrici), dove ogni cosa è collegata con fili: voi potete sempre cambiare delle cose qui e là ma se tocchi il filo sbagliato allora l’intero circuito smetterà di funzionare. Anche se viene usato del codice estremamente ben strutturato la flessibilità non aumenterà molto. L’aggiunta di un bottone email addizionale nella schermata “About” potrebbe richiedere un ridotto numero di linee di codice addizionali, ma l’aggiunto di un bottone “Facebook Like” sulla stessa pagina è una cosa completamente differente e non ci può attendere che venga fatto in poche ore.

Convertire un’app per iPhone in un’app iPhone/iPad universale: Questa è la peggiore ‘funzionalità aggiuntiva’ presente nei contratti di sviluppo di app per iPhone. Questo perché un’app per iPad non è una banale funzionalità aggiuntiva. Le app per iPad sono di solito molto più complesse delle app per iPhone e il più delle volte sono richiesti un’interfaccia e un meccanismo di interazione completamente differenti. Non solo quello, dato che anche le API potrebbero essere diverse: l’app Denso, che ho sviluppato (e quindi conosco), ha alcune funzionalità esclusive dell’app per iPad che richiedono dati addizionali dal server. Inoltre l’iPhone e l’iPad richiedono esperienze utente differenti.

Dunque siete pronti a partire?

Spero che dopo aver letto questo abbiate un’idea più chiara di quel che è necessario alla vostra ditta per sviluppare un’app per il mondo mobile. A meno che non facciate un’app completamente offline (come una Calcolatrice!) che non raccoglie dati dagli utenti, non potrete pretendere che questa vi venga sviluppata a un prezzo basso. Dopo aver considerato le variabili elencate sopra, se non potrete giustificare lo sviluppo a contratto allora l’altra opzione è assumere a tempo determinato dei progettisti a tempo pieno che lavorino a tempo pieno per l’intera durata del progetto.

D’altro canto, se decidete di andare avanti e affidare in outsourcing il lavoro, c’e’ un’altra cosa da aggiungere: le lungaggini burocratiche. Se lavorate in una grande azienda o in un ambiente molto regolamentato, il vostro lavoro sarà essenzialmente di aiutare lo sviluppatore ad evitare le lungaggini burocratiche che potrebbe incontrare lungo la strada e talvolta avrete necessità di aggirare un pochino le regole. Ho parlato con molti clienti e ho potuto notare il loro scetticismo quando ho cercato di saperne di più sulle loro API, dato che essi o non desideravano esporsi maggiormente per non violare le loro regole di segretezza, e non potevo biasimarli, oppure non possono portare certi dati al di fuori del perimetro aziendale, oppure semplicemente (e questa è la cosa peggiore) le regole di branding aziendale richiedono che ogni singola pagina dell’app presenti il logo dell’azienda (!!!). Alla fine ho preferito non lavorare con questi clienti dato che non potevo immaginare quando a lungo avrei penato per ottenere anche un minimo supporto sulle API di cui avrei avuto bisogno.

P.S. Avrete bisogno di tempo, un sacco, per cui siate pazienti.

Schermate dell’applicazione

Un’applicazione per la lettura di riviste si compone principalmente di 3 schermate principali, indicate in figura

Sviluppo App per Magazine

La prima schermata  rappresenta lo Store ossia la vetrina delle pubblicazioni. Questa è di solito la prima schermata che viene presentata all’utente (con l’eventuale eccezione dello splash screen) e visualizza le copertine e le informazioni principali dei numeri attualmente in vendita, in genere con particolare evidenza per l’ultimo numero. Tutti i numeri presentati sono acquistabili, dove per acquistabile si intende anche nel caso la rivista fosse gratuita, ossia venduta a prezzo zero.

Tipicamente in un’app per riviste si ha una sola testata a disposizione, per cui la vetrina sarà limitata all’ultimo numero a disposizione e un insieme di numeri precedenti selezionati dall’editore. Per riviste con periodicità mensile in genere si raccomanda la visione degli ultimi 12 o 24 numeri, per riviste con cadenza settimanale non conviene appesantire troppo la vetrina limitandosi alla visualizzazione degli ultimi 3 o 6 mesi di pubblicazioni, eventualmente fornendo la possibilità all’utente di una ricerca in archivio per poter accedere a numeri più vecchi.

Chiaramente per app più complesse, esempio multi testata o per librai, l’organizzazione della vetrina dovrà essere di tipo gerarchico, consentendo ad esempio una scelta iniziale per categorie o testate. Inoltre la rappresentazione grafica può essere di diversi tipi: a copertine scrollabili, a griglia, con effetto cover flow, su scaffale ecc.

Di ogni pubblicazione presentata in vetrina viene in genere presentata la copertina, il numero, la data di pubblicazione, il prezzo, eventualmente un breve sommario, oltre che ai bottoni necessari all’utente per poter effettuare la sua scelta. Questi bottoni consentiranno l’acquisto (o il download diretto nel caso di prodotti gratuiti) e la possibilità di effettuare una preview (che può avvenire on-line oppure mediante il download di un numero ridotto o infine per presentazione di alcune miniature significative).

Una volta che la procedura di acquisto è completata, la rivista viene immediatamente copiata nella Libreria utente. Questa schermata ha lo scopo di mostrare all’utente tutte le pubblicazioni acquistate. La presentazione grafica potrà essere simile a quello dello Store oppure differente, mentre diverse saranno le azioni possibili. Oltre ovviamente al bottone “Leggi”, si dovrà prevedere un certo numero di azioni legate alla struttura dell’applicazione. Per esempio nell’eventualità che concluso l’acquisto si sia reso impossibile effettuare il download, allora al posto del bottone “Leggi” dovrà presentarsi un bottone “Download”. Oppure l’utente può decidere di rimuovere completamente la rivista già letta dallo scaffale (“Cancella”) o di liberare spazio nella memoria permanente dell’iPad cancellando il file che contiene la rivista ma lasciando la copertina per poter effettuare un successivo download (“Archivia”).

Infine la terza schermata fa riferimento al Reader, ossia la pagina dedicata alla fruizione dei contenuti. Quest’ultimo può essere un lettore di file pdf di tipo generale, o un lettore di ePub, oppure un lettore customizzato nel caso la rivista fosse rappresentata con formati non standard  o infine (ma sconsigliato) il Preview interno al sistema operativo (sostanzialmente il lettore di documenti integrato in Safari).

Alcuni editori potrebbero richiedere che le funzioni Libreria e Store siano unificate in un’unica schermata. Questa scelta è comune a molte applicazioni già presenti sul mercato, compito dell’applicazione sarà quello di mostrare chiaramente e in maniera opportuna le varie scelte possibili. Ad esempio non avrà senso visualizzare il prezzo della pubblicazione se quest’ultima è già stata acquistata. Inoltre se la pubblicazione è stata acquistata, letta e archiviata sarebbe più opportuno presentare il bottone “scarica” piuttosto che il bottone “acquista” per non disorientare il cliente (sebbene la policy dell’App Store sia tale per cui successivi riacquisti dello stesso prodotto non comportino un ulteriore addebito in carta di credito). Infine si dovrà prevedere uno spazio apposito per la gestione degli abbonamenti nel caso che la pubblicazione prevedesse questa forma di acquisto.

Architettura

Un’app correttamente organizzata dovrà disaccoppiare, per quanto possibile, i moduli gestionali da quelli visuali. Questo perché diversi editori potrebbero richiedere importanti variazioni grafiche e di approccio sull’interfaccia utente, ma ovviamente lo sviluppatore deve cercare di riutilizzare per quanto possibile i blocchi critici legati alla gestione dei dati. L’approccio da seguire è quello suggerito da Apple per la programmazione con Cocoa e denominato MVC (Model View Controller) che va implementato fin dai più alti livelli.

Riportiamo di seguito un diagramma a blocchi funzionale.

Il Publisher Server indicato nel diagramma con una nuvola non fa parte dell’applicazione ma costituisce l’insieme dei servizi internet a cui si appoggia l’app. Esso consiste di solito della infrastruttura server per l’immagazzinamento e la fornitura dei contenuti (quindi delle riviste) oltre che dei servizi web di cui si avvarrà l’applicazione per poter costruire la sua vetrina. Questo back-end può essere gestito direttamente dal cliente sui suoi server, oppure su servizi dedicati quali Amazon S3 o infine direttamente dallo sviluppatore (in tal caso si raccomanda una buona larghezza di banda e un tempo di indisponibilità veramente ridotto).

Lo Store Manager è uno dei blocchi funzionali centrali dell’applicazione. Il suo ruolo è sia quello di comunicare con il back-end dell’editore sia quello di fornire alle altre componenti dell’app i dati che verranno di volta in volta richiesti. La progettazione di quest’oggetto deve essere quindi particolarmente curata e dovraà essere assolutamente svincolata dall’interfaccia utente.

All’apertura dell’app lo Store Manager si inizializzerà e quindi provvederà a contattare il server per recuperare la lista aggiornata delle pubblicazioni in vetrina. Come questo avviene è strettamente legato alle caratteristiche del servizio fornito dal server. Qui possiamo usare un semplice file XML, JSON o PLIST – nel caso di prodotti con pochi numeri pubblicati – o un insieme ben più complesso di API che permetteranno di muoversi all’interno di un catalogo ben più vasto o di poter fare ricerche (per autore, titolo, genere nel caso di libri).

Val la pena sottolineare che la comunicazione server – applicazione è avviene principalmente in una direzione, dato che la gran parte del flusso di dati procede dal server verso l’app. La comunicazione inversa dall’applicazione al server sarà limitata alla gestione delle query e alla fornitura di alcuni dati quali la registrazione delle transazioni di acquisto o l’invio di dati di monitoraggio (“analytics”). Si raccomanda allo sviluppatore di gestire la comunicazione tra Store Manager e server per mezzo di un livello di intermediazione. Il vantaggio di questo approccio è che lo Store Manager esporrà un insieme di API generiche e ben identificate mentre il livello intermedio di comunicazione si comporterà da driver specifico per il tipo di back-end. In questa maniera sarà possibile riutilizzare lo Store Manager per applicazioni che pur presentano back-end molto differenti.

Ogni qual volta un certo numero di informazioni sulle riviste viene trasmesso dal server all’applicazione, lo Store Manager si occuperà di creare gli Issue Model.

L’issue model è la rappresentazione logica di ogni singola rivista ed in genere è costituito da un identificatore univoco (non visibile all’utente), un titolo, una data di pubblicazione, un’immagine di copertina, una URL di download (nel caso il numero fosse gratuito) e una URL di preview, un’eventuale indice o sommario, una breve descrizione dei contenuti. Si noti che tra queste informazioni è stata volutamente tralasciata l’informazione di prezzo. Questo perché attualmente l’unica forma autorizzata di acquisto on-line tramite iPad deve avvenire per mezzo dell’In App Purchase (App Store) e le informazioni di prezzo derivano da quest’ultimo. Ciò significa che lo Store Manager dovrà farsi carico, una volta raccolte le informazioni sui vari numeri, di contattare l’App Store per verificare l’effettiva vendibilità del prodotto e conoscere il prezzo di vendita espresso nella valuta indicata dal cliente nelle impostazioni di sistema.

Inoltre l’issue model potrà cambiare durante il ciclo di vita all’interno dell’app. Questo perché una volta che l’utente avrà provveduto all’acquisto si dovrà senza indugio memorizzare localmente l’informazione ottenuta. Inoltre può essere elegante poter fornire una vista della vetrina anche in assenza di connessione internet, se non altro per non presentare l’app con un laconico messaggio di errore e una vetrina vuota (in pratica come un negozio che nel giorno di chiusura abbassasse le saracinesche). E’ vero che non si potrà concludere nessuna transazione ma se non altro i prodotti saranno visualizzabili. Questi motivi giustificano la presenza del Local Storage come copia locale dei dati associata agli Issue Model.

Nella parte inferiore dello schema precedente abbiamo indicato i due blocchi che si occupano dell’interfaccia utente, ossia la Store View e la Library View (abbiamo volutamente escluso il Reader dato che esso si comporta come un componente aggiuntivo – sebbene essenziale – non vincolante ai fini dell’architettura). In questo schema le due viste sono state volutamente tenute separate per evidenziarne la diversa natura, ma ricordiamo che in molti casi possono essere unificate in un’unica schermata.

Al fine di poter garantire l’approccio MVC, le due viste comunicheranno con lo Store Manager per mezzo di un protocollo di delega (delegate protocol). In sostanza la vista farà delle opportune richieste allo Store (quanti numeri ci sono? quali sono i numeri?) e si comporterà di conseguenza per la rappresentazione visuale. La comunicazione sarà di tipo bidirezionale (questo perché la vista deve trasmettere le scelte dell’utente allo Store) e occorrerà prevedere anche una comunicazione asincrona basata sulle notifiche o sul KVO (key-value observing). Il motivo di quest’ultima richiesta nasce dal fatto che lo Store Manager in genera lavora indipendentemente dal fatto che lo Store View stia facendo o meno delle richieste, ma quest’ultimo ha bisogno di essere aggiornato nel caso vi fossero delle novità sostanziali. Esempio: stiamo sfogliando la vetrina, quando termina il download di un numero precedentemente acquisito. In tal caso la Store View dovrà essere aggiornata dell’avvenuto cambiamento e modificare la grafica in maniera adeguata. Oppure: decidiamo di monitorare il progresso del download di un numero, sarà opportuno che la Store View osservi l’andamento del progresso per poter aggiornare la progress bar in maniera opportuna.

Lo Store Manager infine dovrà mantenere i contatti con due servizi forniti da Apple: l’In App Purchase e il Newsstand.

Abbiamo già introdotto in precedenza l’In App Purchase. Ricordiamo che ad esso si accede tramite il framework integrato Store Kit. Anche qui è buona norma avvalersi di un’interfaccia semplificata nello Store Manager e delegare il lavoro di comunicazione con lo Store Kit a moduli adhoc. Un ottimo esempio open-source e’ l’MKStoreKit. Inoltre la presentazione dello store (non mostrata nel diagramma) avverrà in maniera modale per poter catturare l’attenzione dell’utente e costringere quest’ultimo a dedicarsi esclusivamente all’operazione di acquisto.

L’altro servizio è il Newsstand. Quest’ultimo sarà parte integrante di iOS5 che al momento in cui scriviamo è ancora in beta. Come sviluppatori siamo legati all’NDA con Apple per cui ci limiteremo a esporre del Newsstand solamente il materiale marketing presente nel sito di Apple. Fondamentalmente il newsstand rappresenterà una sorta di ufficio centrale per la gestione delle pubblicazioni in sottoscrizione e si presenterà all’utente finale come uno speciale folder contenente le copertine degli ultimi numeri delle app installate nel sistema. Un’app su iOS5 non potrà fare a meno di dover essere compatibile con il Newsstand.

Nel prossimo articolo entreremo nel dettaglio dei vari blocchi implementativi e cominceremo la costruzione di una semplice app per la lettura di riviste.

L’articolo è disponibile in inglese su iOS Blog.

Sin dal momento dell’ introduzione dell’iPad nel mercato,uno dei generi più apprezzati di applicazioni è stato senza dubbio quello delle app per poter leggere libri, rivieste e giornali. Durante il suo anno di vita, tutti i maggiori editori hanno reso disponibili per iPad le loro principali testate, a cui si sono aggiunti – tra gli editori minori – inizialmente un manipolo di coraggiosi e poi, visto il numero straordinario di dispositivi venduti in poco tempo, tantissimi editori si sono a poco a poco convinti a portare i loro prodotti sul tablet di Apple. Nonostante le potenzialità di guadagno siano ancora da discutere – e nel mondo dell’editoria si stia ancora cercando la strada giusta per rendere profittevole questo tipo di attività (dato che comunque vige la regola non del tutto giustificata che ciò che si trova su Internet debba essere gratis) – senza dubbio esiste per gli editori un’ampia possibilità di scelta su come entrate nell’App Store.

Attualmente un editore si trova a dover compiere un certo numero di scelte, le quali a loro volta influenzeranno i costi di sviluppo, di manutenzione di un eventuale server e infine il flusso stesso di preparazione della rivista. In particolare l’editore dovrà:

• scegliere se è preferibile pubblicare la sua testata con un’app specifica, o affidarsi ad app di tipo “newsstand” del tipo di Zinio
• decidere se contattare una software house per uno sviluppo dedicato, o affidarsi a dei servizi su internet che consentono una pubblicazione più rapida ma con possibilità di personalizzazione limitate
• verificare se converrà ospitare i servizi di back-end su un proprio server o utilizzando un servizio di terze parti
• infine dovrà decidere se mantere il proprio flusso di pubblicazione via file pdf o affidarsi ad una soluzione completamente diversa che però potrebbe avere un grande impatto nel flusso di preparazione del prodotto.

Come sviluppatori “mobile” abbiamo ricevuto in dono da RIM un nuovo BlackBerry PlayBook, attualmente alla ricerca di software house che aiutino a popolare l’app store del nuovo tablet di casa BlackBerry.
Il dispositivo in prova e’ un modello Wi-Fi con schermo da 7″ e memoria SSD da 16 GB.
Abbiamo svolto questa presentazione in collaborazione con il “Social Blogger” Enrico Giubertoni Buzzes che ci ha ospitato nella sua splendida casa sul Lago d’Orta.
Godetevi il filmato… oppure leggete le nostre considerazioni.

A prima vista eravamo piuttosto scettici su questo dispositivo, viste soprattutto le difficolta’ avute nello sviluppare le prime applicazioni in un ambiente basato esclusivamente sul simulatore e con una “burocrazia” da submission a review non inferiore a quella di Apple (soprattutto nei primi tempi). Ad ogni modo siamo riusciti a mettere nello Store le nostre prime app e finalmente a entrare in possesso di questo dispositivo, che ricordiamo non e’ ancora disponibile sul mercato italiano.

A freddo possiamo dire che il tablet PlayBook avra’ un bel futuro, ammesso che il numero delle applicazioni cresca e che il dispositivo venga dotato di una propria indipendenza di rete (secondo noi un device cosi’ maneggevole non puo’ essere venduto senza la possibilita’ di connessione dati via 3G).

In breve, ecco gli aspetti positivi:
- veloce
- maneggevole
- graficamente curato
- interfaccia utente gradevole
- ottimo schermo LCD e molto sensibile al touch
- fotocamera e videocamera di qualita’
- browser con supporto Flash
- BlackBerry bridge (tethering via telefono BlackBerry)

E quelli negativi:
- prezzo (se confrontato con iPad)
- applicazioni: poche (a campione: avremmo voluto editare questo blog su WordPress su un’app nativa, e non c’era; abbiamo cercato Skype: nulla da fare)
- scalda un po’ troppo sul retro (il processore pero’ e’ davvero potente)
- spessore eccessivo (se confrontato sempre all’iPad)
- assenza di connesione 3G
- non siamo riusciti a connetterlo via Bluetooth al nostro iPhone 3GS per effettuare il tethering

Come programmarlo:
Java, WebApp (HTML 5 + Javascript), Adobe Flash, Adobe Air.
Ci piacerebbe che la RIM si concentrasse piu’ su un unico ambiente di sviluppo. Inoltre si parla di compatibilita’ con le app Android (da noi non provata). Sinceramente questo mix di ambienti non ci pare un buon segno, e’ come se la RIM non sapesse bene su cosa puntare e “sparasse” un po’ in tutte le direzioni. Sarebbe il caso di prendere delle decisioni strategiche e non farsi trascinare dalle onde. Anche perche’ l’hardware e’ davvero buono.

Infine:
non ha senso confrontarlo con l’iPad. I due dispositivi hanno dimensioni completamente diverse (l’iPad ha uno schermo di area esattamente il doppio del PlayBook) e quindi il loro utilizzo sara’ diverso. Secondo noi l’iPad e’ piu’ adatto a sostituire un computer netbook, mentre il PlayBook lo preferiremmo in condizioni di portabilita’ estrema.

Quando l’anno scorso debutto’ l’iPad, con esso inizio’ la sua attivita’ il primo processore SoC (System on chip) progettato interamente in casa Apple specificatamente per iOS, l’A4. In seguito questo oggetto venne installato nell’iPhone 4, nell’iPod Touch e per finire nell’Apple TV. Per chi volesse ripercorrere la storia dell’A4, basta leggere il nostro articolo uno sguardo al cuore dell’iPad, pubblicato quasi un anno fa. Allora presentammo i risultati dell’analisi fatta da EETimes (www.eetimes.com) che si concludeva col fatto che sicuramente il progetto del chip era frutto dell’acquisizione delle ditte Intrinsity e PA Semi, mentre a livello di blocchi si trovarono molte similitudini con S5PC110. Nel frattempo pero’ le cose sono cambiate di molto, dato che Apple ha avuto tempo per sviluppare il successivo A5 mentre Samsung ha deciso di migrare su altra piattaforma. Il reverse engineering effettuato da ditte specializzate sull’A5 ha mostrato un notevole incremento nella dimensione del die, passato dai 53 mm² dell’A4 ai 122 mm² dell’A5. Cerchiamo di giustificare dunque queste maggiori differenze.
Innanzitutto il processo produttivo: e’ lo stesso, il 45-nm di Samsung. I blocchi analogici (Wi-Fi a audio) sono praticamente gli stessi. Ovviamente A5 e’ un dual-core, quindi i blocchi CPU+GPU occuperanno almeno il doppio dell’area, oltre al fatto che sara’ necessaria una logica di “arbitraggio” per gestire i flussi di dati tra i due core. Aggiungendo nel conteggio il contributo dovuto ai blocchi di I/O e controllo della memoria, scopriamo che nel processore A5 avanza molta piu’ area di quanta ne e’ avanzata nell’A4. Che cosa ci ha messo Apple in questo spazio aggiuntivo? Probabilmente, ma non si puo’ dirlo con certezza, si tratta di acceleratori hardware pensati specificatamente per il video (e guarda caso infatti solo con iPad 2 troviamo lo streaming completo in HD) o il supporto alle estensioni NEON SIMD specifiche per il multimediale. I vantaggi di questo approccio, rispetto a una magari piu’ flessibile soluzione general purpose, sarebbero un minor consumo di potenza e un aumento in velocita’: ma la perdita di flessibilita’ non puo’ preoccupare piu’ di tanto Apple che ha comunque il pieno controllo del software che dovra’ girare su questi processori. In pratica Apple non avrebbe fatto altro che ingrandire il proprio chip (o sfruttare lo spazio in eccesso) per portare sul “metallo nudo” certe funzioni, particolarmente dispendiose, che prima giravano come software.
Certo questa e’ una sfida per Apple: a parita’ di processo produttivo infatti, un chip piu’ grande sara’ sostanzialmente piu’ costoso. Quindi Apple non avrebbe fatto altro che spostare delle funzioni software verso l’hardware a un maggior costo pero’. E’ chiaro che qui e’ stata presa una decisione strategica: puntare con maggiore enfasi su un mercato a cui la Apple tiene particolarmente, quello dei prodotti consumer basati su iOS, e allo stesso tempo differenziandosi dalla concorrenza, ancorata a soluzioni piu’ flessibili e pensate per supportare molteplici dispositivi e sistemi operativi, ma che probabilmente renderanno a questi ultimi la vita piu’ difficile nel campo dell’innovazione.

Questo articolo e’ una libera traduzione di un articolo, molto piu’ ricco di informazioni (e decisamente piu’ tecnico), apparso su EETimes. Per chi volesse approfondire puo’ leggere l’articolo originale

La piattaforma “i3f editorial” si poggia su 4 basi portanti:
- elaborazione e lettura di documenti in formato PDF
- l’utilizzo di web service e network queue
- l’infrastruttura Apple per l’In App Purchase
- i servizi web di ausilio all’editore

Vediamoli in dettaglio.

PDF Reader

Alla base della lettura dei documenti si trova il PDF Reader. Per capire il lavoro che si trova dietro questa tecnologia cominciamo col fare riferimento a quel che iOS fornisce ai propri sviluppatori.
Il supporto PDF e’ un supporto nativo all’interno del framework Quartz, il framework grafico 2D installato in Mac OS X e portato con successo in iOS. Per capire l’importanza del PDF all’interno dei sistemi operativi di casa Apple, basti sapere che il PDF non e’ visto come un qualunque formato di output, ma di fatto qualunque vista grafica all’interno di Mac OS X e iOS puo’ essere riprodotta come un PDF, che di fatto risulta essere il formato principe per la stampa basata su Quartz. Questo spiega perche’ sia in Mac OS X che in iOS il supporto al PDF, sia in ingresso che in uscita, e’ naturale e non richiede l’installazione di software esterni (come avviene per esempio in Windows, dove l’input richiede l’installazione di Adobe Reader, l’output richiede l’utilizzo di appositi plug-in).

Detto questo, cio’ non significa che le cose siano facili. Infatti il supporto fornito da iOS si limita sostanzialmente alla possibilita’ di “leggere” e capire un file PDF, ma limitatamente alle funzioni di rendering su carta o video, mentre l’interpretazione di tutti gli altri dati (outline, thumbnail, annotazioni, ecc.) e’ lasciata al programmatore.
Il PDF Reader fornito con le app prodotte tramite I3F Editorial e’ un continuo work in progress, soggetto a continui miglioramenti e supporto di nuove possibilita’. Attualmente esso offre le seguenti funzionalita’ di base:
- supporto di iPhone e iPad
- rendering veloce della pagina in formato portrait (orizzontale) e landscape (verticale, a due pagine affiancate), con caching per velocizzare le prestazioni
- nessun limite nel numero di pagine supportato (o comunque nessun limite in aggiunta a quelli eventuali forniti dalla piattaforma iOS)
- completamente basato sul motore di rendering di iOS, quindi nessuna sorpresa nel passaggio dell’applicazione tra diverse versioni del sistema operativo
- caricamento dei thumbnail in multi-threading
- mini-thumbnail (stile iBooks)
- funzione scrubbing della pagina (con visualizzazione del numero di pagina e/o del thumbnail)
- pre-caricamento di outline (il sommario con tutta la sua struttura gerarchica) e delle annotazioni (link)
- annotazioni intra-documento (salto di pagina), e verso link esterni
- oltre al supporto standard dei link esterni (http: e mailto: all’interno dell’applicazione, eventuali altri schemi url verso altre app installate dall’utente, esempio skype:) supportiamo dei link proprietari per lo streaming video direttamente dall’app e per la visualizzazione di gallerie fotografiche; cio’ significa che l’editore sara’ in grado di generare dei pacchetti multimediali (file PDF + contenuti multimediali) semplicemente definendo i link all’interno del suo strumento grafico di produzione dei PDF, senza dover appesantire e implementare tutte quelle complicazioni tecniche dovute all’inserimento dei file multimediali direttamente all’interno del PDF (ricordiamo infatti che Quartz non supporta questi tipi di file, di fatto scartando queste informazioni). Il supporto di questi link e’ via via in aumento.
- funzione di ricerca dei testi in multi-threading (ossia la fruizione del documento non viene bloccata)
- salvataggio dell’ultima pagina vista (auto-bookmark)

Gestione della libreria

L’interfaccia di libreria definita da I3F Editorial si basa su alcuni template standard comunemente riconosciuti (esempio: copertine su scaffale stile iBooks, oppure copertine in finestra stile App Store), sebbene I3F Editorial non sia un pacchetto software ma un team di designer e sviluppatori in grado di implementare qualunque richiesta provenga dall’utente. L’iPad e’ una formidabile piattaforma creativa, pertanto sono benvoluti gli editori che vogliono portare questa creativita’ anche all’interno delle applicazioni.
Quel che e’ comune invece e’ l’aspetto tecnico dietro questa approccio. Attualmente la composizione dell’archivio dell’editore, e della libreria utente, sono contenuti all’interno di file (di vario formato, a seconda della complessita’ dell’archivio, si va dal JSON all’XML a veri e propri database SQLITE per le configurazioni piu’ complesse). I file sono gestibili interamente dall’editore mediante la nostra piattaforma web e possono essere installati su server proprietari o in hosting presso i3factory (che si avvale a sua volta di provider di reputata affidabilita’). In ogni momento l’editore e’ in grado di variare la composizione del proprio archivio e renderla immediatamente operativa con un solo click, previo testing pre-pubblicazione possibile sempre mediante le nostre applicazioni.
Una volta che l’archivio viene definito, l’applicazione alla partenza cerca di aggiornarsi all’ultimo stato disponibile. Da questo momento ogni pubblicazione puo’ superare diversi stati: in negozio (se a pagamento), da scaricare (se gratis o gia’ acquistata), da installare, da leggere. Il passaggio di questi stati e’ effettuato in maniera sicura e interamente in multi-threading: cio’ significa che l’utente puo’ interagire con l’applicazione (o addirittura sospenderla nel caso di download) senza dover necessariamente attendere il download dell’intero pacchetto. Inoltre i file multimediali possono essere impacchettati in un unico file – in tal caso pero’ il tempo di download sara’ piu’ lungo – oppure possono essere scaricati su richiesta (questo quando i contenuti multimediali sono ritenuti opzionali alla fruizione del prodotto).

In App Purchase

Facendo seguito alle ultime novita’ introdotte da Apple nelle regole di approvazione delle applicazioni e dei contenuti a pagamento, noi forniamo come soluzione unica di acquisto quella dell’In App Purchase, ossia la possibilita’ di acquistare le pubblicazioni via App Store (ricordiamo che per queste transazioni Apple trattiene il 30% del prezzo applicato al cliente).
In ogni caso i3factory e’ disposto a fornire soluzioni di acquisto complementari all’In App Purchase, basate su pagine web esterne fornite dall’editore. Tali soluzioni non sono fornite come standard e vanno di volta in volta concordate, questo peche’ occorrera’ considerare di volta in volta tutte le complessita’ dovute alla sicurezza delle transazioni e dei pagamenti fatte via web. I3F non effettua alcun tipo di supporto su forme di pagamento diverso da App Store, che dovranno essere quindi curate dal cliente: in tali casi I3F si occupera’ esclusivamente dell’integrazione all’interno dell’applicazione.

I servizi web per l’editore

L’editore sara’ in grado di gestire l’archivio delle pubblicazioni via interfaccia web, basata su metodologie standard Web 2.0. Tale interfaccia consentira’:
- l’inserimento di nuove pubblicazioni
- la definizione dei link multimediali e il caricamento dei contenuti
- la gestione degli archivi (modifica, cancellazione, organizzazione in categorie e testate)
- la possibilita’ di rimuovere temporaneamente dalla vendita certe pubblicazioni
- transazioni cifrate anti-hacking
Ricordiamo che data la presenza dell’In App Purchase, eventuali contenuti in vendita e prezzi dovranno essere replicati all’interno del servizio iTunesConnect di Apple. Per regolamento non possiamo fornire soluzioni che automatizzino questa operazione.
L’intero pacchetto verra’ fornito in pacchetti auto-installanti basati su php e richiederanno da parte del server un supporto software minimo e che riteniamo sia standard nella gran totalita’ delle installazioni adatte a un editore.

Ecco una curiosita’ dovuta probabilmente a una distrazione degli sviluppatori Apple.
Se avete installato la nuova versione 10.6.6 di Mac OSX avrete notato la grande novita’ software di questa versione, ossia la presenza dell’applicazione “Mac App Store” (MAS).
Ora non tutti sanno che le impostazioni di un’applicazione effettuabili con il menu “Preferences…” (o equivalente in italiano… scusate, da sviluppatore uso il mio Mac in lingua inglese con tastiera americana, lo avrete notato dagli apostrofi al posto degli accenti, tanto che “à” diventa “a’”) sono un piccolo sottoinsieme delle impostazioni globali accessibili da un’applicazione.
Queste ultime sono accessibili solo via terminale (o mediante qualche applicazione esterna tipo MacPilot) usando il comando defaults. In particolare provate ad eseguire queste istruzioni:

1. chiudere l’applicazione “App Store”
2. aprire il terminale
3. digitare il comando defaults write com.apple.appstore ShowDebugMenu -bool true che abilita il menu di Debug dell’applicazione
4. riaprire l’applicazione “App Store”

Noterete l’aggiunta del menu Debug.
A questo punto ATTENZIONE: non giocate con le opzioni senza saperne il significato, potreste creare problemi all’applicazione, al sistema o peggio addebitare la vostra carta di credito senza fare acquisti…
L’unica curiosita’ che giustifica il titolo del post e’ legata all’opzione “Show Debug Panel…”. Selezionandola si aprira’ una finestra sul pannello di Debug dell’applicazione. In particolare noterete la voce “Fake Server Location” che presumibilmente si riferisce a un server interno ad Apple:

http://porco.apple.com/cgi-bin/Firenze

A quanto pare lo sviluppatore e’ un conoscitore di Firenze, dato che ci viene spontaneo pensare ad un riferimento alla Loggia del Mercato Nuovo nota anche come “Loggia del Porcellino” per la “Fontana del Porcellino” (in realta’ un cinghiale) posta ai margini della loggia.

Resta comunque la curiosita’ se non altro per capire come ad Apple effettuano il debug, in maniera decisamente elegante se si prendono la briga di creare un’interfaccia ad-hoc (sebbene non curata graficamente come le altre, ma questo e’ ovvio).

Con l’introduzione dell’iPad gli sviluppatori si son trovati di fronte al dilemma se sviluppare applicazioni separate per iPhone e iPad oppure rilasciare un’unica app “universale” valida per entrambi i dispositivi.

Indipendentemente da eventuali scelte di marketing, che potrebbero far propendere verso applicazioni separata col vantaggio di poterne vendere due al posto di una, in questo articolo spiegheremo quali sono i vantaggi che si possono ottenere dallo sviluppo di una singola applicazione e alcuni utili suggerimenti su come impostare il lavoro.

Prima di addentrarci nelle caratteristiche di un’applicazione universale, e’ bene rammentare come avviene il caricamento e il lancio di un’applicazione in iOS.

CARICAMENTO E LANCIO DELL’APPLICAZIONE

La figura in basso, tratta come sempre dall’eccellente documentazione Apple fornita col gratuitamente col pacchetto XCode dal sito http://developer.apple.com, mostra qual e’ la sequenza degli eventi che si scatena dal momento in cui l’utente tocca sull’icona dell’applicazione che intende lanciare.

Essendo Objective-C nient’altro che un’estensione del C, un’applicazione parte con l’esecuzione della funzione main(). Utilizzando i template forniti con XCode, la funzione main() contiene il seguente codice, che e’ bene non modificare mai a meno di esigenze molto particolari:

Quel che fa questo codice e’ essenzialmente lanciare la funzione UIApplicationMain() il cui compito consiste innanzitutto nell’instanziare l’oggetto UIApplication, il cui scopo e’ quello di creare e eseguire il motore delle applicazioni iOS, il cosiddetto Event Loop. Non entreremo in quest’articolo nella descrizione dell’Event Loop (lo faremo prossimamente) ma per ora basti sapere che ogni qualvolta l’utente tocca lo schermo del suo dispositivo, il tocco viene catturato dall’Event Loop e smistato alla porzione di codice che si occupera’ di gestirlo.

Dato che l’oggetto UIApplication e’ unico e gestito dal sistema operativo, come facciamo a inserire il nostro codice all’interno di questo meccanismo di start-up dell’applicazione? La risposta e’: tramite l’”application delegate”. Uno dei compiti della funzione UIApplicationMain e’ infatti quello di instanziare il nostro Application Delegate e, durante la fase di lancio, fornirgli il controllo tramite la ben nota chiamata al metodo “application:didFinishLaunchingWithOptions:”. In questo metodo noi inseriremo la nostra logica iniziale, creeremo i nostri view controller e comunque ci consentira’ di far partire la nostra app.

Riassumendo: l’utente tocca l’icona dell’applicazione, il sistema operativo carica l’app e chiama la funzione “main()”, la funzione main chiama la funzione UIApplicationMain, quest’ultima instanzia l’oggetto (unico) UIApplication, il quale avvia l’Event Loop e chiama il suo “delegate” affinche’ quest’ultimo esegua il codice di inizializzazione proprio dell’applicazione.

Quel che resta da definire a questo punto e’: come fa UIApplication a conoscere il suo “delegate”? la risposta e’: questa informazione viene fornita tramite il file Info.plist con la chiave “NSMainNibFile” (indicata in XCode come “Main nib file base name”). Questo nib file, che in genere nei template di XCode si chiama MainWindow.xib, conterra’ un oggetto AppDelegate che sara’ collegato all’outlet “delegate” del File’s Owner, che non e’ nient’altro che il nostro oggetto UIApplication.

Quindi UIApplicationMain svolgera’ oltre al compito sostanziale di instanziare UIApplication anche quello di caricare l’NSMainNibFile e collegare l’instanza di UIApplication (nota come “sharedApplication”) all’AppDelegate.

Questa lunga spiegazione e’ necessaria per capire come far partire un’app universale. In genere i template di XCode per le applicazioni univesali forniscono due diversi NSMainNibFile, uno denominato NSMainNibFile – e usato di default – un altro denominato NSMainNibFile~ipad che, se definito, verra’ caricato nel caso l’app venisse lanciata da un’iPad.

In genere le due chiavi devono puntare a due finestre differenti, dato che sono differenti le dimensioni degli schermi, e il programmatore potrebbe scegliere di instanziare i due UIViewController iniziali, che potrebbero essere profondamente diversi, gia’ nel nib file iniziale. Quel che pero’ fa il template di XCode e’ collegare all’UIApplication delegate outlet due diverse istanze di AppDelegate, denominate rispettivamente AppDelegate_iPhone e AppDelegate_iPad.

Da questo momento in poi le due app prenderanno strade sostanzialmente differenti e sara’ compito del programmatore gestire i due “rami” di codice e cercare di accomunare tra loro quelle porzioni di codice che sono indipendenti dall’interfaccia grafica.

Compito di questo articolo e’ indicare alcune regole pratiche che faciliteranno il compito del programmatore cercando di accomunare il piu’ possibile le porzioni di codice.

APPLICATION DELEGATE UNIFICATO

Il primo approccio rivolto all’unificazione del codice e’ quello di definire un unico application delegate. Come detto in precedenza il template “Universal app” di XCode tende a creare due app delegate praticamente identici, uno per iPad e l’altro per iPhone, e referenziarli in due MainWindow.xib differenti, che e’ bene rimangano tali dato che in questa sede si potrebbero gia’ cominciare a definire le peculiarita’ grafice delle due app (se non altro, le due Window hanno gia’ dimensioni differenti!).

Pertanto il nostro approccio sara’ cancellare uno dei due delegate dal nostro codice (ad esempio AppDelegate_iPad) e sostituire nel MainWindow ad esso associato (nell’esempio: MainWindow_iPad) l’oggetto corrispondente.
In questa maniera l’eventuale caricamento di dati essenziali all’applicazione e il codice richiesto dal protocollo di UIApplicationDelegate sara’ comune nei due casi.

ORGANIZZAZIONE DEL PROGETTO

Per mantenere un certo ordine nell’organizzazione del progetto, e’ buona norma definire tre gruppi all’interno di XCode, denominati Shared, iPhone  e iPad, rispettivamente utilizzati per i file comuni, specifici all’iPhone e specifici all’iPad. Nel nostro caso inseriremo l’AppDelegate comune nel gruppo Shared.

FORCHETTE NEL CODICE

E’ ovvio che tanto piu’ si condivideranno delle porzioni di codice, tanto piu’ sara’ necessario discriminare all’interno di tale codice se si sta eseguendo l’app in un iPad o in un iPhone/iPod Touch, dato che sarebbe presuntuoso pensare di poter scrivere del codice sempre indipendente dal device, specialmente nei View Controller e nelle View.

A tal fine e’ bene aggiungere nel proprio file “Prefix.pch” la definizione seguente:

La funzione isPad(), una volta chiamata, restituira’ YES se l’app viene lanciata in un iPad, NO altrimenti. Questo codice si basa sulla funzione “userInterfaceIdiom” definita nella classe UIDevice. Se questo metodo fornisce in risposta la costante UIUserInterfaceIdiomPad allora siamo in un iPad, altrimenti no. Pero’, dato che questa funzione e’ stata introdotta solamente con la versione 3.2 di iOS, ossia quella che ha introdotto l’iPad (in questo possiamo dire che in Apple non sono stati molto lungimiranti!), per poter garantire la compatibilita’ con versioni precedenti di iOS dobbiamo controllare che questa funzione esista e possa essere chiamata (se non lo facessimo, la nostra app andrebbe miseramente in crash). E’ ovvio che una risposta negativa a questo check implicherebbe una versione di iOS precedente alla 3.2 e quindi il dispositivo non puo’ essere un iPad.

Quindi, tutte le volte che dovremo gestire una qualche eccezione tra i due dispositivi, ci sara’ sufficiente creare una condizione if…else… su isPad() e gestire il comportamento dell’app nei due casi.

IL PATTERN MVC

La programmazione in iOS si basa profondamente sul paradigma Model-View-Controller (MVC).
Questo pattern architetturale prevede che un software sia articolato nelle tre unita’ fondamentali: Modello, Vista e Controllore. Il modello si occupa della gestione dei dati di un’applicazione, le viste gestiscono l’interfaccia utente e la rappresentazione grafica mentre il controller si occupa della logica dell’applicazione mettendo in comunicazione il modello con la vista.

E’ evidente che il Modello prescindera’ sempre dalla natura del dispositivo, in particolare nel nostro caso saremo facilitati dal fatto che sia l’iPhone che l’iPad condividono esattamente le stesse classi e le stesse funzioni per tutto cio’ che riguarda la gestione dei dati (le cosiddette “foundation classes”, ma anche il file system e i vari media framework o l’accesso ai sensori). Pertanto massima cura dovra’ essere data al progetto dell’app affinche’ i moduli comuni non direttamente legati alla rappresentazione grafica siano spostati all’interno del modello.

Talvolta si tende a integrare alcune funzionalita’ all’interno dei View Controller, questo per semplicita’ nella scrittura del codice: dato che il View Controller gestiste il flusso dell’applicazione perche’ non inserire certe funzionalita’, quali ad esempio quelle di networking, all’interno del View Controller? sebbene questo approccio continui ad essere sempre valido, occorre considerare il fatto che in taluni casi non e’ conveniente condividere tra i due dispositivi lo stesso View Controller, e in tal caso tali funzionalita’ andrebbero replicate con evidenti problemi di manutenzione del codice. Per cui si consiglia di spostare quanto piu’ possibile queste operazioni all’interno dei modelli, e sfruttare i meccanismi di comunicazione di Objective-C (protocolli, KVO, notifiche) per far colloquiare i modelli coi controller.

VISTE CONDIVISE

Condividere le viste, ossia le varie UIView e tutte le loro sottoclassi, e’ compito in genere abbastanza arduo. In genere si sconsiglia di costruire una vista per iPad partendo da quella per iPhone e “ingigantendola” di conseguenza: l’effetto e’ abbastanza sgradevole e comunque non renderebbe merito del magnifico display dell’iPad.

Quindi il consiglio che ci sentiamo di dare e’ quello di cercare di studiare l’interfaccia grafica tenendo conto delle caratteristiche dei due dispositivi e solamente in seguito pensare se e come unificare parti di essa. Vi saranno sicuramente dei casi in cui le viste possono essere condivise: si pensi ad esempio alle piccole miniature che si vedono in fondo al lettore di PDF integrato nell’app iBooks. Esse possono essere costruite (diciamo “possono” poiche’ non sappiamo se i progettisti di Apple abbiano seguito lo stesso approccio) usando un’unica vista che calcolando le dimensioni dello schermo sara’ in grado di conoscere il numero di miniature che potranno essere posizionate. Inoltre le stesse dimensioni delle miniature, dato che saranno diverse fra i due schermi, potranno essere discriminate grazie all’uso della nostra funzione isPad(). Quindi senza ombra di dubbio un’eventuale classe “ThumbnailsView” potra’ essere inserita nel gruppo Shared del nostro progetto.

VIEW CONTROLLER

Non c’e’ ombra di dubbio che i View Controller, rappresentando la logica dell’applicazione e quindi la parte piu’ complessa, richiedono un’attenta valutazione prima di effettuare la scelta della condivisione o no. Infatti tenere separati i View Controller tra i due rami del progetto (iPhone e iPad) puo’ implicare una quantita’ eccessiva di codice ridondante. Ma allo stesso tempo un’eccessiva unificazione, soprattutto per quei View Controller che piloteranno viste molto differenti per i due schermi, potrebbe comportare a una tale ramificazione intra-codice e un numero cosi’ grande di biforcazioni da rendere il codice difficilmente leggibile.

Si tenga conto inoltre che certi elementi molto comuni nell’iPhone, come gli UITabController, sono raramente utilizzati nell’iPad, e quindi questo gia’ in partenza implica una netta separazione delle due porzioni di codice. Chiaramente gli UITabController istanziano a loro volta dei UIViewController che potrebbero essere unificati tra loro. Si pensi per esempio al caso di una mappa: i percorsi per arrivare alla mappa possono essere molto diversi fra due dispositivi, ma alla fine la vista, a parte alcune differenze, sara’ sostanzialmente la stessa: una mappa a tutto schermo con una toolbar o navigation bar per accedere ad altre funzioni.

Il prossimo paragrafo, sui Popover, fornira’ una soluzione molto comoda per unificare il maggior numero di View Controller possibile.

I POPOVER

L’iPad e’ dotato di un insieme di view controller unici, quali gli UISplitViewController e gli UIPopoverController.

Questi ultimi sono quei “fumetti” che appaiono di tanto in tanto nell’interfaccia delle app per iPad e che consentono di accedere ad alcune funzionalita’ extra dell’applicazione. Apple suggerisce nelle sue Human Interface Guidelines (HIG) di utilizzare questo controller tutte le volte che si vuole accedere ad alcuni sezioni dell’app senza distogliere l’utente dalla pagina principale. Questo approccio e’ molto diverso dall’iPhone, in cui il progresso all’interno di un’applicazione avviene tipicamente tramite le “sliding windows”, ossia le finestre scorrevoli da destra verso sinistra e gestite da un UINavigationController. A ragione, i redattori dell’HIG ritengono che far scorrere tali finestre in un’app per iPad non sarebbe il massimo, poiche’ date le loro dimensioni il tutto  risulterebbe essere oneroso per il processore (rendering grafico) e visivamente pesante. In questo la soluzione suggerita e’: aprire un popover all’interno della finestra e inserire il view controller al suo interno. E’ vero che nel tempo gli sviluppatori si sono sbizzarriti nell’ottenere soluzioni alternative a questo approccio, ad esempio con viste scorrevoli parzialmente, ma l’approccio dei popover risulta essere il piu’ immediato, abbastanza elegante e comunque perfettamente in linea con le HIG.

I popover possono essere sfruttati per unificare i view controller. Si consideri ad esempio il caso di una funzione “Impostazioni” che si vuole introdurre nell’app. Ovviamente date le differenti dimensioni dello schermo, per l’iPhone si potrebbe impostare una classica vista 320×480 contenente una tabella e mostrata per scorrimento. Nell’iPad occorrerebbe costruire una macro vista 768×1024 da mostrare in qualche maniera e magari difficile da riempire (e quindi da rendere esteticamente gradevole) soprattutto se il numero di impostazioni risultasse ridotto. In questo caso la soluzione migliore sarebbe creare un popover e inserire al suo interno una finestra di dimensioni, guarda caso, 320×480.

Pertanto avremmo lo stesso ImpostazioniViewController, studiato per un iPhone, e le differenze fra i due device sarebbero:

1. chiamata via NavigationController (“push”) per iPhone, via PopoverController per iPad
2. presenza della navigation bar con “Back” button per iPhone, presenza opzionale della navigation bar ma senza “Back” button

LE MODAL VIEW

Le modal view sono tradizionalmente utilizzate nell’iPhone per interrompere il flusso dell’applicazione e porre l’utente di fronte ad un’attivita’ che richiede la sua immediata e unica attenzione. Con l’iPad tali viste sono state estese per consentire un approccio diverso all’interazione con l’utente, ed e’ grazie a tale scelta che possiamo pensare ad un’ulteriore forma di condivisione del codice.

La differenza sostanziale e’ che mentre nell’iPhone la modal view appare sempre e soltanto dal basso verso l’alto a riempire tutto lo schermo, nell’iPad e’ possibile scegliere tra diversi approcci. Nel nostro caso l’approccio piu’ confacente alla condivisione e’ quello di mostrare la vista modale in modalita’ “Form Sheet”, con la quale la modal view appare al centro dello schermo, con dimensioni ridotte, con un effetto di “dimming” nelle aree lasciate scoperte.

In questo caso la nostra vista comune non avra’ le stesse dimensioni (nell’iPad e’ comunque piu’ grande) per cui dovremo gestirla affinche’ il ridimensionamento risulti adeguato. Ad ogni modo queste eccezioni possono essere facilmente gestite nel nostro codice tramite l’uso della funzione isPad() senza dover necessariamente ricorrere all’uso di View Controller separati.

CONCLUSIONI

Senza dubbio scrivere una buona app universale rapprsenta sempre una sfida. Ma se non altro i vantaggi che si ottengono in riutilizzabilita’ e manutenzione valgono lo sforzo. Inoltre l’impegno in piu’ richiesto per la definizione di un’architettura che favorisca la condivisione del codice verra’ premiato da un software che risultera’ essere piu’ ordinato, leggibile e estendibile.

Chiaramente questo obiettivo puo’ non essere facilmente raggiungibile, e invitiamo gli sviluppatori a non cimentarsi in imprese disperate per rendere universali tutte le app, soprattutto in quei casi in cui le due interfacce sono profondamente diverse, oppure il contributo dovuto ai modelli e’ insignificante oppure si proviene da un’app iPhone gia’ esistente e progettata con tutt’altri criteri.

Screenshot di PhotoGrap per iPad

Abbiamo avuto il piacere di provare un’ottima app per iPad da poco presente sull’App Store: PhotoGrab (iTunes link, questa invece e’ la pagina di supporto).

Questa app permette di navigare entro la propria libreria di iPhoto senza alcun software aggiuntivo e senza dover scaricare fisicamente le vostre foto all’interno dell’iPad.

Questo e’ possibile poiche’ se si attiva la funzione “sharing” (“condivisione”) su iPhoto e ci si trova sulla stessa rete locale, allora l’app sara’ in grado di consultare l’elenco delle foto, con tanto di album, e lanciare degli slideshow.

Con essa quindi non solo potrete guardare le vostre foto comodamente seduti in poltrona oppure sdraiati nel letto, ma se andate a casa di amici vi sara’ sufficiente portare il vostro iPad e connettervi alla loro libreria.

L’app permette oltre al semplice browsing, anche di lanciare degli slideshow oppure di selezionare alcune foto per essere scaricate nella memoria dell’iPad.

La navigazione e’ molto veloce e di fatto lo slideshow non presenta ritardi dovuti a caricamenti. Il comportamento e’ fluido, l’interfaccia intuitiva e l’app stabile. Lo sviluppatore ci ha comunicato che e’ attualmente in revisione da parte di Apple un aggiornamento dell’app che portera’ diverse bug fix e alcune nuove potenzialita’.

Attualmente il prezzo sull’App Store italiano si aggira sui 5 Eur. E’ un prezzo sopra la media ma la comodita’ che porta questa app li vale senza dubbio. Inoltre lo sviluppatore, Matt Long, e’ molto attivo nella comunita’ dei developer su Apple e il suo lavoro di divulgatore e blogger e’ senz’altro da apprezzare.

DeTelegraaf for iPad

Finalmente l’iPad e’ sbarcato anche in Italia, e l’App Store si e’ subito popolato delle applicazioni delle maggiori testate giornalistiche italiane, oltre che di qualche rivista.
Provate a scaricarne qualcuna, scegliendo tra Repubblica, Il Corriere della Sera, La Gazzetta dello Sport, Il Foglio, L’Unione Sarda, Mac Magazine (ma ve ne sono altre, che non abbiamo scaricato e provato dato che ci son bastati gli snapshot per capire dove saremmo andati a parare): sono tutte esattamente uguali (con La Repubblica che si distingue leggermente dal gruppo).
Non c’e’ nulla di male a che le applicazioni siano uguali, se non fosse che esse sono ben lontane da quel che dovrebbe essere un’app per iPad.
Escludiamo per ora dal gruppo l’app di Repubblica, che merita una trattazione a parte (e una stelletta in piu’ nel rating Apple, cosi’ permettendo di elevarsi dal mediocre 2 stelle alla sufficienza). Le altre si mostrano al pubblico come dei visualizzatori di PDF o meglio di PNG. Optiamo per la seconda scelta, dato che sono app abbastanza veloci (unico vantaggio) ma che di fatto si comportano come dei visualizzatori di un’unica grande immagine sulla quale sono impressionate tutte le pagine del giornale. Quindi la meravigliosa esperienza sensoriale che avrete leggendo questi giornali online sara’ semplicemente lo scroll e lo zoom lungo questo enorme foglio elettronico.
Un po’ poco, soprattutto se si confrontano queste app con quella del New York Times Editor’s Choice, quest’ultima si’ che rende giustizia all’iPad.
Si distingue leggermente La Repubblica +, forse un po’ piu’ lenta nel caricamento, ma che almeno permette di aprire l’articolo nella sua interezza (ahime’ senza immagini, ahime’ senza i link nel caso di rimando alla prima pagina, ahime’ con la disposizione a due colonne e scroll verticale, quando invece la lettura sarebbe facilitata se impostata a libro, si vedano nuovamente NYT o l’app iBooks) e con qualche contenuto multimediale (una bella galleria fotografica, un video).
A nostro avviso queste app cosi’ fatte avranno vita difficile quando i contenuti diventeranno a pagamento, cosa necessaria affinche’ il business dell’editoria sull’iPad diventi profittevole per gli editori. Attualmente forse il business l’hanno fatto i produttori di questa app (trattasi di una start-up italo-californiana) ma di certo non hanno un reso un gran servizio ne’ all’iPad ne’ alle testate nostrane. Questi ultimi da biasimare certamente, poiche’ presi dalla fretta di uscire per primi e del tutto incapaci di capire le potenzialita’ dell’iPad.
Il nostro auspicio e’ che queste applicazioni vengano aggiornate (oserei dire: rivoluzionate) il piu’ presto possibile e ben vengano le fotocopie, ma che non si presentino ancora sullo schermo dell’iPad le fotocopie delle pagine del giornale.

Il Foglio su iPad