Icona Newsstand Icon

La rivoluzione iOS5

Molta acqua è passata sotto i ponti da quando abbiamo pubblicato la nostra prima parte di questo tutorial. Ci scusiamo per il ritardo, ma al momento di scrivere eravamo consapevoli delle nuove funzionalità introdotte con iOS5 ma eravamo ancora sotto NDA e non autorizzati a rivelare nulla del SDK. Finalmente siamo ora in grado di fornire l’esempio  della nostra applicazione per riviste e magazine  con compatibilità doppia: iOS4/iOS5 .

Non passeremo il tempo a spiegare tutte le caratteristiche della funzione Newstand (edicola), tutto sommato stiamo dandovi le informazioni per creare un app per leggere delle riviste e i dettagli d’implementazione Newstand  vanno oltre il nostro scopo originale.
Abbiamo scritto un tutorial di due parti, presente in inglese nel  blog personale del nostro CTO, che potete leggere qui, e che copre tutti gli aspetti Newstand e le richiesta (da parte di revisori Apple) in caso di abbonamenti.

In breve, Newstand (edicola) è un nuovo modo di presentare riviste nel iPad e iPhone, dove è sostituita l’icona originale dalla copertina della rivista o giornale, ed è posto sotto uno speciale gruppo dedicato a raccogliere tutte le icone Newstand installate dall’utente.
Per lo sviluppatore c’è anche un framework, chiamato Newstand Kit, che introduce una nuova metodologia per organizzare, scaricare e installare il contenuto dell’ App.

L’esempio di applicazione

La schermata mostra l’aspetto finale dell’ app. Un insieme di nove riviste con ongnuna un differente frutto in copertina.

È possibile scaricare una rivista, vedere il cambiamento barra di avanzamento mentre l’operazione è in corso e, infine, leggerla. La schermata mostra l’altro aspetto nel Newstand (edicola).
L’icona tipica è stata sostituita dalla rivista, come la rappresentanza all’interno del gruppo Edicola.
Invece, se eseguito su un iPad con iOS4 installato apparirà l’icona classica.

Il codice di un’applicazione completa è disponibile su GitHub. Non considerarla come un codice di produzione, quindi per favore non cercate di riutilizzare così com’è per la vostra app o con i vostri clienti se non avete provato in tutti i possibili casi limite.
In ogni caso può essere considerato come un valido punto di partenza per le applicazioni reali. In sostanza i principi alla base dell’architettura del codice sono stati descritti nella Parte I di questo tutorial, se non avete ancora letto vi consiglio di saltare al precedente articolo prima di leggere questo, almeno per capire i componenti chiave di tale applicazione.
Lo scopo di queto tutorial , guida o howto, è quello di capire e tenere la gestione dell’ issues management (controller, da non confondere con “View Controller”) separata il più possibile dalle UI (interfaccie utente). Ciò significa che in teoria il codice che sta dietro Store Manager and Issue Models  può essere riutilizzato anche in un applicazione Mac OSX , in quanto rapporto con cose come la UI è minimo.

Abbiamo installato questa applicazione utilizzando il modello di base di una singola finestra Xcode (the basic single window Xcode template) e poi aggiunto le due componenti principali del metodo all’avvio dell’applicazione (delegate startup method):

I due componenti sono:

la classe Store, che rappresenta il blocco Store Manager nell’architettura applicazione, questa classe è una sottoclasse di NSObject e non è legata all’interfaccia utente.
Il ShelfViewController rappresenta l’UI (interfaccia utente) dell’applicazione. E’ collegata allo Store (negozio) utilizzando una proprietà specifica. Si noti che il controller non avrà accesso alle proprietà Store esposte, ma otterrà le informazioni necessarie attraverso una semplice API.
Avremmo potuto utilizzare un modello di delega (delegate pattern), invece, ma poichè i due blocchi sono blocchi essenzialmente custom in un’applicazione personalizzata, non c’è proprio bisogno di definire un protocollo per la loro interazione. Possiamo dire che la parte del controller è stato suddiviso in due parti, una per l’interfaccia utente (UI), la mensola (the shelf), e uno per il back-end, il negozio (Store). Il loro legame è tale che la mensola dipende dallo Store (strict link), non viceversa.
Ogni Store per la comunicazione con il prodotto (shelf) utilizza le notifiche.

L’applicazione è stata poi integrata con le nuove esigenze Newstand nel plist info. Anche in questo caso dare un’occhiata alla documentazione di Apple per una guida dettagliata.

Modelli e Controller

Abbiamo un modello in questa applicazione, è il modello Issue che rappresenta un numero singolo del magazine o rivista nello Store (negozio) o nella libreria utente (user library). C’è anche un controller, che è il Store. Come abbiam detto questo controller non è un componente di UI (interfaccia utente), ma l’applicazione di back-end è autosufficiente con questi due componenti. In teoria siamo in grado di recuperare lo statuo negozio e riviste scaricate (store status and download magazines) anche senza alcuna UI (interfaccia utente). Questo è un concetto di base in applicazioni per riviste (Magazine Apps), in cui molti eventi avvengono in background non sono legati all’interazione diretta dell’utente : questo significa che l’applicazione dovrebbe essere in grado di eseguire diverse operazioni, anche se l’interfaccia utente non è stata caricata.

