• 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)

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

• English

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.

• 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)

Un giroscopio all'interno di un telefonino smartphone

Si rumoreggia da tempo dell’imminente rilascio di uno smartphone dotato di un giroscopio costruito con tecnologia MEMS. Le speculazioni sul produttore del telefono vanno da Apple (con l’imminente iPhone 4G) a HTC e a ST-Ericsson, anche se il segreto e’ cosi’ ben mantenuto da rendere il tutto ancora molto incerto. Quel che e’ abbastanza chiaro invece e’ che entro il 2012 tutti i maggiori produttori di smartphone avranno integrato i giroscopi nei loro dispositivi, questo perche’ questi sensori permettono di introdurre nuove modalita’ nell’interazione utente-dispositivo, in particolare nei settori del gioco e della navigazione in interni (dove il segnale GPS e’ scarso o inesistente) oppure con l’invenzione di nuovi gesti per controllare le funzioni del telefono.
Attualmente una prova pratica del sensore a sei assi (tre assi forniti dall’accelerometro – ormai di serie su tutti gli smartphone – e tre dal giroscopio) e’ data dal controller MotionPlus fornito con la console Wii della Nintendo, permettendo un riconoscimento del movimento piu’ sensibile e preciso che con i soli 3 assi forniti dall’accelerometro, questo perche’ l’accelerometro – che rileva il movimento lineare – da solo non e’ in grado di stabilire la differenza tra gravita’ e movimento, mentre con l’ausilio del giroscopio – che rileva il momento angolare – e’ possibile distinguere le due componenti permettendo una risposta ai movimenti dell’interfaccia utente piu’ sensibile e priva di artifatti. Un altro uso molto comune dei giroscopi in tecnologia MEMS lo si trova nei dispositivi di stabilizzazione di molte macchine fotografiche reflex o cineprese digitali, dato che e’ possibile controbilanciare l’effetto del movimento della macchina tramite uno spostamento in direzione opposta del sensore.
Senza dubbio l’esperienza acquisita nel campo della fotografia verra’ immediatamente riversata, come prima applicazione, negli smartphone, in particolare in quei dispositivi che consentono scatti con risoluzioni superiori ai 5 megapixel, particolarmente sensibili alla stabilita’ dell’immagine.
Nel video un’interessante demo delle applicazioni del chip MPU-3000 di InvenSense sugli smartphone.