English
Schermate dell’applicazione
Un’applicazione per la lettura di riviste si compone principalmente di 3 schermate principali, indicate in figura
(sebbene ci si riferirà in seguito all’iPad, tutte le considerazioni sono valide anche per l’iPhone e l’iPod Touch)
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.