Il ruolo della “issue class” è quello di rappresentare tutte le proprietà rilevanti rivista, che sia un identificatore univoco, un titolo, una data di uscita, un collegamento alla immagine di copertina, ovviamente il link (URL) al contenuto (che può essere un file PDF, un file epub o un file zip per i pacchetti complessi).
In particolare, l’identificatore univoco (unique identifier) è un pezzo di dati che deve essere mantenuta lungo la vita dell’ issue: è l’unico modo per identificare univocamente un determinato issue, indipendentemente da problemi di localizzazione (ad esempio, il titolo può cambiare in diversi paesi, ma non l’ID univoco). Inoltre è il link per il modo in Newsstand (edicola) per identificare le issue  (il nome del campo NKIssue) e può anche essere utilizzato per collegare il prodotto con l’App Store, se abbiamo intenzione di implementare gli Acquisti In App o In App Purchases.

Oltre a  questo ruolo, le issue class avranno un ruolo centrale nel download di una rivista. In sostanza la classe Store (Store class) potra fare uno schedule e quindi potra’ programmare un download, ma questo sarà monitorato  dalla issue class (progress) e poi terminare (installazione effettiva della rivista/magazine ).

Infine, questa classe ha limitate capacità di rappresentare una rivista già scaricata e disponibile nella libreria utente (user library). Per questo mettiamo a disposizione la semplice isIssueAvailableForRead  che sara utilizzata da parte dell’interfaccia utente per sapere quali interventi sono possibili con un issue (leggere o scaricare) ed eventualmente visualizzarne il contenuto.

La classe Store è il controller app. E ‘inizializzato all’inizio delle app e la sua istanza non è mai rilasciata. Subito dopo l’inizializzazione DI questa classe verrà recuperato il contenuto dello store (negozio) dal server dell’editore.

In questo esempio abbiamo deciso di attuare il contenuto negozio come un semplice elenco delle proprietà, e poi istruire il negozio per recuperare questa lista di proprietà, decodificarlo e creare gli oggetti di emissione e, infine, scaricare le loro immagini di copertina. Tutto questo è fatto in modo asincrono utilizzando la Grand Central Dispatch e alla fine una notifica verrà inviata per informare tutti gli oggetti interessati (in particolare il controller della vista) che i contenuti Store sono pronti e l’interfaccia utente può essere tranquillamente visualizzata.
Si noti che il negozio è stato rappresentato da un property status. Abbiamo ignorato il  setter method, di inviare una notifica che informa ogni osservatore interessato del nuovo stato. Per semplicità abbiamo deciso di limitare i possibili stati di “non inizializzato”, “download”, “pronto” e “errore”. Una applicazione più compless può introdurre gli stati extra se necessario. Infine come ripiego in caso di collegamento mancante (l’utente deve essere in grado di accedere al suo / suoi contenuti, anche se non collegato a Internet) si potrà ricaricare una copia salvata in locale del negozio.

Il pezzo centrale del codice è nel metodo downloadStoreIssues della classe, che riportiamo di seguito:

Si noti che nel codice qui sopra, per semplicità, abbiamo messo in coda il  download della copertina (cover) subito dopo il property list download (download elenco di proprietà).
Probabilmente questo non è il modo migliore per fare questo, stiamo aggiungendo ulteriori networking steps  prima di presentare lo status dell’applicazione, con possibili ritardi se le condizioni della rete non sono buone. Possiamo fare questo in un esempio in cui sappiamo che il numero di problemi è limitato, probabilmente in una applicazione vera e propria ha più senso farlo in un processo in background e quindi notificare all’interfaccia utente di aggiornare il suo status ogni volta che una nuova copertina è pronta da visualizzare.

La “View Controller”

L’interfaccia utente si sveglia immediatamente, e cambierà il suo aspetto, basato sulle comunicazioni provenienti dal negozio. Quando il centro di notifica consegnerà al negozio “Sono pronto” come  messaggio per l’interfaccia utente, questo verrà caricato tutte le rappresentazioni problema UI (la classe CoverViewè  nel codice, una view di base con la logica dell’applicazione davvero minimo) e mostrare la shelf (mensola) all’ utente.

A questo punto l’applicazione ha terminato la sua elaborazione back-end ed è in attesa di comandi dell’utente. Qui abbiamo due possibilità:

Una rivista è stata scaricata, l’utente vedrà un pulsante “Leggi”, cliccando su di essa egli sarà in grado di leggerla.
Nel nostro esempio tutti i nostri contenuti sono costituiti di file Pdf, abbiamo deciso di utilizzare il framework Quick Look in iOS, che è sufficiente per i nostri scopi.
Una rivista non è ancora stata scaricata, l’utente vedrà un pulsante “Download”, cliccandoci sopra si avvia il download e ti mostrano una barra di avanzamento (progress bar). Alla fine avremo bisogno di sostituire l’etichetta del pulsante e nascondere il progress. Vedremo questa parte in modo più dettagliato.

La view controller dipende dallo Store (negozio). Al fine di ottenere le informazioni sull’issue(numero dell’issue, il dettaglio di ogni numero/issue) questa non avrà accesso direttamente alle proprietà del negozio, ma userà una API molto semplice, fatta di tre metodi:

Basandoci su questa informazione, e sulle propieta’ dell’ Issue (properties), si creerà la Issue view representation (CoverView) e sarà visualizzata sullo schermo.

Il download di una rivista o giornale

In una Magazine App ci sono tre sezioni critiche:
recuperare e visualizzare i contenuti negozio, scaricare il contenuto e, infine, leggerlo (un buon lettore PDF o EPUB  è obbligatorio in un app del genere, non è lo scopo di questo tutorial, mirato a spiegare l’architettura e le tecniche necessarie per rendere tale applicazione, ma è una parte rilevante l’esperienza utente).

Il nostro approccio nel download della rivista è che l’utente deve essere completamente libero di fare qualsiasi azione e tale azione non deve interferire con il risultato del download.
Ora molte applicazioni sono solite prendere una scorciatoia: hanno messo uno spinner al centro dello schermo, poi bloccano qualsiasi interazione dell’utente con gli oggetti dell’interfaccia utente dietro lo spinner per poi chiedere all’utente di aspettare.
E ‘facile fare questo, ma non è la migliore esperienza utente.
Durante attesa l’utente deve poter leggere un altro numero (issue), poter navigare all’interno del negozio o decidere di passare temporaneamente a un’altra applicazione o infine può perdere temporaneamente il collegamento con la rete.
Newsstand Kit fornisce una metodologia a livello di sistema che semplifica (in alcuni casi) la vita degli sviluppatori, ma al tempo stesso elimina ogni scusa per non fare un buon lavoro in termini di user experience.

Non appena l’utente attiva un nuovo download, il view controller invierà la sua richiesta di download alla classe Store. Nel codice qui sotto potete vedere il scheduleDownloadOfIssue:code.
Questo metodo prepara la richiesta di rete e la invierà in background. Si noti come abbiamo diviso il comportamento applicazione in base alla versione del sistema operativo siamo in. Se è iOS5 allora dobbiamo utilizzare l’approccio Newsstand-Edicola – dove il download saranno gestiti dal sistema in una coda Edicola -, se siamo in iOS4 faremo seguire una metodologia classica basata su NSOperation: in questo caso mi sono perso per la semplicità per ottenere la  content length del contenuto da scaricare, nel caso iOS4 la barra di avanzamento non viene visualizza. Questa informazione è invece fornita “for free” da Newsstand.

Nei due casi mi piacerebbe sottolineare il fatto che lo “Store” avvia l’operazione di download, ma poi  delega ogni ulteriore elaborazione alla parte interessata, l’ Issue da scaricare. Così sarà la classe Issue che monitorerà il download e poi lo finalizzerà.

La issue class (classe di Emissione) si comporterà come delegato dell’operazione di scaricamento innescata dalla Store class. Il delegate protocolrisulta differente se si sta utilizzando “Edicola” oppure no. Nel primo caso sarà necessario per essere compatibile con il protocollo NSURLConnectionDownloadDelegate mentre nel secondo caso il protocollo da rispettare sara’ il  non documentato (o: documentato solo nel file header ) NSURLConnectionDataDelegate che è una “spin-off” di il NSURLConnectionDelegate classico.
La differenza tra i due protocolli è che il primo scriverà nel file system, l’altro in memoria.
Anche in questo caso non usare il “data” approach a fini di produzione, qui si sta caricando tutto il contenuto in memoria e quindi salvando su disco quando il contenuto è stato completamente scaricato: in realtà non è l’approccio migliore se il contenuto è centinaia di megabyte, la vostra applicazione sarà certamente crash.

Have a nice Code with

Carlo Vigiani

Ecco cosa la rivista Time sta preparando per sbarcare su AppStore con una versione digitale del magazine ottimizzata per iPad.

Una grande differenza rispetto ai progetti lanciati dagli Editori italiani, che continuano a brancolare nel buio non affidandosi a professionisti smart e internazionali.

Sembra che il vero “Digital Divide” (wikipedia: http://it.wikipedia.org/wiki/Digital_divide), ovvero il divario esistente tra chi ha accesso effettivo alle tecnologie dell’informazione  e chi ne è escluso, in modo parziale o totale, sia la lingua. Sembra infatti che chi riesce a leggere l’Inglese abbia a disposizione prodotti editoriali d’avanguardia e contenuti ad altissimo valore, mentre chi conosce solamente l’italiano rimarra’ indietro e consultera’ solo il vecchiume tecnologico che i grandi giornalisti italiani (salvo eccezioni ovviamente) ci propinano.

Dal video dimostrativo si evince che con queste applicazione Time reinventa il modo di fruire dei magazine su iPad, sia dal punto di vista dell’interfaccia che per l’interattività dell’utente.

Time sarà a breve rilasciata su AppStore.

Demo di Time Magazine su Ipad

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