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.

Schermate dell’applicazione

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

Sviluppo App per Magazine

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

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

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

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

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

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

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

Architettura

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

Riportiamo di seguito un diagramma a blocchi funzionale.

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

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

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

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

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

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

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

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

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

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

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

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

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

L’articolo è disponibile in inglese su iOS Blog.

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

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

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

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.

i3Factory ha Pubblicato su App Store la rivista Varese Focus edita dall’Unione Industriali di Varese:

App Name: Varese Focus

App Version Number: 1.0

App SKU: 777010777010777010

App Apple ID:415378997

i3Factory presenta la sua nuova piattaforma per editori dedicata sia ai grandi gruppi che ai piccoli imprenditori.

Proponiamo anche soluzioni per piccolissimi editori con la possibilità di pubblicare infiniti numeri di una rivista, libro o di un qualsiSI periodico ad un costo incredibilmente concorrenziale date le economie di scala che il nostro modello di sviluppo “crowd” ci permette.

Il codice dell’app e’ sviluppato in OBJ-C , ovvero con linguaggio nativo per iPhone/iPad iOs, dato che i3Factory preferisce evitare il piu’ possibile la produzione di semplici Web App che riteniamo “poco professionali”.

L’Applicazione Varese Focus pe iPad è realizzata in partnership con Idini Consulting.

Per contattare un agente i3Factory e’ possibile scrivere al seguente indirizzo: