• English

Approccio HTML(5)
In questa 5a e ultima parte dell’articolo del CTO di i3Factory rappresenta l’ultima tecnica che vi mostreremo.
L’HTML5 è qualcosa che sta emergendo negli ultimi tempi, soprattutto grazie ai grandi miglioramenti in termini di stabilità e velocità introdotte dalla nuova versione di IOS per l’in-app viste web.
Un paio di buoni esempi di questo approccio sono l’Ars Technica app (link) e la rivista Bloomberg Businessweek + (link).

• English

Pagine pre-renderizzate da immagini
Questa tecnica è molto utilizzata all’interno delle riviste altamente interattive pubblicate utilizzando ambienti come Adobe Digital Solutions: esempi ben noti sono le riviste di Condé Nast (Wired è uno degli esempi più famosi).
Il modo in cui sono implementate queste riviste inizia con la suite dei ben noti strumenti di Adobe Digital Publishing (link), In Design in primis. Questi strumenti sono utilizzati da molti editori in tutto il mondo e le ultime versioni offrono la possibilità di esportare il progetto, oltre all’onnipresente formato Pdf, anche in un pacchetto adatto per la distribuzione attraverso iPad. Gli output di questi file possono essere testati utilizzando l’ App gratuita Viewer Adobe Content scaricabile da App Store, ma naturalmente l’applicazione finale, insieme con l’infrastruttura server necessaria per servire i contenuti, richiede una licenza di livello superiore (e costo…).

Ciò che caratterizza questo tipo di riviste è che al momento della creazione del progetto tutte le pagine vengono pre-renderizzate come jpeg o png e poi gli effetti speciali vengono sovrapposti successivamente.
Ciò significa che la sezione centrale (Core reader) del lettore rivista è essenzialmente un visualizzatore di immagini. Certo queste immagini si estenderanno per una superficie leggermente più grande dello schermo iPad, in modo che saranno inserite all’interno di una visione a scorrimento (scroll view), ma sono ancora solo immagini.
Tutto sommato la scelta tecnicamente non è male: l’iPad è molto veloce nel rendering delle immagini rispetto ai file PDF,  i calcoli necessari per trasformare i dati del  Pdf in bitmap non vengono fatti in questo caso, mentre la CPU sarà sufficiente veloce a decomprimere l’immagine e inviarla all’hardware grafico. Esattamente come abbiamo fatto nel caso PDF, possiamo applicare la tecnica di sovrapposizione e imporla su alcuni contenuti che richiedono l’interazione dell’utente sulla parte superiore dello strato di bottom-rendering.

Mentre questa tecnica è altamente efficiente dal punto di vista del tempo di rendering, ed è semplice da implementare in quanto tutte le complessità del layout di pagina sono state prese in considerazione e risolte con gli strumenti di desktop publishing, offre alcune forti limitazioni che devono essere prese in considerazione:

• ogni singola pagina richiede molto più spazio su disco e il tempo di download di questo tipo di riviste è aumentato  in confronto con una pagina pdf, lo spazio occupato è molto più grande e l’informazione di ogni pixel del testo deve essere fornita nel file e non possiamo neppure alleggerirlo forzando l’immagine con alti rapporti di compressione, se non vogliamo introdurre sfocatura nel testo. La pagina pdf, in particolare quelle pagine fatte di solo testo, è molto più leggera in quanto il testo non è pre-renderizzata e si presenta in formato vettoriale.

• lo zoom o il ridimensionamento dei font non è fattibile: invece, PDF e Core Text ridisegnano il testo utilizzando algoritmi vettoriali e rappresentano i font per dimensioni, questo ovvimente non si puà ottenere se si lavora su un’immagine jpg o png statica. Ciò significa che la rivista ha bisogno di essere disegnata con i tipi di carattere specifici e dimensioni prestabilite, i caratteri che sono adatti per la compressione jpeg (senza sfocatura) e per la risoluzione dello schermo (iPad 1 e 2 hanno 132 dpi, non è poi così alto; le cose andranno meglio con il prossimo iPad schermo retina !)

• Ricerca testo, con la rivista fatta d’ immagini non abbiamo la possbilità evidenziare il testo , e quindi la selezione del testo è impossibile, a meno che gli strumenti di pubblicazione digitale per fare le esportazioni  . insieme all’immagine forniscano anche uno schema  della pagina pre-renderizzata con una mappa completa delle coordinate del testo, qualcosa che non francamente non abbiamo ancora visto ma che noi stessi abbiamo implementato , su richiesta, per alcuni clenti del nostro sistema editoriale i3F Editorial.

Adobe non è il solo sistema con cui è possibile a pubblicare questo tipo di riviste con immagini statiche: ci sono diverse applicazioni personalizzate sul mercato che seguono esattamente lo stesso approccio.
Non è male, ma non sfruttano i grandi framework editoriali che Apple sta offrendo ai propri sviluppatori. Inoltre l’approccio basato sull’immagine ha anche molti altri limiti se confrontato con altre tecniche. Di sicuro un editore che è ha la padronanza degli strumenti dell’editoria digitale può trarre vantaggio da questo approccio, la qualità finale è indubbia e il time to market è il più breve, e al tempo stesso permette di fornire un contenuto adatto per l’iPad , e non solo un pdf adattato sullo schermo.

Ma vorremo raccomandare a tutti gli sviluppatori, che stanno facendo prodotti personalizzati e non stanno utilizzando speciali strumenti di composizione pagina (composition tools) di stare lontano da tale metodologia.

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

• English

Core Text  (in breve: CT) è un’altra di quelle tecnologie sviluppate per Mac e in seguito convertita per iOS.
Il framework Core Text è dedicato alla disposizione del testo e alla gestione dei font. Giusto per riassumere le capacità di questo framework, si consideri che è alla base della rivoluzione del desktop publishing che ha reso celebre il Mac in questo settore professionale.
Come Quartz Core Graphic (CG), anche CT (Core Text) ha un API basata su C, esistono comunque diversi wrapper open source di terze parti  che contengono le funzionalità più comuni con un alto livello d’interfaccia Objective-C.
Core Text (CT) non deve essere utilizzato per sostituire il rendering basato sul web a base di Html e Css, questo è un campo troppo complesso
che è meglio lasciare ai componenti di sistema dedicati, come la UIWebView che può essere utilizzata per rendere efficiente un rich text.
CT “comunica” con CG , infatti il rendering del testo è dato contemporanemente al rendering di una view basata su Quartz.
Le due API hanno convenzioni  e regole di gestione della memoria molto simili, per cui lo sviluppatore già abituato con un modello di programmazione “Core Foundation”  non trovera ostacoli nella comprensione della API Core Text.
Questo dà la possibilità allo sviluppatore di mescolare il rendering del testo e le immagini nella fase di rendering stesso (CT è limitata al solo testo, non ha capacità di disegnare l’immagine).

Il motivo principale per usare Core Text è perché questo esegue il rendering del testo direttamente sulla pagina, senza intermediari.
Si differenzia dai formati PDF che considerano ogni pagina come un’intero, si differenzia anche dalle tecniche web di base in quanto non possiede un linguaggio intermedio (come ad es. html) e nemmeno l’interpretazione del layout (css). Con CT si può scrivere direttamente nella pagina.

I componenti di base dietro CT sono oggetti del layout, che sono la traduzione diretta di caratteri in glifi (glyphs), “linee” di caratteri e di “frames”, che corrispondono ai paragrafi. La traduzione dei caratteri in glifi è fatto da “typesetters” e il testo da plottare viene dato attraverso l’utilizzo di stringhe di attributi, che sono stringhe comuni arricchite con informazioni attributo (dimensione del font, colore, ornaments).

Si decide di utilizzare Core Text per una rivista il cui schema sarà principalmente basato su un Testo con layout standard, in modo che si adatterà bene anche per i giornali. Probabilmente non è la scelta migliore per le riviste glamour, dove layout grafico cambia in ogni pagina e potrebbe essere piuttosto complesso.
Un chiaro vantaggio della soluzione basata su Core Text è che, con questo framework, non c’è bisogno di applicare la tecnica di sovrapposizione di cui abbiamo parlato nel paragrafo dedicato al Pdf. Con CT si divide direttamente la pagina in cornici (frames) e ciascuno di questi frames conterrà testo (reso da CT) o elementi multimediali.
Essenzialmente è possibile definire il layout della pagina, definendone la dimensione (che può andare bene per lo schermo iPad oppure può essere con scorrimento pagina verticale o orizzontale), poi si deciderà la dimensione e la posizione dei contenuti multimediali di questa stessa pagina e, infine, si definiranno i frames (diverse cornici rettangolari) che conterranno il testo.
L’organizzazione delle cornici di testo può essere di qualsiasi genere, una compatta struttura a singola colonna, due layout multicolonna o cornici di varie dimensioni. All’interno dei frames dovremo renderizzare il testo e Core Text vi aiuterà a gestire interruzioni di riga per questi paragrafi.
A questo punto si può facilmente fornire all’utente la possibilità di modificare il tipo e la dimensione di font  e lo stesso codice di rendering  può essere riutilizzato per riorganizzare rapidamente il testo all’interno dei frames (cornici).

La rappresentazione del layout di pagina può essere fornita in qualsiasi forma preventivamente decisa dallo sviluppatore assieme all’editore; la scelta migliore sarà il formato XML (tutto sommato è la base di qualsiasi formato di markup!) e che sarà inviato all’applicazione assieme con i testi (ancora in XML) e gli asset in un pacchetto zip file.

Una limitazione del Core Text è che si tratta di una tecnologia per il disegno di testo e non è ottimizzata per la modifica e l’interazione con l’utente, anche se non ne abbiamo bisogno in questa fase. Questo significa che se vogliamo , ad esempio, evidenziare il testo o selezionare e copiare le caratteristiche del testo stesso avremo bisogno di implementarle scrivendo codice.
Il framework ci fornisce alcune API per facilitare questo compito, ma in ogni caso il codice per implementare queste funzionalità deve essere scritto da uno sviluppatore in grado di gestire ogni singolo dettaglio. In ogni caso tutti questi compiti saranno notevolmente semplificati rispetto al PDF: qui, con CT,  si ha il controllo pieno del testo e la sua posizione di schermo, mentre fare quueste operazioni con il Pdf è ancora  piuttosto opaco poichè  il tutto è nascosto dietro una complessa struttura di dati che non si può controllare nella sua interezza.

Concludendo questa terza parte, la nostra raccomandazione è che se si deve implementare una rivista digitale, senza requisiti di layout estremo, con alcuni contenuti multimediali e un controllo veloce e potente di testo,  Core Text è la prima tecnologia da considerare.

Un ottimo tutorial su questo argomento è disponibile a questo link su Ray Wenderlich blog:
http://www.raywenderlich.com/4147/how-to-create-a-simple-magazine-app-with-core-text

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

NDR.
Per approfondimenti sul wrapper di Core Text segnaliamo un articolo: http://akosma.com/2010/07/08/core-text-objective-c-wrapper/

• English

La Rivista / Magazine è un file PDF

Qualora vogliate  impegnarvi a sviluppare una magazine app per iPad, che vi piaccia o meno,  la rivista che avrete a disposizione dall’editore vi sarà consegnata – con molta probabilità -  un file PDF.
Poiché non c’è modo di “sfuggire” da esso, alla fine sarà necessario sviluppare il vostro proprio lettore pdf o integrare qualche libreria gratuita o commerciale esterno. i3Factory ha a questo proposito sviluppato un reader propietario che possiede tutte le caratteristiche necessarie per pubblicare una magazine app alquanto performante.

Il motivo per cui pdf è ancora il formato dominante nel mondo dell’editoria e quindi e-publishing  ci appare chiaro:
la maggior parte degli editori fanno semplicemente il porting delle loro pubblicazioni esistenti e stampate su carta per iPad e iPhone. Questo per sia per ragioni di bilancio, dato che è ovvio che desidera riutilizzare l’investimento fatto nella creazione delle proprie testate e sia perchè gli editori – tranne rare eccezioni -  non possiedono ancora un modello di produzione volto alla piena fruizione multimediale dei propri contenuti.

Pertanto, come sviluppatori, non sarete ancora in grado di sfuggire al formato Pdf con l’eccezione di due casi:
1) la pubblicazione è nuovo di zecca e solo digitale, quindi non ci sono precedenti inparamenti per guidare la scelta finale

2) L‘editore ha grandi budget e / o è una forte esperienza utente (UX), è quindi un reale possessore di capacità di vision futura e crede nella nostra visione  e accetta di allocare il budget extra per ricreare un formato diverso per le proprie pubblicazioni.

In entrambi i casi non sono così rari incontri con quegli editori che hanno già  fatto lo sforzo di portare i propri prodotti sul web (con la notevole eccezione di quelli che ha fatto in Flash!), ma la gran parte delle case editrici piccole e medie imprese sarà ancora bloccata con in formato Pdf.

Purtroppo il Pdf non è il modo migliore per portare un magazine su iPad o altri tablet. E questo per diverse ragioni:

• La pagina di una rivista stampata ha dimensioni solitamente più grande dello schermo iPad o di un Tablet tradizionale: questo significa che quando la pagina si adatta allo schermo, tutti i caratteri appaiono più piccoli e quindi qualcosa di leggibile nella carta stampata potrebbe diventare illeggibile senza zoom, ma lo zoom non è sempre efficiente ed in particolare non è amato da tutti i lettori che possono perdere il loro “orientamento” all’interno la pagina.

• Le pagine di riviste stampate  non hanno le stesse proporzioni dello schermo iPad: questo significa che una pagina che si adatta allo schermo sarà delimitata da righe vuote in alto / basso o destra / sinistra.

