Quando si decide di progettare un’App è sempre necessario seguire i principi di base della progettazione industriale.
Molte persone  pensano di commissionare un’app, ma quando si trovano a dover descrivere l’applicazione e quindi come la loro idea possa essere tradotta nell’esperienza dall’utente e nell’interfacia grafica (User Experience & User Interface),  si trovano impreparati e si nascondono molto spesso dietro frasi del tipo “non saprei questo è un lavoro per tecnici, pensateci voi tecnici!”.
Inutile aggiungere che quando poi i cosidetti “Tecnici” si mettono al lavoro queste persone, che non hanno vuluto delegare il concept, inizieranno a chiedere modifiche sostanziali dispensando consigli e ragguagli di ogni genere e quasi sempre solo dopo che l’app e’ arrivata alla fase finale del suo sviluppo.
E’ ben noto il concetto secondo il quale i “tecnici”, e gli ingenieri, prima costruiscono il cuore dell’applicazione e poi ci adattano il design e fanno il contrario, loro malgrado, solo se il commitment e’ valido e convincente e, sopratutto, quando questo è deciso fin dall’inzio delle fasi di progettazione.
Di norma con l’approccio “fate voi che poi vediamo” , voluto dai professionisti distratti e poco preparati,  il risultato estetico finale può risultare quantomai scadente dato che ogni ingeniere sa bene che, prima di mettersi a scrivere codice, bisogna aver chiari i principi dell’interfaccia utente unitamente alla descrizione delle funzionalità legate all’esperienza dell’utente stesso.

Alcuni sofisti mi potranno criticare per l’uso della parola “utente”, che a volte risulta poco accattivante se si pensa che alla fine gli utenti non sono altro che persone, ovvero individui utilizzatori. Questa differenza di significato delle parole mi è molto chiara, ma per semplicità comunicativa e sopratutto per necessità di traduzione preferisco usare la parola “utente” o “utilizzatore” al posto dell’ “individuo“.

10 principi per un buon design di un’app e di un prodotto

Inanzi tutto,  per citare Steve Jobs,  propongo  una delle definizioni di design che più mi ha convinto:
“Il design è l’anima che si trova al cuore di un oggetto creato dall’uomo e che gradualmente si estrinseca ai piani esteriori.”

Di certo lo stesso Jobs si ispirava ai principi di Dieter Rams, ex-designer della Braun, che ha enumerato i suoi 10 principi per un  buon design di un prodotto:

Dieter Rams e i suoi prodotti di design

• Un buon design deve essere innovativo.
• Un buon design deve rendere il prodotto utile.
• Un buon design deve essere dotato di estetica.
• Un buon design deve aiutare a capire il prodotto.
• Un buon design non deve essere invasivo, mancare di riservatezza.
• Un buon design deve essere onesto.
• Un buon design deve essere durevole.
• Un buon design è la conseguenza dell’ultimo dettaglio.
• Un buon design si deve preoccupare dell’ambiente.
• Un buon design deve contenere il minor design possibile.

Naturalmente è facile capire che questi principi si adattano sia al design dei prodotti industriali, ma anche per il design delle Applicazioni, sopratutto se queste verranno utilizzate sui prodotti che sono stati costruiti proprio secondo i buoni principi del design industriale, come lo sono tutti i prodotti Apple.

Progettare meglio, lavorare meno

Dieter Rams, creatore dei 10 principi, ha sempre espresso il suo approccio al design con la frase: “Weniger, aber besser” , ovvero “Meno, ma meglio” .
Il minimalismo , oltre ad essere molto elegante, è sicuramente il modo migliore per permettere a tutti gli utenti-utilizzatori di comprendere d’istinto il prodotto e le sue funzionalità e rende il prodotto stesso, o l’App,  amichevole all’uso (user friendly) e “puro”.

Di seguito riporto i commenti , tradotti dall’inglese, dello stesso Rams sui principi da lui stesso enunciati:

1.  Le possibilità d’innovazione non sono esaurite. Lo sviluppo tecnologico offre sempre nuove opportunità per il design innovativo. Ma il design innovativo si sviluppa sempre assieme alla tecnologia innovativa, e non può mai essere fine a se stesso.
   (The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself )
2. Un prodotto viene acquistato per essere utilizzato. Esso deve soddisfare determinati criteri, non solo funzionali, ma anche psicologici ed estetici. Un buon design sottolinea l’utilità di un prodotto, mentre trascura tuuto ciò che potrebbe sminuirla.
   (A product is bought to be used. It has to satisfy certain criteria, not only functional, but also psychological and aesthetic. Good design emphasises the usefulness of a product whilst disregarding anything that could possibly detract from it. )
3. La qualità estetica di un prodotto è parte integrante della sua utilità, perché i prodotti che utilizziamo ogni giorno influiscono sulla nostra persona e il nostro benessere. Ma solo gli oggetti ben costruiti possono essere belli.
   (The aesthetic quality of a product is integral to its usefulness because products we use every day affect our person and our well-being. But only well-executed objects can be beautiful.)
4. Chiarifica la struttura del prodotto. Meglio ancora, si può far parlare il prodotto. Meglio se esso è auto-esplicativo.
   (It clarifies the product’s structure. Better still, it can make the product talk. At best, it is self-explanatory.)
5. I prodotti che soddisfano un fine sono come strumenti. Non sono né oggetti decorativi, né opere d’arte. Il loro Design dovrebbe quindi essere sia neutrale che sobrio, per lasciare spazio all’auto-espressione dell’utilizzatore.
   (Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.)
6. Non costruire il prodotto in modo da farlo apparire più innovativo, potente o importante di quanto sia realmente. E non tentare di manipolare il consumatore con promesse che non possono essere mantenute.
   (It does not make a product more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.)
7. Evita di seguire la moda ma non appare mai antiquato. A differenza del design “alla moda”, il prodotto deve durare per molti anni – anche nella società dell’usa e getta di oggi.
   (It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society.)
8. Nulla deve essere arbitrario o lasciato al caso. La cura e la precisione, nel processo di progettazione, mostrano il rispetto nei confronti dei consumatori.
   (Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.)
9. Il Design offre un importante contributo alla salvaguardia dell’ambiente. Esso conserva le risorse e riduce al minimo l’inquinamento fisico e visivo durante tutto il ciclo di vita del prodotto.
   (Design makes an important contribution to the preservation of the environment. It conserves resources and minimises physical and visual pollution throughout the lifecycle of the product.)
10. Meno, ma meglio – questo perchè ci si concentra sugli aspetti essenziali, e i prodotti non sono appesantiti da elementi non essenziali. Torna alla purezza, torna alla semplicità.
    (Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials.Back to purity, back to simplicity.)

Valutazione Euristica

A questo punto non mi resta che descrivere anche la cosidetta valutazione euristica.
La Valutazione Euristica è un metodo ispettivo che viene effettuato esclusivamente dagli esperti di usabilità  e consente di valutare se una serie di principi generali di progettazione sono stati applicati correttamente nell’interfaccia utente.
Le linee guida (“Ten Usability Heuristics”) su cui si basa questo tipo do valutazione sono state sviluppate negli anni 1990 da Jakob Nielsen e Rolf Molich e sono state pensate per i desktop software , ma anche in questo caso questi principi sono ancora validi per le applicazioni studiate per touchscreen, come le App iOS per iPhone e iPad ,  per le  app Android e Window Mobile.

Progettare indipendentemente dalla risoluzione dell’interfaccia utente è difficile, soprattutto se si deve programmare il codice del disegno.
Per semplificare questo processo di sviluppo è utile un’ applicazione di disegno vettoriale che genera istantaneamente codice Objective-C.
In questo modo è possibile progettare il design dei bottoni o di tutti quei componenti che possono essere visualizzati da iOS o OSX attraverso il codice; in questo modo l’app sarà di certo molto performante e avrà la qualità del design indipendente dalla risoluzione grafica del dispositivo, sia esso iPad3, iPhone4, iPad 2 o qualsiasi altro dospositivo apple.

Abbiamo utilizzato l’app PaintCode con iMac e la abbiamo scaricata dal mac app store. Il prezzo non è tra i più bassi ed è di 80 dollari, ma l’acquisto di questa app permette al programmatore di smettere di scrivere il codice di disegno e al designer piu’ avanzato di non lavorare direttamente su files grafici.

PaintCode è una semplice applicazione di disegno vettoriale che genera codice per Mac OS X e iOS.

Non è più necessario ricompilare il codice, più e più volte, per ottenere il risultato desiderato. Con app di questo tipo anche un graphic designer senza esperienza di programmazione può disegnare controlli, icone e altri elementi propri della UI.

Interfaccia utente resolution-independent

Con questo stumento è possibile utilizzare forme vettoriali built-in (rettangoli, rettangoli arrotondati, ovali, testi, Béziers, stelle e poligoni) per disegnare i pulsanti, cursori, icone e altri elementi dell’interfaccia utente, allineandoli alla griglia a pixel nei posti giusti.
È anche possibile aggiungere gradienti e ombre per rendere l’interfacia più realistica.

Generare il codice per OS X e iOS

È possibile scegliere tra OS X o iOS codice. PaintCode genera Objective-C che utilizza Cocoa, Quartz e Core Graphics API. È anche possibile spostare l’origine e generare un codice di disegno per NSViews capovolte!

Preparatevi per i display Retina

Per aiutarvi a preparare il mondo ad alta risoluzione, con display ad alta densità, PaintCode consente di attivare la modalità Retina. Questo raddoppia la risoluzione del disegno. Quando si è in modalità Retina, si può immediatamente vedere il disegno in modo molto simile a iPhone 4, iPhone 4S, il nuovo iPad 3 e altri dispositivi retina-display  che possono essere aggiunti in futuro.

Con il rilascio della prossima generazione dell’ iPad (iPad 3)  si aprirà una nuova stagione per la progettazione grafica ad altissima risoluzione.Le nuove App dedicate ad iPad , sopratutto quelle universali , dovranno valorizzare il nuovo Retina display, che raggiunge l’incredibile risoluzione  di 2048×1536 pixel.

L'iPad 3 possiede uno schermo di dimensione superiore anche alla risoluzione full HD del blu Ray (1920*1080 px).

La distribuzione di massa di un iPad con uno schermo così dettagliato e di risoluzione grafica così elevata rappresenta una sfida per tutti gli sviluppatori che vogliono mantenere i loro App Bundle al di sotto del limite di 20 MB.
20 Mega Byte è attualmente il limite imposto  dall’Apple Store per  effettuare  il download delle App attraverso la rete Umts , 3G o edge; sapendo che Apple limita il download di App da rete cellulare dobbiamo tener presente che se compiliamo App “Grasse” – Fat Binary superiori ai 20 mb – è necessario che il nostro cliente sia collegato in modalità Wifi.

Di seguito  suggerisco alcune tecniche che gli sviluppatori possono utilizzare per mantenere le loro App  nella fascia ” magra”.

Vi mostrerò interessanti tecniche  suggerite in un post di David Smith (http://david-smith.org/blog/2012/03/05/techniques-for-shrinking-app-bundle-size/) , un developer di app quale ad es. My Recipe Book.

Rimuovere il codice inutilizzato

Il primo passo per il taglio  di spazio è quello di trovare il codice non utilizzato nel progetto. Il candidato più probabile sarebbe da trovare in tutte le librerie di terze parti (3rd party library) che vengono fornite con il progetto, ma che non verranno attivamente utilizzate.

Inoltre, bisogna sincerarsi di controllare anche  l’intero contenuto di una libreria ; se si ha solo bisogno di alcuni file, si possono eliminare quelli non utilizzati.

Rimuovere risorse non utilizzate

Il secondo passo è quello di assicurarsi che non siano comprese le risorse che non vengono utilizzate nel nostro progetto. Spesso trovo che la nostre app  comprendono  immagini, icone, suoni che appatengono a versioni precedenti a cui non si fa più riferimento.

Fare auditing del vostro progetto per questi casi è spesso difficile,  e per questo David ci consiglia un ottimo strumento chiamato Slender che elimina una parte del lavoro analizzando il progetto per i file inutilizzati e permette di rimuoverli. Questo strumento analizza vari tipi di file e oltre a indicare quali di questi non vengono referenziati all’interno del progetto, individua anche alcuni problemi, come ad esempio la mancanza della versione @2x (utilizzata per il Retina Display), la dimensioni delle artwork grafiche di sistema (icona, Default image, ecc.) più una serie di controlli apparentemente minori ma che servono a fare pulizia del progetto. Inoltre questa applicazione ad ogni modifica effettua una copia di backup affinché eventuali file incorrettamente rimossi possano essere facilmente ripristinati.

Caricare le risorse On-Demand

Se il progetto comprende risorse come video tutorial o immagini che sono utilizzati  e necessari solo raramente, è possibile spostare questi su un web-server e richiamarli on-demand.  Amazon S3 o di un piccolo servizio di VPS  Linode sono ottime soluzioni possibili.  E’ necessaria discrezione con questa tecnica se si vuole evitare di frustrare l’utente con una serie download dopo l’installazione.
Personalmente trovo utile ciò che ha fatto David per i video tutorial  nella sua App My Recipe Book, questi Video infatti sono richiamati solo in schermate secondarie dell’app e non fanno parte della cosidetta user’s initial experience.
Nell’eventualità che questi file siano necessari per l’utilizzo primario dell’app, potete sempre offrire la possibilità di una visione online a quella di poter scaricare il file localmente. Tenderei ad evitare il fastidioso requisito di scaricare i file una volta scaricata l’app, dato che spesso l’utente non si avvede immediatamente di questa necessità e nel momento stesso in cui se ne accorgerà questo accadrà troppo tardi, ormai lontano da ogni connessione Wi-Fi.

Utilizzare immagini Patterned

Seguendo la definizione di Wikipedia:
<<”Nell’ingegneria del software, un design pattern (schema di progettazione) può essere definito come : una soluzione progettuale generale a un problema ricorrente. Esso non è una libreria o un componente di software riusabile, quanto piuttosto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software (NB: nel nostro caso e’ un’immagine).
….
La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il secondo è legato agli aspetti progettuali del software.”>>

Nel nostro caso, un Pattern è una sorta di trama grafica (una sorta tegola) che viene ripetuta e sata come riempimento per un’immagine.

UIColor include una funzione fantastica per ridurre la necessità di includere le immagini di grandi dimensioni strutturate all’interno del progetto.

Ad esempio le dimensioni medie di un’immagine per dispositivo Apple sono le seguenti:

• iPad 3 (@2x) = 2048*1536 px = 1,2 Mb = 1200 Kb
• iPad 1 e 2 = 102*768 px = 0,73 Mb = 730 Kb
• iPhone 4 (@2x) = 960*640 px = 0,63 Mb = 630 Kb
• iPhone 3 = 480*320 = 0,34 Mb = 340 kb

TOTAL = 2900 Kb

• Single Pattern Tile = 300 kb

Vi segnalo uno dei tanti video che vi insegnerà (tutorial) a creare Pattern:

Un uso utile del Patterned image è quando volete fornire alla vostra applicazione uno sfondo stilizzato, anche se questa tecnica si applica altrettanto bene a piccole aree in cui si desidera aggiungere texture a un controllo dell’interfaccia utente.

Basta impostare il colore di sfondo della vista desiderata per un colore fantasia come questo:

view.backgroundColor = [UIColor colorWithPatternImage: [UIImage imageNamed: @ "pattern_image.png"]];

La view  avrà così uno sfondo con texture che viene scalato e regolato secondo le dimensione della vista stessa.
David ci segnala che una buona fonte per le tile texture (texture tegola) è il progetto Subtle Patterns.

Utilizzare Stretched UI Image

UIImage include un metodo performante per creare immagini che vengono scalate o bilanciate dinamicamente in relazione  alla dimensione (size). L’immagine è configurata in modo che la sezione centrale si allunga mantenendo invariati i bordi. Questo è spesso usato per oggetti, come i pulsanti, dove si ha uno stile per gli angoli e per i lati, ma il corpo del pulsante è semplice.
Funziona bene anche per la creazione di un effetto”inciso” (etched) in una table view (vista tabella).

Quindi, piuttosto che la creare un’immagine 320×48 che rappresenta lo sfondo della cella si crea una piccola immagine 1×3 con il top desiderato, il corpo e i colori di sfondo. Questo viene poi assegnata come backgroundView;

UIImage* template = [UIImage imageName:@"template.png"]; UIImage* stretched = [template resizableImageWithCapInsets:UIEdgeInsetsMake(1, 0, 1, 0)]; cell.backgroundView = [[UIImageView alloc] initWithImage:stretched]; 

Disegnare elementi dell’interfaccia utente (UI Elements) in Quartz

Essenzialmente quando si realizzano degli elementi dell’interfaccia (UI Elements) utente geometrici  è spesso possibile evitare l’utilizzo di un’immagine PNG per raggiungere l’obiettivo dato dalla progettazione.
Piuttosto che pre-generare gli elementi in Photoshop e poi bundle con l’applicazione, è sufficiente rendere lo stile desiderato in fase di runtime. Questo può essere semplice come creare uno stile pulsanti quadri:

UIButton SquareButton * = [UIButton buttonWithType: UIButtonTypeCustom];
 [squareButton.layer setBorderColor: [[UIColor blackColor] CGColor]];
 [squareButton.layer setBorderWidth: 1,0];
 [SquareButton setTitleColor: [UIColor blackColor] forState: UIControlStateNormal];
 squareButton.backgroundColor = [UIColor whiteColor];

Oppure, più complicato come il progetto Gradient Buttons dell’ottimo Jeff LaMarche. Per quest’ultimo ricordiamo che i file presenti nel repository non sono compatibili con ARC e quindi vanno modificati (le modifiche richieste sono poche ma necessarie per non avere errori di compilazione).

L’obiettivo è quello di rendere quello che ti serve attraverso il codice, piuttosto che fare il bundling con decine di mini vedute di background con la tua applicazione.

Utilizzare file PDF

Ultimamente è stata avanzata dal noto sviluppatore inglese Matt Gemmell, nel suo articolo Using PDF Images in iOS apps, la proposta di utilizzare il PDF come elemento portante di immagini vettoriali. Ricordiamo che le immagini vettoriali permettono di raggiungere, per loro natura, delle definizioni molto elevate, per esempio le due immagini del “close button” (entrambe tratte dall’articolo di Gemmell), sono la rappresentazione in scala diversa dello stesso oggetto vettoriale: . Utilizzando Photoshop è possibile ottenere un file PDF sufficientemente compresso (il PDF è un ottimo “vettore” di file vettoriali) che potrà essere in seguito manipolato con del codice Objective-C per ottenere le immagini delle dimensioni desiderate. In tal caso si richiede allo sviluppatore la capacità di spacchettare queste immagini nel momento opportuno senza anche qui bloccare l’applicazione all’inizio. Un buon esempio di tale codice è reperibile nel progetto UIImage+PDF category su GitHub.

 Conclusioni

L’uso ponderato di queste tecniche può aiutare a ridurre drasticamente le dimensioni del bundle delle vostre applicazioni, aiuta quindi a pubblicare un’app sotto il limite di download per 3G.

Tuttavia, è necessario fare attenzione e non esagerare; non fatevi prendere la mano e a volte è meglio frenare il vostro desiderio di ottimizzazione se c’e’ il rischio di ottienere una soluzione che sia lontana dal buon gusto di progettare un user experience di gusto e design.

• 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