• I layout di una pagina stampata spesso sono ottimizzati per lunghezza, per esempio un immagine panorama che si sviluppa
tra due pagine, quando il dispositivo viene tenuto in orientamento verticale, i dettagli grafici andranno persi, invece se il dispositivo è tenuto in orizzontale si sarà in grado di apprezzare le due pagine di layout, ma i caratteri saranno troppo piccolo per essere letti comodamente.

• I file forniti dall’editore non sono ottimizzati per il digitale, normalmente i contorni (tabella dei contenuti) e le annotazioni (Collegamenti a pagine o risorse esterne) non vengono esportati; questo significa che anche se il vostro lettore Pdf è consapevole di queste informazioni, nella maggior parte dei casi non è disponibile e quindi è necessario definire un divero modo di fornirle.

• Il formato ufficiale PDF supporta contenuti multimediali; purtroppo l’IOS non è in grado di gestirlo, per cui  tutti i contenuti interattivi devono essere fornite al di fuori del file pdf e associati ad esso.

Il rendering delle pagine è realizzato in iOS (e anche in OSX) attraverso il Quartz 2D API, cono Core
Graphics framework (CG). Quartz 2D è il motore grafico bidimensionale su cui si basano molte (ma non tutte)  funzionalità di disegno di IOS. Il
PDF API è un sottoinsieme del grande CG API. Questa API è “vecchio stile “e non si basa su Objective-C, ma è in puro vecchio C; oltre a tutte le regole di gestione della memoria che seguirà il Core Foundation (CF) con regole che sono diverse da Obj-C:
questo significa che particolare attenzione deve essere fornita al fine di evitare perdite di memoria, come ad ogni manipolazione la pagina PDF può pesare diversi megabyte e può facilmente innescare il memory watchdog, in tal modo la vostra applicazione potrà crashare.

In ogni caso se si è abituati con i concetti Quartz 2D sarà semplice renderizzare una pagina PDF seguendo questi passaggi fondamentali:

1. Ottenere il riferimento CG alla pagina pdf da trarre;
2. Ottenere il contesto grafico corrente per la vista che contiene la pagina;
3. Istruire Quartz a disegnare la pagina Pdf per il contesto.

Come potete vedere, a parte le fasi necessarie per il disegno del modello Quartz, il rendering completo è compiuto dal sistema e non c’è bisogno di avere alcuna conoscenza del formato dei dati di un file pdf. Quindi per voi il processo di rendering Pdf  è solo una scatola nera, e questo è chiaro quando si nota che tutte le strutture dati CG sono infatti opache e il loro contenuto interno si può accedere solo tramite API.
Ma un reader valido per una rivista in Pdf non può limitarsi al rendering, per cui vi sarà richiesto di supportare ad esempio lo zoom;
ora, il livello massimo di zoom può essere teoricamente molto elevato (non dimenticate che i caratteri nel file Pdf sono come i font
nel computer, non potranno mai perdere in precisione, anche per estremi zoom-in), è impossibile rendere l’intera pagina ingrandita in un canvas molto più alto dello schermo del dispositivo:
Qui abbiamo pixel ,non  vettori, e sarebbe immediato il crash dell’applicazione, perché la memoria è esaurita per una sola pagina. Quindi saremo costretti a introdurre tecniche per limitare il rendering e renderlo efficace per la solo parte visibile della pagina, questo nonè  sempre un compito facile.

Più complessa è l’analisi del documento: questo è necessario se si desidera estrarre contorni,  annotazioni, fare qualche ricerca di testo
ed evidenziare. In tal caso a parte un paio funzioni per estrazione di meta-dati, quello che ti fornisce l’API è un insieme di funzioni che vi permetterà di esplorare le strutture dati all’interno del documento. Non saremo in grado di ottenere qualsiasi informazione dal file se non si esplora l’albero dati (data tree) correttamente e se non si seguono le specifiche del documento PDF.
Ciò è aggravato dalla molte versioni che le specifiche PDF hanno ottenuto negli anni e dal fatto che molti editori usano ancora del vecchio software che esporta il contenuto in vecchi formati.

Carlo ha sviluppato un generico PDF Explorer, questo è stato parte di un impegno per un cliente che ha chiesto di sviluppare un generale lettore PDF. E’ risulato davvero difficile applicare tutte le specifiche di riferimento ufficiale del formato PDF, il mio suggerimeto è di concentrarsi sulle funzionalità più utilizzate e test con molti documenti. Come ho detto prima, CG naviga l’albero dei dati (data tree), ma non la interpreta per noi!

L’ultima sezione di questa parte, la spiegazione lunga ma necessaria, data l’importanza del tema, è come fornire contenuti multimediali sulla cima di un file PDF: tutti in tutti i
iPad è un dispositivo così versatile che noi non possiamo limitarci al semplice rendering delle pagine. Con l’aggiunta di contenuti extra per la pagina stampata è possibile sfruttare le caratteristiche del dispositivo
e ancora in vantaggio per l’investimento fatto nella creazione rivista.

Ci sono molte ragioni per giustificare questa scelta: ad esempio un messaggio pubblicitario stampato in grado di offrire un video al posto di un’immagine statica, o un link stampato su una pagina web può essere sostituito da un collegamento attivo ad una vista web, o infine possiamo mostrare il tempo corrente utilizzando un widget HTML5. Come ho già detto non è consigliabile introdurre tutti questi contenuti all’interno del file pdf: non sarà reso da quarzo e sarà comunque
costretti ad attraversare la struttura dei dati per estrarre il riferimento all’oggetto CG per ulteriori manipolazioni. Infine, non tutti gli editori sono a conoscenza di queste funzionalità o dei loro software di pubblicazione digitale è troppo vecchio per loro pieno sostegno.

Quindi la soluzione migliore è basata sulla “tecnica di sovrapposizione”.
Questa metodologia consiste nel rappresentare le pagine in due strati:

• il livello inferiore (“layer rendering”) conterrà il rendering PDF, in modo che conterrà l’immagine bitmap della pagina;
• lo strato superiore (“layer overlay”) attirerò tutti sovrapposizioni ed è sensato touches.More utente difficile è l’analisi del documento: questo è necessario se si desidera estrarre contorni, le annotazioni, fare qualche ricerca di testo ed evidenziare. In tal caso a parte un paio di meta-funzioni di estrazione dei dati, che cosa ti dà l’API è un insieme di funzioni
che vi permetterà di esplorare le strutture dati all’interno
il documento. Non sarà in grado di ottenere qualsiasi informazione
dal file se non si esplora l’albero dati in modo corretto
e se non si seguono le specifiche del documento PDF.
Ciò è aggravato dalla molte versioni le specifiche PDF ottenuto
negli anni e dal fatto che molti editori usano ancora
vecchio software che esporta il contenuto in vecchi formati.
Ho sviluppato un generico PDF Explorer, questo è stato
parte di un impegno di un cliente che mi ha chiesto di sviluppare
un generale lettore PDF scopo, ma in quanto è davvero difficile
applicare tutte le specifiche di riferimento ufficiale in formato PDF, il mio suggerimento è di concentrarsi sulle funzionalità più utilizzate e test
con molti documenti. Come ho detto prima, CG naviga
l’albero dei dati, ma non la interpreta per noi!

L’ultima sezione di questa parte – la spiegazione lunga ma necessaria data l’importanza del tema – è come procurare i contenuti multimediali di un file PDF:
l’iPad è un dispositivo così versatile che noi non possiamo limitarci al semplice rendering delle pagine. Con l’aggiunta di contenuti extra alla pagina stampata è possibile sfruttare le caratteristiche del dispositivo.

Ci sono molte ragioni per giustificare questa scelta: ad esempio un pubblicità in grado di offrire un video al posto di un’immagine statica, o un link su una pagina web può essere sostituito da un collegamento attivo ad una vista web, o, infine, possiamo mostrare le previsioni meteo utilizzando un widget in formato HTML5.
Come abbiamo già detto ,  non è raccomandato introdurre tutti questi contenuti all’interno del file pdf:
non sarà reso da quartz e saremo comunque costretti ad attraversare la struttura dei dati per estrarre l’oggetto CG di riferimento per ulteriori manipolazioni. Infine, non tutti gli editori sono a conoscenza di queste funzionalità o quelle loro software di pubblicazione digitale è spesso troppo vecchio per loro pieno sostegno.

Quindi la soluzione migliore è basata sulla “tecnica di sovrapposizione” (overlay technique).
Questa metodologia consiste nel rappresentare le pagine in due strati:

• il livello inferiore (“layer rendering”) conterrà il Rendering PDF, in modo che conterrà l’immagine bitmap della pagina;
• lo strato superiore (“layer overlay”) disegnerà le sovrapposizioni e sarà sensibile al tocco dell’utente.

Lo strato superiore di overlay è tipicamente costituito da componenti UIKit, quindi dovremo aggiungere un UIWebView html per i widget, si introducono una UIScrollView per visualizzare una galleria di immagini scorrevoli, o faremo aggiungere una vista Media Player per l’esecuzione video.
Di solito le descrizioni in sovrapposizione sono forniti da un file separato, ad esempio, uno di formato XML, JSON o plist, e sara inserito iinsieme  con il file pdf e tutte gli altri (filmati, immagini, file html, file musicali) in un unico file zip.
L’applicazione quindi scaricherà il file zip, lo scompattarà e  utilizzerà la pagina Pdf per riempire il rendering layer, aggungendo le informazioni associate in sovrapposizione a quella pagina per costruire un “overlay layer“.
Si noti che questa tecnica può essere applicata anche nelle altre tecniche di rendering  di cui parleremo nei prossimi articoli, in tal caso ciò permette di superare molti limitazioni del formato pdf.
Il requisito principale per lo sviluppatore è quello di definire un formato adatto, controllare tutte le pagine soggette a zoom e rotazioni con una trasformazione e corrispondente sovrapposizione e, infine, fornire alla casa editrice  gli strumenti e le linee guida necessarie per creare facilmente sovrapposizioni del genere.

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

• English

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

Uno dei grandi miglioramenti per tutti i proprietari di iPad è la possibilità di portare ovunque le propie rivista preferite o libri, grazie alle dimensioni dello schermo e il peso leggero dispositivo, che permette una  facile lettura. In particolare le relazioni sulle vendite  hanno dimostrato che in un momento di diminuzione mercato della stampa delle pubblicazioni vi è un enorme aumento del numero di abbonamenti alle versioni digitali degli stessi prodotti (il lettore interessato può leggere questo rapporto da MPA: http://www.magazine.org/association/press/mpa_press_releases/mag-mobile-reader-study.aspx)

Apple sta seguendo questa tendenza con grande interesse, e ciò è abbastanza chiaro se diamo uno sguardo alla evoluzione della
le caratteristiche di iOS che sono state introdotte dopo il rilascio della versione dedicata a iPad, che è di 3,2.
In particolare le tappe che sono state raggiunti sono tre, in comune tra i tre principali releases del sistema operativo:

• iOS 3.2 è stata arricchita dal framework CoreText, una tecnologia dedicata al rendering del testo sul display disponibile da tempo su Mac OSX e mai portati nelle versioni precedenti di iPhone OS.

• iOS 4.x ha introdotto il concetto di abbonamento auto-rinnovabile, in aggiunta allo standard di  Acquisti In App, questa funzione è stata
introdotto dopo lunghe discussioni tra Apple, che applica la commissione del 30% su ogni In App venduta e vieta a qualsiasi altro store esterno più economico l’accesso all’interno dei suoi dispositivi, e gli editori in cerca per le tecniche di fedeltà dei clienti.

• infine iOS 5.0 ha aggiunto la funzione di Edicola (Newsstand), che fornisce un luogo centrale, una vera e propria app App,  per raccogliere tutte le pubblicazioni e le  magazine  app compatibili e allo stesso tempo fornire una push notification per i nuovi contenuti e automaticamnte fornire a tutti gli abbonati la possibiltà di scaricare automaticamente i nuovi numeri, permettendo di leggere immediatamente le novità e  far risparmiare i tempi (A volte lunghi) necessari per il download.

Quello che Apple non ha fornito invece è un unica piattaforma di sviluppo per la creazione di applicazioni dedicate ai consumi di riviste. Questo ha portato a numerose iniziative dedicate per aiutare gli editori ad entrare nel mercato iPad con le proprie riviste . Queste iniziative, come ad esempio il nostro sistema editoriale i3F Editorial,  sono state preso da società importanti e ben noti, come ad esempio Adobe con i suoi affari Digital Publishing, e un sacco di molte start-
up, ognuno con una propria soluzione.

Come già detto, Apple non fornisce una soluzione unica, ma i developers hanno la disponibilità di una serie di frameworks e tecniche, con diversi livelli di complessità, che prevedono diversi modi di rappresentare la pagina sullo schermo.

Non c’è una scelta ottimale, poiché la decisione finale deve considerare aspetti che vanno oltre la pura tecnica.

In questo articolo cercheremo di descrivere queste soluzioni principalmente dal punto di vista dello sviluppatore di applicazioni, ma non dimentichiamo di enumerare i pro e i contro che possono influenzare la decisione dell’editore , come l’agency,  su quale tecnologia adottare.

Panoramica sul page rendering

Diamo per scontato che voi, lo sviluppatore, siate ad una certo dello  sviluppo di un  applicazione in cui la rivista è stato acquistato, scaricato ed è pronto per essere letta.
I dati del vostro documento, a questo punto vengono conservati nel file system del dispositivo e possono essere rappresentati da un unico file pdf, o da un insieme di file html e css o una directory contenente files di diversi formati, quali immagini, video, widget HTML5, file di testo.
Stai quindi per affrontare il problema di prendere una pagina (che nosrmalmente si estende oltre i limiti dello schermo) e la presentazione nello spazio vuoto del vostro UIView dedicato al rendering della pagina.

Nei prossimi paragrafi il nostro Carlo (CTO di i3factory)  presentera le seguenti metodologie per ottenere questo risultato:

• il rendering documento pdf
• pre-rendered visualizzazione delle immagini
• libero formato di rendering CoreText
• approccio basato sul web

Continua a leggere il prossimo articolo su Parte 2: Tecniche di Page Rendering #parte 2 : Riviste e Magazine in PDF

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

Come abbiamo segnalato nel precedente articolo  di seguito trovate le principali caratteristiche di “Ice Cream Sandwich“ , dal punto di vista dello sviluppatore. Abbiamo tradotto alcuni importanti passi dal portale Android developer sul nuovo Os mobile Android 4.0,  che presenta importanti novità per il developer.

Unified UI framework per i telefoni, tablet e altro

Android 4.0 possiede una struttura unificata per l’interfaccia utente. L’Unified UI  framework include tutti gli elementi dell’interfaccia gia presenti in Android 3.x e API , così come nuovi elementi e le API.

Per gli sviluppatori, il framework di interfaccia utente unificata (Unified UI  framework) in Android 4,0 significa lavorare su nuovi strumenti di interfaccia utente con un metodo di progettazione coerente, codice e risorse semplificate e lo sviluppo diretto su tutta la gamma di dispositivi Android che istallano Android.

Comunicazione e condivisione

Android 4.0 estende le caratteristiche sociali e la condivisione di tutte le applicazioni presenti sul dispositivo. Le applicazioni possono integrare con i contatti, i dati dei profili e gli eventi nel calendario da qualsiasi attività dell’utente o social network.

Le principali API sono:

• Social API
• Calendar API
• Visual voicemail API
• Android Beam
• Modular sharing widget

New media capabilities

Low-level streaming multimedia
Android 4.0 possiede un diretto ed efficente percorso per il low-level streaming multimedia. Questo risulta ideale per applicazioni che necessitano un completo controllo sui media data prima di passarli alla piattaforma per la  presentation. A esempio, mediae  applicazioni possono ora ricevere dati da qualsiasi fonte, applicare  encryption/decryption proprietarie, e quindi inviare i dati al sistema per mostrarli.

Supporta il format multiplexed stream per audio/video in MPEG-2.

Per ll supporto a questo low-level streaming, viene introdotta  una nuova API nativa basasta su Khronos OpenMAX AL 1.0.1.
Questa API è implementata su gli stessi servizi di base della piattaforma esistente OpenSL ES API, così gli sviluppatori possono usufruire di entrambe le API insieme, se necessario. Strumenti di supporto per lo streaming multimediale di basso livello saranno disponibili in una prossima release del NDK Android.

Nuova caratteristica della telecamera

Gli sviluppatori possono usufruire di una serie di nuove funzioni della fotocamera in Android 4.0. ZSL esposizione, messa a fuoco continua, e lo zoom dell’immagine permettono alle vostre apps di cogliereal meglio le immagini statiche e video, anche durante la cattura video.

Media effects per trasformare le immagini e video

Un insieme di filtri di trasformazione ad alte prestazioni  consentono agli sviluppatori di applicare effetti  a qualsiasi immagine che viene  passata come una texture OpenGL ES 2.0. Gli sviluppatori possono regolare i livelli di colore e luminosità, cambiare sfondi, affilare, ritagliare, ruotare, aggiungere la distorsione della lente, e applicare altri effetti. Le trasformazioni vengono elaborate dalla GPU, quindi sono abbastanza veloci per l’elaborazione dei frame immagine caricate dal flusso di disco, una fotocamera o video.

Audio remote controls

New media codecs and containers

Android 4.0 aggiunge il supporto per ulteriori tipi di codecs e containers per permettere agli sviluppatori di accedere ai formati di cui hanno bisogno. Per le immagini di alta qualità compresse, il media framework aggiunge il supporto per i contenuti WebP. Per il video, il framework ora supporta lo streaming di contenuti VP8. Per il multimedia streaming, il framework supporta i protocolli HTTP Live streaming versione del protocollo 3 e la codifica di ADTS-contained contenuto AAC. Inoltre, gli sviluppatori possono ora utilizzare Matroska container per Vorbis e contenuto VP8 .

Nuovi tipi di connettività

• Wi-Fi Direct
• Bluetooth Health Device Profile (HDP)

Nuove UI components

• Layout enhancementse
• OpenGL ES texture views
• Hardware-accelerated 2D drawing

Tutti i dispositivi  con sistema operativo Android 4.0 devon osupportare un’accelerazione hardware per il disegno 2D. Gli sviluppatori possono trarre vantaggio da questo per aggiungere effetti all’ interfaccia utente, pur mantenendo prestazioni ottimali su schermi ad alta risoluzione, anche su cellulari. Per esempio, gli sviluppatori possono contare su scaling accelerato, la rotazione e altre operazioni 2D, così come i componenti dell’interfaccia utente accelerati come TextureView e le modalità di composizione come il filtering, blending, and opacity.

New input types and text services

• Stylus input, button support, hover events
• Text services API for integrating spelling checkers

Android 4.0 consente alle applicazioni di interrogare i servizi di testo disponibili, come dizionari, spell checker,  suggerimenti per le parole, correzioni, e dati simili. I servizi di testo sono esterni al IME attivo, per cui gli sviluppatori possono creare e distribuire dizionari e motori di suggerimento che si inseriscono nella piattaforma. Quando un’applicazione riceve i risultati di un servizio di testo – per esempio, suggerimenti per le parole – che possono essere visualizzati in una finestra popup dedicata al suggerimento direttamente all’interno della vista del testo, piuttosto che basarsi su l’IME per visualizzarli.

Enhanced accessibility APIs

Android 4.0 aggiunge nuove caratteristiche di accessibilità e  una enhanced API  per consentire agli sviluppatori di migliorare l’esperienza utente nella proprie applicazioni, in particolare su dispositivi che non dispongono di pulsanti hardware. Per i servizi di accessibilità come gli screen reader, in particolare, la piattaforma offre nuove API per fare query al contenuto nella finestra , per facilitare la navigazione, migliorare il feedback, e interfacce utente più ricche.

• Accessibility API
• Text-to-speech API

Uso Efficente della rete -  network usage

In Android 4.0, gli utenti possono visualizzare la quantità di dati in rete delle loro applicazioni in esecuzione. Essi possono anche impostare i limiti per l’utilizzo dei dati per tipo di rete e disabilitare l’utilizzo dei dati per applicazioni specifiche. In questo contesto, gli sviluppatori devono progettare le loro applicazioni per funzionare in modo efficiente e seguire buone pratiche per la verifica della connessione di rete. Android 4.0 fornisce network API per consentire alle applicazioni raggiungere questi obiettivi.

Come gli utenti passano da reti o limiti stabiliti su dati di rete, la piattaforma permette di interrogare le richieste di tipo di connessione e la disponibilità. Gli sviluppatori possono utilizzare queste informazioni per gestire in modo dinamico le richieste di rete per garantire la migliore esperienza per gli utenti. Gli sviluppatori possono anche costruire una rete su misura e dati di utilizzo delle opzioni nelle loro applicazioni, poi esporle agli utenti direttamente da Impostazioni per mezzo di un nuovo system Intent.

Sicurezza per apps e contenuto

Management delle credenziali

Android 4.0 rende più facile, per le applicazioni, gestire l’autenticazione e le sessioni protette. Un nuovo keychain API e lo storage criptato permette alle applicazioni di memorizzare e recuperare le chiavi private e le loro catene di certificati corrispondenti. Qualsiasi applicazione può utilizzare l’API portachiavi per installare e memorizzare i certificati utente e CA in modo sicuro.

Address Space Layout Randomization

Android 4.0 fornisce ora Address Space Layout Randomization (ASLR) per proteggere applicazioni di sistema e la terza dallo sfruttamento a causa della gestione della memoria.

Miglioramenti per l’Impresa

VPN client API

Gli sviluppatori possono ora creare o estendere le proprie soluzioni sulla piattaforma VPN utilizzando un nuovo VPN API e alla base di memorizzazione sicura delle credenziali. Con il permesso dell’utente, le applicazioni possono configurare gli indirizzi e le regole di routing, il processo di pacchetti in uscita e in entrata, e stabilire tunnel sicuri su un server remoto. Le imprese possono inoltre usufruire di un client VPN standard integrato nella piattaforma che fornisce l’accesso ai protocolli L2TP e IPSec.

Device policy management for camera

La piattaforma aggiunge un nuovo controllo della politica per gli amministratori che gestiscono i dispositivi con un installato Device Policy Manager. Gli amministratori possono ora disabilitare da remoto la fotocamera su un dispositivo gestito per gli utenti che lavorano in ambienti sensibili.

Questo articolo è basato da una libera traduzione dal’Andorid developer Portal (android-4.0-highlights)

Il linguaggio HTML5 avrà un profondo impatto sulla Internet.

Per citare la definizione di Wikipedia, l’HTML5 è un linguaggio di markup per la progettazione delle pagine web attualmente in fase di definizione presso il World Wide Web Consortium.

iOS 5 introduce 1.500 nuove API per gli sviluppatori, compreso l’accesso icloud, Storage, Newstand e Twitter.
Apple ha apportato alcune migliorie sul supporto per html, come Safari Mobile che permette di attingere a maggiori porzioni di memoria locale del dispositivo e ai servizi di geolocalizzazione.

Abbiamo pensato quindi di integrare il supporto all’html5 all’interno del nostro sistema editoriale i3F Editorial.

Vi segnalamiamo a questo proposito un interessante articolo di Bart Termorshuizen autore del Bolg Siteless.Org:
Bart sta lavorando su un piccolo progetto per la creazione di un generico codice basato su HTML5 per la lettura di riviste come soluzione per l’iPad.

L’idea di base è che le soluzioni editoriali adottate dalle corporate sono troppo costose per una vasta gamma di editori. Inoltre, queste soluzioni editoriali non sembrano essere di semplice utilizzo e integrazione e molti non sfruttano la tecnologia HTML5, ma sono derivanti da logiche d’informatizzazione ad alto impatto architetturale.

Crediamo che la semplicità sia la chiave del successo per il mercato delle App online e per questo , come Bart, siamo certi che l’iPad sia un dispositivo meraviglioso per leggere riviste – soprattutto se queste riviste sono ricche di contenuti interattivi.

Creare un app che ti permette di gestire pubblicazioni multiple, con la possibilità di lettura off-line con performance scattanti non è facile.

Se qualcuno volesse cimentarsi con un progetto Xcode puo’ trovare il sources code sul blog http://www.siteless.org/books/SitelessMagazine.zip.

Per una soluzione didattica possiamo provare a dare un’occhiata al framework Baker, Baker framework, Laker compendium and pugpig. Tutto il codice è open source-

Innanzi tutto il codice è:
- siteless magazine è il nome del progetto e prende la grafica e altra roba dal sito Siteless.org a scopo di test
- Minizip per decomprimere
- Json per il parsing json
- pugpig reader (ha delle belle pre-rendering snapshot)

Viewcontrollers:
- LibraryViewController – qui è dove accadono le cose principali. Nota che le copertine fanno riferimento ad una url nella stringa JSON. Oltre alle funzionalità di sincronizzazione (il pulsante in basso a sinistra ), che cura anche la creazione di istanze di oggetti issueviewcontroller e la gestione del layout
- IssueViewController – questo è il viewcontroller di una singola pubblicazione. Il Design (xib) è in bozza. Si occupa anche di scaricare / decomprimere una singola pubblicazione e l’archiviazione (che elimina la pubblicazione dal filesystem)
- ReaderViewController – si prende cura del lettore reale – utilizza il framework pigpug in questa versione open.

il suo modello misto di storage :
- Le pubblicazioni sono memorizzate utilizzando core data (database SQLite). È possibile esaminare il database utilizzando il browser dei database SQLite. Come potete vedere, il database non è incluso – viene creato automaticamente se non esiste.

- Le copertine grafice sono memorizzate sul filesystem – la posizione delle cover sul filesystem viene mantenuta nel database. E’ un path completo – Bart sostiene di un essere incorso in problemi con esso.
- Le Pubblicazioni (dossier) vengono memorizzate sul filesystem. L’operazione ‘archive’ rimuove la pubblicazione mentre ‘download’ la scarica , poi unzippa e inserisce il riferimento ad esso nel database.
Il DataModel è nel file xcdatamodel. La classe Issue, copertina e contenuti sono generati da quel DataModel.

Per verificare che cosa sta succedendo, è facile monitorare la cartella e il database. Ricominciare è anche facile: rimuovere tutto cio’ che si trova in quella cartella (/’user’/Application Support/iPhone Simulator/4.3.2/Applications/’applicationid’/Documents/)

Il formato JSON è facile da capire, assicurarsi che i numeri di serie delle pubblicazioni siano unici. Sul sito di siteless sono incluse due testissue – (pubblicazione numero 1 e 2, da Laker e Pigpug), mentre le altre non esistono.

Qualche necessità per rendere questo codice meno didattico:
- Integrazione del reader. Il reader in questo codice non consente ancora lo scorrimento verticale. Il doppio tap non mostra l’indice. Il pulsante library ha bisogno di essere implemntato. Non aggiornare se si vuole aprire un altra pubblicazione
- Refactoring di alcuni metodi (alcuni sono troppo lunghi e verbosi)
- Generalizzare il codice e includerlo nel github (dopo il test)

L’icona di avvio (launcher icon) è un elemento grafico che rappresenta la nostra applicazione. Le icone di avvio vengono utilizzate per avviare le applicazioni e appaiono sulla schermata iniziale del dispositivo utente.
Le icone di avvio possono essere utilizzate anche per rappresentare i collegamenti (shortcuts) nella vostra applicazione (ad esempio, un’icona di collegamento contatto permette di aprire le informazioni di dettaglio per un contatto).

Quando si disegna per Android è necessario creare le icone separate per tutti i diversi display presenti sul mercato dei device che montano android gli , schermi che hanno diverse densita di pixel potranno essere a bassa, media, alta e altissima densità. Questa differenziazione assicura che le icone verranno visualizzate correttamente in tutta la gamma di dispositivi su cui l’applicazione può essere installata. Vedere Tips for Designers (Suggerimenti per i progettisti) su come lavorare con più set di icone.

Obiettivi del icona di avvio
Esempio di launcher icons per sistemi e applicazioni di terze parti

Esempi di Icone di avvio (laucers icons) per OS Android

Figura 1. Esempi di launcher icons per system applications (sinistra) e applications di terze parti (destra).

Le icone di avvio dell’applicazione hanno tre obiettivi primari:
a. Promuovere il marchio e raccontare la storia delle app.
b. Aiutare gli utenti a scoprire l’applicazione in Android Market.
c. Permettere l’avvio dell’App.

a) Promuovere la storia del marchio
Le icone di avvio applicazione sono l’occasione per presentare il marchio e la storia della vostra applicazione .
Pertanto, si dovrebbe:

• Creare un’icona con uno stile unico e memorabile.
• Utilizzare una combinazione di colori che si adatta il vostro marchio.
• Non cercate di comunicare troppo con l’icona. Una semplice icona avrà più impatto e più memorabile.
• Evitare di includere il nome dell’applicazione nell’icona. Il nome della applicazione sarà sempre visualizzato accanto all’icona.

b) Aiutare gli utenti a scoprire l’applicazione in Android Market
Le icone di avvio fornicono una prima impressione agli utenti potenziali in Android Market. Un icona di alta qualità può influenzare gli utenti che scorrono gli elenchi di applicazioni.

Un icona ben progettata può essere un segnale forte che la vostra applicazione sarà di qualità altrettanto elevata. Consideriamo quindi di lavorare con un designer professionista per sviluppare un’icona di avvio per la nostra applicazione.

c) Funzionare e pemettere l’avvio
Un’icona di successo dovra’ essere ben definita in tutte le situazioni: su qualsiasi sfondo e accanto ad altre icone e widget app.

Per fare questo, le icone dovrebbero:

• Comunicare bene anche dimensioni ridotte.
• Lavorare con una vasta gamma di sfondi.
• Rispecchiare il tipo di illuminazione del laucher (top-lit).
• Se l’icona è 3D, utilizzare una prospettiva che non sia fuori luogo con le altre icone, forward-facing (rivolte in avanti) funziona meglio.
• Icone 3D funzionano meglio con una ridotta profondità.
• Avere un profilo unico per rendere veloce il riconoscimento, non tutte le icone Android app devono avere dimesioni quadrate.
• Le icone non dovrebbero presentare un quadro ritagliato di un’immagine più grande.
• Avere un peso simile ad altre icone. Le icone che sono troppo sottili o che non utilizzano abbastanza spazio spesso non attirano l’attenzione dell’utente, o possono non stare bene in tutti i contesti/background.

Dimensioni e formato
Le icone di avvio dovrebbero essere a 32-bit PNG con un canale alfa per la trasparenza. Le dimensioni finali un’icona di avvio corrispondente a una data densità dello schermo sono riportate nella tabella sottostante.

Table 1. Summary of finished launcher icon dimensions for each generalized screen density.
Tabella 1. Sommario delle dimensioni dell’icona per ogni densità schermo.

È anche possibile includere pochi pixel di padding (imbottitura) nell icone di avvio per mantenere un peso costante visivo con le icone adiacenti. Ad esempio, un’icona di avvio a 96 x 96 pixel xhdpi può contenere una forma 88x 88 pixel con 4 pixel su ogni lato per padding. Questa imbottitura o padding può essere utilizzata anche per fare spazio a un’ombra sottile, che può aiutare a garantire che le icone di avvio siano leggibili in tutto su qualsiasi colore di sfondo.
Icone delle applicazioni in Android Market
Se si pubblica l’applicazione su Android Market, è necessario fornire anche un icona artwork di 512 x 512 pixel ad alta risoluzione. Questa icona sarà utilizzata in Android Market e non sostituisce l’icona di avvio.

Per suggerimenti e raccomandazioni sulla creazione di icone ad alta risoluzione di avvio che può essere facilmente scalata fino a 512×512, si possono vedere Suggerimenti per Designer sul sito Android Developer (Tips for Designers).

Per informazioni e specifiche sulle icone ad alta risoluzione per l’applicazione in Android Market, vedere anche il seguente articolo:
Graphic Assets for your Application (Guida di Android Market)

Cosa fare e cosa non fare
Di seguito sono riportati alcuni esempi presi dalla guida Android developers su come “fare e non fare” , sono esempi da prendere in considerazione quando si creano le icone per l’applicazione.

Disegno Troppo complicato ? Semplificare le icone non dovrebbe essere eccessivamente complicato. Ricorda che le icone di avvio saranno utilizzate a dimensioni spesso piccole, quindi dovrebbero essere distinguibili a dimensioni ridotte.

Icona ritagliata e opaca (cropped and glossy) ? Le icone non devono essere tagliate. Utilizzare forme uniche, se del caso, ricordate che le icone di avvio dovrebbe differenziare la vostra applicazione. Inoltre, non usare troppo lucido (glossy) a meno che l’oggetto rappresentato è un materiale lucido.

Troppo sottile? Le icone non devono essere sottili. Dovrebbero avere un peso simile a quello altre icone. Le icone troppo sottili non si distinguono bene con tutti i background.

Full-frame oppure sottilmente arrotondati e trattati ?Le icone dovrebbero utilizzare il canale alfa, e non dovrebbe essere semplicemente delle immagini full-frame. Distinguere , quando possibile, la propria icona con un lieve ma accattivante trattamento visivo.

fonte: libera traduzione dalle Android Guidelines

Pasticcini alle icone di iOS

Le icone e le immagini sono una parte fondamentale l’esperienza degli utenti iOS.
Lungi dall’essere un’elemento puramente decorativo, le icone e le immagini nelle nostre applicazioni svolgono un ruolo essenziale nel comunicare con gli utenti.

Per ottenere i migliori risultati, possiamo arruolare un grafico professionista. Un progettista ed esperto grafico può aiutare a sviluppare uno stile visivo integrato per la vostra applicazione e applicare tale stile a tutte le icone e le immagini del caso.

Apple consiglia di utilizzare le immagini in stile universale in modo che la gente possa facilmente riconoscerle. Eviteremo quindi di concentrarsi su  aspetti secondari o poco visibili.

I tecnici Apple abbracciano la semplicità. In particolare, di consiglia di evitare di stipare un sacco di immagini diverse nella vostra icona. Provate a utilizzare un singolo oggetto che esprime l’essenza della vostra applicazione. Si inizia con una forma di base per poi aggiungere i dettagli con cautela. Se il contenuto di un’icona o la forma è eccessivamente complesso, i dettagli possono diventare confusi e può sembrare sfocato quando ridotto in piccole dimensioni.

L’ utilizzo dei colori e ombre leggere possono aiutare l’icona a esprimere meglio il suo ruolo. Non aggiungeremo quindi il colore solo per fare l’icona più colorata. Inoltre, graduienti regolari di solito funzionano meglio della colore diffusion

In generale, bisogna evitare di utilizzare il testo “greco” o linee ondulate per sottolineare il testo. Se si desidera visualizzare del testo nell’icona, ma non volete attirare l’attenzione sulle parole stesse, iniziare con un testo  poi renderlo piu’ leggibile con lo shirnk e/o raddoppiando i layer .

In generale, creare una versione stilizzata del soggetto piuttosto che utilizzare una foto, anche se a volte può essere opportuno utilizzare una foto (o uno screenshot) per un icona.

Se la vostra applicazione ha un’interfaccia utente molto riconoscibile, è consigliabile creare una rappresentazione di essa invece di utilizzare un immagine del software nell’icona dell’applicazione. La creazione di una versione migliorata dell’interfaccia utente è particolarmente importante in quanto gli utenti potrebbero confondere una versione più grande dell’icona con l’interfaccia stessa del app.

Evitare di utilizzare elementi di interfaccia iOS nel disegno. Non si vuole che gli utenti possano confondere le icone o immagini con l’interfaccia utente iOS.

Non usare le repliche di prodotti hardware di Apple nel disegno. I simboli che rappresentano i prodotti Apple sono protetti da copyright e non possono essere riprodotti in icone o immagini. In generale, è una buona idea per evitare repliche di tutti i dispositivi specifici nel disegno, perché questi disegni cambiano di frequente e le icone o immagini che si basano su di esse può apparire datato.

Non riutilizzare iOS icone delle applicazioni nella vostra interfaccia. Può essere fonte di confusione per gli utenti di vedere la stessa icona utilizzata per indicare cose leggermente diverse in luoghi diversi in tutto il sistema.

Ritrarre sostanze reali con precisione. Le icone che rappresentano gli oggetti reali dovrebbero apparire come se fossero fatti di materiali reali e con massa reale. Icone realistiche replicano con precisione le caratteristiche delle sostanze come tessuto, vetro, carta e metallo, e dovranno trasmettere l’idea del peso di un oggetto.

Utilizzare la trasparenza solo quando ha senso. La Trasparenza in un’immagine può aiutare a descrivere materiali come il vetro o la plastica, ma può essere complicato da usare in maniera convincente. Si consiglia quindi di non utilizzare la trasparenza nella vostra icona dell’applicazione.

• English

Cari Editori,

finalmente abbiamo realizzato un sistema che permette di pubblicare riviste, libri, giornali o qualsivoglia pubblicazione senza alcun costo per ogni nuovo numero o per ogni nuovo lettore.

Ci rivolgiamo al piccolo editore come alla grande casa editrice; dopo aver collaudato i nostri prototipi, e dopo piu’ di un anno di sviluppo, i3Factory è lieta di presentare un sistema software che permette di pubblicare le proprie edizioni sull’App Store senza investimenti onerosi.

Attraverso l’App Store di Apple , l’Android Market e Amazon App store, il vostro mercato cartaceo diventerà il mercato online mondiale, con la possibilità quindi di raggiungere nuovi lettori in tutto il mondo.

I costi di stampa in carta sono sempre piu’ elevati e non permettono all’editore di pianificare tirature elevate e quindi di raggiungere un pubblico geograficamente piu’ vasto.

Con il nostro sistema editoriale per iPad , i costi di tiratura si annullano; i  lettori sfoglieranno la vostra pubblicazione sul tablet, iPad, iPhone o Smartphone e il costo per le nuove pubblicazioni sara’ sempre nullo con costo marginale tendente allo zero.

Notiamo che l’esperienza di lettura di un magazine su iPad e di gran lunga piu’ soddisfacente dell’esperienza di leggere la stessa pubblicazione su carta.
Oltre ad essere semplice da sfogliare, basta un gesto con la mano, la rivista diventa piu’ fruibile; basterà pensare alla possibilita’ di poter ingrandire i caratteri con un gesto e fare lo zoom anche su immagini e altri dettagli oltre alla possibilità di fruire di video o di seguire links e ipertesti, html5…

Nessun costo aggiuntivo. Si utilizzano le infrastrutture esistenti del cliente e l’applicazione viene distribuita da Apple, Google e Amazon.

Illimitati lettori potenziali allo stesso costo,

nessun impatto ecologico.,

..sono solo alcuni dei vantaggi dell’utilizzo del  sistema editoriale i3Factory.

Alcune delle principali caratteristiche del  sistema editoriale “i3F Editorial” per iPad , iPhone e Android :

• Pubblicazione e distribuzione Applicazione personalizzata per l’editore  su App Store

• Illimitate Pubblicazioni

• Illimitati Lettori e Utenti

• Distribuzione pubblicazioni su App Store sia gratuitamente che a Pagamento (inApp)

• Investimento Una Tantum: nessun costo di manutenzione

• Nessun costo nascosto: paghi una sola volta e il sistema funziona per sempre

• Dal pdf ad iPad senza costi

• Links ipertestuali sul pdf

• Support per Video e Multimedia

• Supporto Youtube

• Social Network: Facebook, Twitter, etc..
• Supporto HTML5 Nativo
• Supporto Pdf
• Supporto social networks (Facebook , Twitter, etc…)

• Nessuna infrastruttura necessaria, colleghiamo il sistema al vostro sito web senza alcun costo aggiuntivo per hardware.

Alcune caratteristiche Tecniche del sistema editoriale:

• php per la processione dei dati

• sqlite per db
• Interfaccia DB editor

• una singola pagina html con interfaccia in ajax

Funzioni

• autenticazione  utente

• caricamento dei dati realtivi a pubblicazioni

• modifica dei dati con un sistema a versioni

• output dei dati in formato json

• caricamento selletivo immagini per copertine riviste

• resize automatico di dimensioni predefinite delle copertine caricate

• caricamento file zip e pdf

• abbinamento pagina della rivista con video

• backup automatico del db
• Inserimento contenuti extra e Html5

Costi/Prezzi:

Evidentemente i prezzi varieranno rispetto all’esigenza dell’editore, che di norma richiede alcune “personalizzazioni”.

Il prezzo di partenza per la nostra soluzione parte da  200 euro per Autori indipendenti 1000 euro per Piccoli Editori, a partire da 2000 euro  per Medi e Grandi Editori.

Maggiori Informazioni sui pacchetti editoriali potete trovarli su questo in questa pagina:

Sistema editoriale per iPad, iPhone & Android.

o direttamente sul  i3F Editorial web site (http://i3factory.com/editorial)