Spesso ci capita di dover aggiornare le nostre applicazioni con  le immagini ad alta risoluzione necessarie per il nuovo iPad (iPad 3 o iPad 4). Fortunatamente il nuovissimo iPad Mini ha mantenuto la stessa risoluzione del primo degli iPad che è di 1024 x 768 pixels.
Poichè non è sempre semplice trovare i documenti ufficali di  Apple , in questo articolo ho nuovamente raccolto tutte le informazioni di cui abbiamo bisogno per aggiornare le icone, le immagini di intro o splash, e così via.

Innanzi tutto partiamo da questa utile tabella:

Ricordiamo che con il passaggio da iOS 5 a iOS 6 è nato il nuovo iPhone 5, insieme con l’iPod touch di 5 ° generazione.
Questi nuovi dispositivi Apple hanno solo un grande cambiamento che aggravia il lavoro di sviluppo delle App: la risoluzione dello schermo.
Questi dispositivi hanno un ampio schermo 4″ , WDVGA (Wide VGA doppia) 640 × 1136 pixels, 326 DPI-Retina display.
Questi dispositivi hanno la stessa larghezza 4/4S iPhone ma più 176 pixel di altezza in modalità Portrait.

App Icon Template

Segnalo nuovamente, come ho gia fatto in un’altro articolo, questo utilissimo tool scaricabile direttamente dal sito “appicontemplate.com” .

Scaricando il file otterrete un modello PSD del’ icona dell’App che, attraverso oggetti avanzati in Photoshop, vi permette di automatizzare il processo di esportazione delle varie dimensioni del file icon.png che devono essere necessariamente incluse nel bundle di ogni iOS App.

Attraverso questo modello Photoshop potremo modificare solo l’icona di dimensione più grande e verrà automaticamente eseguito il rendering che permetterà di avere le icone di dimensioni minori attraverso un veloce flusso di lavoro.
Questo modello è stato creato dal designer danese Michael Flarup.

Come si usa (How to) App Icon Template ?
Il modello funziona con Photoshop CS2 o versioni successive.
Basta aprire il file PSD con la vostra versione di Photoshop e fare “clic destro” sul LAYER (Livello) chiamato “EDIT THIS SMART OBJECT” (MODIFICARE QUESTO OGGETTO SMART) e premere  su ’Edit Contents’ (“Modifica contenuto”).
Verrà aperto il file Icon.psb e potrete creare il vostro Artwork  in questo canvas (quadro).
Dopo aver salvato il Icon.psb, dovrebbe essere automaticamente eseguito il rendering per le diverse dimensioni del file PSD principale .
E’ possibile utilizzere le Actions (azioni automatizzate) di Photoshop che sono in bundle con la risorsa per esportare i file dell’icona nelle versioni squared and rounded corner (squadrate e arrotondate).

Buon Design!

Prendendo spunto da  articoli trovati scorrendo diversi blogs, segnalo queste importanti informazioni utili a qualsiasi designer o sviluppatore che intenda disegnare UI (User Interface o Interfacce Utente) per differenti dispositivi smartphone.

Il successo di Android, come sistema operativo per dispositivi mobile, ha portato i produttori di smartphones a produrre una grande varietà di schermi (display) di diverse dimensioni  e risoluzioni. Nel Blog phonearena.com/ (http://www.phonearena.com/news/Display-Comparison-Apple-iPhone-5-vs-Samsung-Galaxy-S-III-vs-HTC-One-X-vs-Nokia-Lumia-900_id35171) viene fornito un elenco di dispositivi di esempio.

Considerando il dispositivo in orientamento verticale (Portrait), definiamo  l’asse X come  la larghezza in pixel e l’asse Y come lunghezza o l’altezza in pixel. Ovviamente si consideri che il dispositivo viene anche tenuto in orientamento orizzontale (Landscape) dato che anche Android ha il supporto per entrambi gli orientamenti.
Si potrà notare che il numero totale di pixel di uno schermo corrisponde al numero dell’asse X moltiplicato per il numero in Y. Maggiore è il numero di pixel per ogni pollice (Dpi)  più nitida sarà la visualizzazione delle immagine (a condizione che tali immagini siano ad alta risoluzione).

L’iPhone 4S è indicato nella tabella per confronto, vedere la linea DVGA, non è un telefono Android.
Nota: a Full High Definition (FHD) o lo schermo 1080i/1080p è 1080 × 1920 che è 2.073.600 pixel.

Stimolato dal blog Tekeye.biz (http://tekeye.biz/2012/example-list-of-android-device-screen-resolutions-and-sizes) andrò ora a confrontare lo schermo HD da 4,8 pollici Super AMOLED del Samsung Galaxy S III, il display 4,7 pollici 720p Super-LCD 2  su HTC One X, e lo schermo del Lumia 900 con is suoi 4,3 pollici ClearBlack AMOLED che viene ostentato dalla Nokia.

Come per ogni confronto di dispositivi elettronici ciò che veramente conta non sono solo le specifiche hardware , ma bisogna vedere come questi telefoni se la cavano in situazioni reali, in quanto si sa, questo è esattamente ciò che più conta.

Vediamo quindi come se la cavano in termini di Luminosità e contrasto (Brightness and Contrast):

Non c’è niente di meglio per attirare la gente che avere un display luminoso, giusto? John V. di Tekeye ha quindi impostato manualmente tutti e quattro gli smartphone per la loro impostazione di luminosità più alta. I nuovi iPhone 5 di IPS-LCD schermo salta subito all’occhio per  avere la più alta luminosità,   il vantaggio è che quindi siamo in grado di avere visibile tutto sul display dell’iPhone 5 quando lo si utilizza all’aperto – anche quando il sole batte direttamente sulo schermo. Inoltre, il pannello Super-LCD 2  in uso da parte del HTC One X mostra il suo valore, in quanto si tratta di un pannello con un cuore LCD che dimostra bene il suo valore in condizioni esterne. Infine, il Samsung Galaxy S III e Nokia Lumia 900 sono allo stesso livello in termini di visibilità esterna, in quanto i rispettivi pannelli HD Super AMOLED e ClearBlack AMOLED sono così efficaci che ci permettono di vedere correttamente quando siamo fuor, ma allo stesso tempo, il calo di contrasto, inclinando leggermente provoca riflessi che interferiscono con la loro usabilità.

Risoluzione:

Leggendo sul foglio delle specifiche, si potrebbe supporre che i due smartphone Android  in questo confronto abbiano  la vittoria visto che hanno una  risoluzione di 720p, ma ancora una volta, ciò che si legge sulla carta e non tiene conto di densità di pixel. Tuttavia, se non dovessimo tenerne conto, allora  l’iPhone 5 dovrebbe essere preso in considerazione con la sua densità di pixel di 326 ppi. Tuttavia, prima di concretamente dire che è il vincitore all’unanimità, gli occhi hanno bisogno di confermare ciò che sembra ovvio.

Caricando il  sito web su tutti e quattro gli smartphone e, guardandoli, da una view ingrandita, è innegabile che la  risoluzione 640 x 1136  dell’ iPhone 5  presenta invisualizzazione dettagli più nitidi. In realtà, il testo sullo schermo ha spigoli vivi che aiutano a rafforzare le sue immagini nitide per renderli facilmente visibili ad occhio nudo. Allo stesso tempo, l’HTC One X da 4.7-pollici e 720p può visualizzare  immagini interessanti – però, la visualizzazione è un po ‘po’ più morbida, cercando intorno ai bordi, in parte a causa della sua densità di pixel inferiore che è di 312 ppi. Al terzo posto, è la  risoluzione del Samsung Galaxy S III da 4,8 pollici con 720 x 1280 px che impiega la PenTile Matrix. Indipendentemente da questo, la sua carenza non pregiudica l’aspetto dei  dettagli guardando il suo display da una distanza normale. E, infine, il Lumia Nokia 900 non riesce a stupire con il suo display da 4,3 pollici WVGA (480 x 800), come la sua risoluzione in pixel di 217  ppi si allontana  drasticamente dalla concorrenza, con conseguente immagini che mancano della stessa nitidezza dei concorrenti.

Perché parliamo di Produzioni video cenematografiche

Si potrebbe pensare che la gestione video sia limitata ad applicazioni come iMovie o Vimeo e a una nicchia di esperti video. Invece può essere esteso ad una gamma più ampia di applicazioni, non è essenzialmente limitato a editing video. In questo articolo forniremo una panoramica del Framework AV Foundation applicato su un esempio pratico.

Nel nostro caso particolare, la sfida era quella di creare un’applicazione che, partendo da una serie di clip video esistenti, fosse stata in grado di costruire una storia fatta collegando un sottoinsieme di queste clip sulla base di decisioni prese dall’utente durante l’interazione con l’applicazione.
Il gioco finale è un insieme di scene, girato in luoghi diversi, che compongono una storia. Ogni scena è composto da un prologo, una conclusione (epilogo) e una serie di piccole clip che verranno eseguite dall’applicazione sulla base di alcune scelte fatte dagli spettatori – utenti- giocatori.  Se le scelte sono corrette, lo spettatore sarà in grado di riprodurre tutta la scena fino al suo lieto fine, ma in caso di errore dovrà tornare sulla scena prologo iniziale o in una certa scena intermedia. Lo schema seguente mostra un possibile schema di una tipica scena: un prologo, un flusso vincente (verde) alcuni rami (giallo sono intermedie, il rosso stanno perdendo filiali) e di un lieto fine. Così gli spettatori da qualche parte nel TRACK1 saranno chiamati a prendere una decisione, se lui / lei è in quel momento in gioco continuerà con TRACK2, se non entrerà nel giallo Track4, e così via

Quello che abbiamo tra le mani è la serie completa di tracce, ogni traccia rappresenta una sottosezione specifica di una scena, e uno storyboard che ci fornisce le regole da seguire per costruire la storia finale. Così lo storyboard è fatto dalle scene, dalle tracce del compongono ogni scena e dalle norme che stabiliscono il flusso attraverso queste tracce.
La sfida principale per lo sviluppatore è quello di mettere insieme queste clip e riprodurre un video in base allo stato attuale dello storyboard, quindi passare alla successiva, selezionare un nuovo clip di nuovo e così via: tutto deve trascorrere fluidamente senza interruzioni.
Lo spettatore deve prendere le decisioni, interagendo con l’applicazione-gioco e questo può essere fatto sovrapponendo al film con alcuni controlli personalizzati.

AV Foundation Framework

Sarebbe impossible raggiungere gli obiettivi spiegati nel paragrafo precedente utilizziando lo standard Media Framework view controllers, MPMoviePlayerController e MPMoviePlayerViewController. Questi conrollers sono buoni per riprodurre un filmato e fornire i controlli di sistema, a schermo intero e la rotazione del dispositivo di sostegno, ma assolutamente non adatti per i controlli avanzati.
Dopo il rilascio di iPhone 3GS dell’utility per la fotocomara avevamo la possibilità di fare un po ‘di tagli e l’esportazione, ma queste capacità non sono state date agli sviluppatori attraverso le funzioni pubbliche del SDK. Con l’introduzione di iOS 4, l’attività svolta da Apple con lo sviluppo delle app iMovie ha dato agli sviluppatori un ricco insieme di classi che consentono la manipolazione completa dei video . Tutte queste classi sono state raccolte ed esportate in un unico framework pubblico, denominato AV Foundation. Questo framework esiste da iOS 2.2, a quel tempo era dedicato alla gestione audio con la ben nota classe AVAudioPlayer, poi è stato esteso in iOS 3 con il AVAudioRecorder e le classi AVAudioSession ma il set completo di funzionalità che consentono capacità video avanzate ha avuto luogo solo a partire dal iOS 4 e sono stati pienamente presentati al WWDC 2010.

La posizione della AV Foundation nello iOS Frameworks stack si trova  sotto UIKit, dietro l’application layer, e immediatamente sopra i basic Core Services frameworks, in particolare Core Media che viene utilizzato da AV Foundation per importare strutture di temporizzazione e le funzioni necessarie per la gestione dei media . In ogni caso si può notare la diversa posizione nello stack rispetto Media Player di alto livello. Ciò significa che questo tipo di struttura non è in grado di offrire una classe plug-and-play  per la riproduzione di semplici video , ma si potranno apprezzare i moderni concetti di alto livello che sono alla base di questo framework, di sicuro non siamo allo stesso livello dei vecchi framework come core Audio.

(image source: from Apple iOS Developer Library)

Building blocks

L’organizzazione dele classi di AV Fondation è abbastanza intuitiva. Il punto di partenza e il building block principale è data da AVAsset. AVAsset rappresenta un oggetto statico multimediale ed è essenzialmente un aggregato di tracce che sono rappresentazioni temporizzate  di una parte de media. Tutti i brani sono di tipo uniforme, in modo che possiamo avere tracce audio, tracce video, tracce sottotitoli, e un complesso di attività può essere fatto di più tracce dello stesso tipo, ad esempio siamo in grado di avere più tracce audio. Nella maggior parte dei casi un asset è fatto di un audio e una traccia video. Si noti che AVAsset è una classe astratta per cui è indipendente dalla rappresentazione fisica dei media che rappresenta, inoltre la creazione di un’istanza AVAsset non significa che noi abbiamo tutti i media pronti per essere riprodotti, si tratta di un puro oggetto astratto.

Ci sono due classi di attività disponibili: AVURLAsset, per rappresentare un supporto in un file locale o in rete, e AVComposition (insieme con la sua variante mutevole AVMutableComposition ) per un’attività composta da più supporti. Per creare una risorsa da un file abbiamo bisogno di fornire l’URL del file:

NSDictionary *optionsDictionary = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:AVURLAssetPreferPreciseDurationAndTimingKey];
AVURLAsset *myAsset = [AVURLAsset URLAssetWithURL:assetURL options:optionsDictionary];

L’ options dictionary poò risultare nullo ma per i nostri scopi – per fare una composizione film – abbiamo bisogno di calcolare la durata esatta e fornire l’accesso casuale ai media. Questa opzione extra, che è l’impostazione su YES della chiave AVURLAssetPreferPreciseDurationAndTimingKey, potrebbe richiedere più tempo durante l’inizializzazione delle attività, e questo dipende dal formato di film. Se questo film è in QuickTime o MPEG-4, il file contiene informazioni aggiuntive che in sintesi annulla il tempo in più, ma ci sono in altri formati, come MP3, in cui queste informazioni possono essere estratte solo dopo la decodifica del media file, in tal caso l’inizializzazione del tempo non è trascurabile. Si tratta di una prima raccomandazione che diamo agli sviluppatori: si prega di utilizzare il formato del file a seconda dell’applicazione.
Nella nostra applicazione dobbiamo già conoscere le caratteristiche dei film che stiamo usando, ma in un diverso tipo di applicazione, in cui è necessario fare un po ‘di editing dei filmati, si può essere interessati a ispezionare le proprietà delle risorse. In tal caso si deve ricordare la regola di base che l’inizializzazione di un asset non significa aver caricato e decodificato in memoria: questo significa che ogni proprietà del file multimediale può essere ispezionata, ma questo potrebbe richiedere un poco di tempo in più. Per completezza abbiamo semplicemente introdotto il modo asset inspection che può essere fatto lasciando l’utente interessato alla documentazione di riferimento (vedere l’elenco proposto letture alla fine di questo post). Fondamentalmente ogni proprietà dell’attività può essere verificata utilizzando un protocollo asincrono chiamato AVAsynchronousKeyValueLoadingwhich che definisce due metodi:

- (AVKeyValueStatus)statusOfValueForKey:(NSString *)key error:(NSError **)outError
– (void)loadValuesAsynchronouslyForKeys:(NSArray *)keys completionHandler:(void (^)(void))handler

Il primo metodo è sincrono e restituisce immediatamente lo stato di conoscenza del valore specificato. Ad esempio si può chiedere lo status di “durata” e il metodo restituisce uno di questi stati possibili: carico, carico, fallito, sconosciuto, annullato. Nel primo caso il valore di chiave è noto e quindi il valore può essere immediatamente recuperato. Nel caso in cui il valore è ignoto è opportuno richiamare le loadValuesAsynchronouslyForKeys:completionHandler: metodo che alla fine dell’operazione chiamerà il callback dato nel completionHandlerblock, che a sua volta interroga lo stato di nuovo per l’azione appropriata.

Video composition

Come abbiam detto all’inizio, il nostro storyboard è composto da una serie di scene e ogni scena è composta da diverse clip il cui ordine di riproduzione non è nota a priori. Ogni scena si comporta indipendentemente dalle altre in modo da creare una composizione per ogni scena. Quando abbiamo un insieme di attività, o tracce, e da loro si costruisce una composizione nel complesso stiamo creando un altro asset. Questo è il motivo per cui le classi AVComposition e AVMutableComposition sono sottoclassi della classe  AVAsset base.
È possibile aggiungere contenuti multimediali all’interno di una composizione mutevole, semplicemente selezionando un segmento di un bene, e l’aggiunta di una gamma specifica di nuova composizione:

- (BOOL)insertTimeRange:(CMTimeRange)timeRange ofAsset:(AVAsset *)asset atTime:(CMTime)startTime error:(NSError **)outError

Nel nostro esempio abbiamo una serie di tracce che si desidera aggiungere una dopo l’altra per generare un insieme continuo di clip. Così il codice può essere semplicemente scritto in questo modo:

AVMutableComposition = [AVMutableComposition composition];
CMTime current = kCMTimeZero;
NSError *compositionError = nil;
for(AVAsset *asset in listOfMovies) {
BOOL result = [composition insertTimeRange:CMTimeRangeMake(kCMTimeZero, [asset duration])
ofAsset:asset
atTime:current
error:&compositionError];
if(!result) {
if(compositionError) {
// manage the composition error case
}
} else {
current = CMTimeAdd(current, [asset duration]);
}
}

Prima di tutto abbiamo introdotto il concetto di tempo. Si noti che tutti i media hanno un concetto di tempo diverso dal solito. Prima di tutto il tempo può muoversi avanti e indietro, oltre il lasso di tempo può essere superiore o inferiore a 1x se si sta visionndo il filmato al rallentatore o in avanzamento rapido. Inoltre si ritiene più conveniente  rappresentare il tempo non come virgola mobile o un numero intero, ma come numeri razionali. Per tale ragioneil framework  Core Media  fornisce la CMTimestructure e un insieme di funzioni e macro che semplificano la manipolazione di queste strutture. Quindi, al fine di costruire una specifica istanza time instance:

CMTime myTime = CMTimeMake(value,timescale);

che infatti specifica un numero di secondi proposto dal value/timescale. La ragione principale di questa scelta è che i film sono fatti di frames e i fotogrammi sono dati ad una razione fissa al secondo. Così, per esempio, se abbiamo una clip che è stata ripresa a 25 fps, allora sarebbe conveniente per rappresentare l’intervallo singolo fotogramma come un insieme variabile CMTime con valore = 1 e tempi = 25, corrispondente a 1/25th di secondo. 1 secondo  è dato da un CMTime con valore = 25 e timescale = 25, e così via (ovviamente si può ancora lavorare con i secondi, se volete, è sufficiente utilizzare i CMTimeMakeWithSeconds (seconds) function). Quindi, il codice di cui sopra inizialmente imposta l’ora corrente a 0 secondi (kCMTimeZero) quindi avvia l’iterazione su tutti i nostri film che sono assets in. Poi si aggiunge ciascuna di questi asset nella posizione corrente della nostra composizione con la loro gamma completa ([asset duration]). Per ogni asset spostiamo la composition head (current) per la lunghezza (in CMTime) dell’asset. A questo punto la composizione è fatta di un set completo di brani aggiunti in sequenza. Ora possiamo giocare.

Playing an asset

Il framework AVFoundation non offre alcuna player integrato, come siamo abituati a vedere con MPMovieViewController. Il motore che gestisce lo stato di riproduzione di un asset è fornito dalla classe AVPlayer. Questa classe si occupa di tutti gli aspetti relativi al play dell’asset ed essenzialmente è l’unica classe in AV Foundation che interagisce con i controller di visualizzazione dell’applicazione per mantenere in sincronia la logica dell’applicazione con lo stato di riproduzione: questo è rilevante per il tipo di applicazione che stiamo prendendo in considerazione in questo esempio, come lo stato di riproduzione può cambiare durante l’esecuzione del filmato base alle specifiche interazioni dell’utente  in momenti specifici all’interno del film. Tuttavia non abbiamo una relazione diretta tra AVAsset e AVPlayer, la loro connessione è mediata da un’altra classe denominata AVPlayerItem. Questa organizzazione delle classi ha lo scopo di separarel’asset, considerato come un’entità statica, dal player, puramente dinamico, fornendo un oggetto intermedio, che rappresenta uno stato specifico di presentazione di un asset. Ciò significa che per un determinat e unicoo asset  possiamo associare elementi di più players, tutti  rappresentano diversi stati dello stesso asset e eseguito da diversi players. Quindi, il flusso in questo caso è dato da un determinato asset che crea un elemento di player e poi lo assegna al pleyer finale.

AVPlayerItem *compositionPlayerItem = [AVPlayerItem playerItemWithAsset:composition];
AVPlayer *compositionPlayer = [AVPlayer playerWithPlayerItem:compositionPlayerItem];

Al fine di eseguire il rendering sullo schermo, dobbiamo fornire una view in grado di rendere lo stato attuale di player. Abbiamo già detto che iOS non offre on-the-shelf una vista per questo scopo, ma quello che offre è un livello speciale CoreAnimation chiamato AVPlayerLayer. Quindi è possibile inserire questo livello nella gerarchia a livello di Anteprima del player o, come nel seguente esempio, utilizziamo questo come livello di base per questa view. Quindi, l’approccio suggerito in tal caso è quello di creare un MovieViewer personalizzato e il  set AVPlayerLayeras base layer class:

// MovieViewer.h

#import <UIKit/UIKit.h>
#import <AVFoundation/AVFoundation.h>
@interface MovieViewer : UIView {
}
@property (nonatomic, retain) AVPlayer *player;
@end

// MovieViewer.m

@implementation MovieViewer
+ (Class)layerClass {
return [AVPlayerLayer class];
}
– (AVPlayer*)player {
return [(AVPlayerLayer *)[self layer] player];
}
– (void)setPlayer:(AVPlayer *)player {
[(AVPlayerLayer *)[self layer] setPlayer:player];
}
@end

// Intantiating MovieViewer in the scene view controller
// We suppose “viewer” has been loaded from a nib file
// MovieViewer *viewer
[viewer setPlayer:compositionPlayer];

A questo punto siamo in grado di riprodurre il filmato, che è abbastanza semplice:

[[view player] play];

Translated from Carlo’s post

iPhone5 ha uno schermo più grande rispetto ai suoi precedessori. Gli sviluppatori di iOS6 devono supportare risoluzioni di 640 x 1136 px al posto di 640 x 960 px dell’iPhone4.
Ma anche in questo caso se si segue la logica Apple il lavoro da fare non è per nulla complicato.

Il blog http://blog.mugunthkumar.com/coding/supporting-the-iphone-5/ propone di seguire quattro fasi:

Fase 1:

iPhone 5 richiede un nuovo set di istruzioni, le armv7s. Solo nell’ultima versione Xcode ( 4.5) supporta la generazione del set istruzioni armv7s. Doa notare che, Xcode 4,5 non supporta più armv6 e depreca iPhone 3G e i dispositivi più vecchi. Quindi bisogna ora sviluppare le nostre applicazione utilizzando Xcode 4,5

Fase 2:

Il passo successivo è quello di aggiungere una immagine di lancio (Default-568h@2x.png). Quando si genera il progetto con Xcode 4.5, viene visualizzato un avviso, “Missing Retina 4 launch image”. Fare clic su “Aggiungi” per aggiungere un immagine di default al progetto.

Al lancio dell’ app apparirà in full screen on iPhone 5

Fase 3:

Tuttavia, la maggior parte dei nib file non sarà ancora in scalata correttamente. Il passo successivo è quello di controllare la maschera ridimensionamento automatico (auto resizing mask) di tutti i file nib e assicurarsi che la vista (view) all’interno del file nib si dimensioni automaticamente in base alla nuova altezza della vista.

Le proprietà che si usano sono:

UIViewAutoresizingFlexibleTopMargin,
UIViewAutoresizingFlexibleBottomMargin,
UIViewAutoresizingFlexibleHeight.

Si utilizza la UIViewAutoresizingFlexibleHeight per la visualizzazione on top in modo che auto dimensioni con la finestra principale. Si utilizza il UIViewAutoresizingFlexibleTopMargin e / o UIViewAutoresizingFlexibleBottomMargin per subviews.

UIViewAutoresizingFlexibleTopMargin viene utilizzato se si desidera che la visualizzazione secondaria eimanga “inchiodata” alla parte inferiore (il margine superiore è flessibile) e UIViewAutoresizingFlexibleBottomMargin viene utilizzato se si desidera che la visualizzazione secondaria sia “inchiodata” alla parte superiore (iò margine inferiore è flessibile).

Se invece si utilizza Cocoa auto Layout, questo passaggio diventa facoltativo. Tuttavia, l’auto Layout non è supportato su iOS 5.

Fase 4:

Infine, qualsiasi Layer che avete aggiunto alla vista dovrà essere ridimensionato manualmente. Il codice seguente mostra come eseguire questa operazione. Usiamo patternLayer per aggiungere un pattern per tutti i view controller. È necessario ridimensionare  nel metodo viewWillLayoutSubviews.

-(void)viewWillLayoutSubviews {

self.patternLayer.frame = self.view.bounds;
[super viewWillLayoutSubviews];
}Step 5 (if you were a messy coder):

Fase 5

Se l’altezza della view è stata codificato  a 460 o 480, potrebbe essere necessario cambiarle tutte  iinsrendo bounds. Ad esempio,

self.window = [[UIWindow alloc] initWithFrame: [[mainScreen UIScreen] bounds]];

invece di

self.window = [[UIWindow alloc] initWithFrame: CGRectMake (0, 0, 320, 480)];

Creare immagini con le nuove dimensioni

Come ho potuto constatare sul blog http://redth.info/get-your-monotouch-apps-ready-for-iphone-5-ios-6-today/ , purtroppo, la convenzione di denominazione di immagini-568h @ 2x.png sembra solo di essere utilizzata per l’immagine di default, ma non viene applicata per le altre immagini dell’ applicazione. Ciò significa che se si sta utilizzando un’immagine di sfondo personalizzata per la visualizzazione (ad esempio: UITableView background), è probabile che sia necessario creare una nuova immagine di sfondo alla risoluzione corretta, e determinare nell’applicazione quando utilizzare ciascuna immagine.
Sarebbe bello se Apple avesse esteso nel nuovo SDK il supporto al nuovo schermo per mezzo del metodo:
[UIImage imageNamed:@"my-image"]
Attualmente possiamo indicare per “my-image” il nome della mia immagine (anche senza estensione) e il sistema operativo effettua la ricerca dell’immagine nell’application bundle secondo questo criterio: se lo schermo è di tipo retina cerca un’immagine con il suffisso @2x nel nome, se non la trova va a cercare l’immagine senza suffisso. Ci saremmo aspettati da parte di Apple l’estensione dell’algoritmo includendo la possibilità di cercare per il suffisso -568h@2x nel caso di schermo da 4″. Purtroppo non è così e per questo motivo dovremo codificare la cosa espressamente nel nostro codice.

Per esempio, nella nostra app non-4inch  compatibile, ho due immagini:

Images / TableViewBackground.png – 320×358
Images / TableViewBackground@2x.png – 640×716

Con la nuova risoluzione, ho bisogno di creare una terza immagine (abbiamo deciso di utilizzare l’opzione-568h @ 2x.png convenzione di denominazione, anche se non è processata da Apple):

Images/TableViewBackground-568h@2x.png

Un approccio elegante è quello di creare una nuova categoria per la classe UIImage (che definiamo con poca fantasia UIImage+Retina4), e effettuare a runtime all’interno della categoria una sostituzione del metodo “imageNamed:” con uno che gestisca la nuova convenzione:


// all'interno di UIImage+Retina4.h
#import

@interface UIImage (Retina4)

@end

// all’interno di UIImage+Retina4.m
#import “UIImage+Retina4.h”
#ifdef TARGET_MAC_OS
#import
#else
#import
#endif

static Method origImageNamedMethod = nil;

@implementation UIImage (Retina4)

+ (void)initialize {
origImageNamedMethod = class_getClassMethod(self, @selector(imageNamed:));
method_exchangeImplementations(origImageNamedMethod,
class_getClassMethod(self, @selector(retina4ImageNamed:)));
}

+ (UIImage *)retina4ImageNamed:(NSString *)imageName {
NSMutableString *imageNameMutable = [imageName mutableCopy];
NSRange retinaAtSymbol = [imageName rangeOfString:@"@"];
if (retinaAtSymbol.location != NSNotFound) {
[imageNameMutable insertString:@"-568h" atIndex:retinaAtSymbol.location];
} else {
CGFloat screenHeight = [UIScreen mainScreen].bounds.size.height;
if ([UIScreen mainScreen].scale == 2.f && screenHeight == 568.0f) {
NSRange dot = [imageName rangeOfString:@"."];
if (dot.location != NSNotFound) {
[imageNameMutable insertString:@"-568h@2x" atIndex:dot.location];
} else {
[imageNameMutable appendString:@"-568h@2x"];
}
}
}
NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageNameMutable ofType:@”png”];
if (imagePath) {
return [UIImage retina4ImageNamed:imageNameMutable];
} else {
return [UIImage retina4ImageNamed:imageName];
}
return nil;
}

@end

Quel che fa questo codice è in fase di inizializzazione sostituire l’implementazione di Apple di “imageNamed:” con la nostra “retina4ImageNamed:” (e viceversa). Nel momento stesso in cui il runtime chiama “imageNamed:” in realtà andrà a richiamare la nostra funzione che andrà a caricare l’immagine ottimizzata per lo schermo a 4″ a condizione che sia presente e che stiamo eseguendo l’app su un device con tale schermo (incluso il simulatore). Nel caso l’immagine non fosse presente o lo schermo fosse il tradizione 3.5″ allora verrebbe chiamata la funzione originale (rinominata a causa dello scambio iniziale).
Ovviamente questa implementazione non può essere usata nel caso il caricamento delle immagini avvenga esplicitamente per mezzo di chiamate del tipo
[UIImage imageWithContentsOfFile:...]
in cui il nome del file va costruito in maniera esplicita.

Recentemente in alcune app, abbiamo notevolmente diminuito le dimensioni del file IPA che inviamo ad Apple.
Sviluppando un’app con molti contenuti grafici siamo riusciti a ridurre di circa il 60% la dimensione del pacchetto da inviare ad Apple, il cosidetto bundle file.

Quando si sviluppa un’ universal  iPad / iPhone app e , sopratutto, se si vuole aggiungere il supporto per la visualizzazione retina per  il nuovo iPad 3 possiamo incombere i dimesioni del pacchetto piuttosto eccessive.
Molte app vengono pensata per avere una moltitudine textures a schermo intero , questo accade in quanto molti designers preferiscono illustrare al meglio le proprie idee. Tali immagini ,se pensate per iPad 3, alla dimesione di 2048 x 1536 e in formato PNG possono risultare molto pesanti. La conversione di alcune di queste immagini in formato JPEG farà risparmiare parecchio spazio.
E ‘un peccato che le jpeg non vengono caricate più rapidamente, ma alcuni PNG che possono essere anche maggiori du 10MB , quando vengono convertote in jpeg pesano circa ~ 200Kb.
Questo è  un buon primo passo, ma bisogna stare molto attenti a non deteriorare la qualità.

La conversione da png a jpg non basta: anche dopo aver convertito il maggior numero di grandi texture il peso del bundle IPA puo’ risultare ancora consistente.
Il nostro obiettivo è quello di essere quasi sempre sotto i 20 MB cosi’ che i vecchi dispositivi possano scaricare l’app anche senza il WiFi.

ImageOptim: Basterà lanciare al suo interno la singola immagine o anche un gruppo, e saranno immediatamente compressi senza ridurre la qualità . Si riduce in media di circa il 15–35 %

Leggendo tra i diversi siti ho trovato alcuni utili consigli nel blog di Sam Soffes (http://samsoff.es/posts/image-optimization-on-ios ) che in suo articolo consiglia l’utilizzo di  ImageOptim, un piccolo programma che ottimizza le immagini. Con questa app per Mac osx i flis vengono processato in modo da occupare meno spazio su disco e in modo che possano essere caricate più velocemente , attraverso l”uso de i migliori parametri di compressione provvedendo a rimuovere i commenti inutili e i profili colore. Il software gestisce PNG, JPEG e GIF animate.
ImageOptim integra perfettamente  i vari strumenti di ottimizzazione: PNGOUT, AdvPNG, pngcrush, esteso OptiPNG, jpegoptim, jpegrescan, jpegtran e Gifsicle.
Particolarmente adatto per la pubblicazione di immagini sul web (restringe facilmente le immagini  “salvate” per il Web in Photoshop) si è rivelto utile per creare applicazioni Mac e iPhone / iPad sempre più leggere.

Inoltre è possibile convertire molte immagini come PNG8;  in Photoshop, nel sezione File>Salva per Web  e’ possibile esportare come PNG8 invece di PNG24 quelle immagini che vanno bene come GIF. Anche se non supporta alpha variabile, è ideale per immagini semplici.
Sam considera  ImageOptim addirittura fantastico; processa le immagini attraverso una serie di strumenti comprimendo il più possibile e senza ridurre la qualità. Anche se avete salvato “for-web” tutte le immagini, ImageOptim è in grado di comprimere ancora oltre il 50%. Alcuni files hanno un incredibile riduzione sino al  90%.

Sam ha processato tutte le immagini attraverso ImageOptim per ben due volte. La seconda volta è stato in grado di comprimere alcune immagini ancora più in profondità.
E’ importante notare che tutto questo è fatto in compressione lossless.

E’ possibile di rendere le immagini ancora più leggere con ImageAlpha (dai creatori di ImageOptim). Si tratta di uno strumento che permette di creare immagini con alpha PNG8 variabile.
Ciò farà risparmiare molto spazio. Si tratta di un processo più manuale rispetto a ImageOptim, ma funziona bene per ingrandire le immagini con alpha che non hanno un molti colori.

Nota: Assicuratevi di disattivare l’ottimizzazione delle immagini Xcode o si annullerà tutto il vostro duro lavoro, quando crerete il vostro bundle.

Conclusione

Abbiamo sentito pareri contrastanti su questi prodotti. Alcuni sostengono di aver avuto problemi con questi strumenti, mentre altri sono pienamente soddisfatti.
Secondo la nostra esperienza tutto funziona abbastanza bene;
se state cercando di ridurre la dimensione dell’app (bundle), raccomandiamo quindi di utilizzare questi strumenti.

Per i piu’ esperti:
Se si desidera provare a fare una compressione ancora più elevata, potete provare ad utilizzare il fork di Scribd del AdvanceCOMP di John Englehart (il creatore di JSONKit);
si tratta di un prodotto un po troppo hardcore, ma si consiglia comunque -ai piu’ smanettoni- di fare un tentativo.

Di norma gli sviluppatori non sono guru del Photoshop e del design in generale e certamente odiano rifare il proprio lavoro per venir incontro alle esigenze degli esperti.
Così abbiamo deciso di segnalarvi una guida infographic pensata per i progettisti che intendono fare App per  iOS  e aiutarli spedire file corretti per lo sviluppatore.

Lo stile di infographic e’ quello di spiegare tutto con un’immagine, che vo proponiamo di seguito:

Innanzi tutto come vediamo nell’immagine e’ necessario ricordare le dimensioni dei differendi device di Apple.

Iphone e ipod touch fino alla terza generazione: 320 x 480 px / 163 PPI
Iphone4 e ipod tpuch di ultima generazione: 640 x 960 px / 326 PPI
iPad & iPad2 : 1024 x 768 px / 132 PPI
iPad 3 : 2048 x 1536 px / 264 PPI

Apple raccomanda di utilizare icone:

44×44 px per i bottoni di controllo

Un’altro suggerimento e’ quello di preparare le icone partendo da dimensioni 512 x 512 px e 1024×1024 px nel caso di iPad con retina display, facendo sempre attenzione a visonare il design quando queste vengono rimpicciolite.

Il resto dei suggerimenti sono molto piu’ chiari se leggete con attenzione cio’ che e’ segnalato nell’immagine postata sopra.

FONTE:   un post infographic, ovvero Tutto riassunto da un’immagine,   inserito nel blog FSM (http://www.funkyspacemonkey.com/ios-app-designers-guide-infographic)

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 ingegnieri, 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 ingegniere 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.

Sempre più spesso i nostri clienti e lettori inviano delle proposte per lo sviluppo App senza utilizzare uno standard documentale e senza utilizzare quelle terminologie che possano aiutare  a comprendere correttamente quanti e quali funzionalità l’app proposta dovrebbe possedere.

Se volete trasmettere un’idea che permetta di creare un’app per iPhone, iPad o Android  è necessario preparare un vero e proprio Mockapp e/o Documento Funzionale nel quale verranno dettagliate tutte le funzionalità della vostra app per iPhone o iPAd o Android unitamente ad un layout che faccia comprendere la User Interface e la User Experience.

Cooker App – Design, Mockup e Prototype Apps interfacce app su iPhone

Qualora vogliate utilizzare il vostro iPad come strumento per preparare il mockapp prototipale, vi segnalo App Cooker (sito web: http://www.appcooker.com/).

Segnaleremo invece nel prossimo articolo sull’argomento quale sono gli strumenti che potrete utilizzare  con il vostro Mac o Pc.

Molte persone hanno abbamdonato quasi del tutto l’uso del computer e si affidano all’iPad per inviare email, fruire dell’Internet e utilizzare strumenti di lavoro;

App Coocker è un’app per iPad e la consideriamo uno strumento utilissimo , se volete portare le vostre idee ad uno stadio di possibile realizzazione.

App Cooker, è attualmente  presente in App Store al prezzo di 15,99 € , che secondo alcuni rumors aumenterà a 24$ alla prossima versione;   l’applicazione (per iPad) è sviluppata da HotAppsFactory e , come abbiamo detto, serve  a progettare applicazioni per iPhone e iPad..

L’ App Board raccoglierà i vostri piani concettuali, mock-up, icone, Scheda Negozio App e la strategia dei prezzi.
Sarà la spina dorsale di ogni vostro progetto e permette di lavorare in modo organizzato e chiaro.

Di seguito il video in lingua inglese direttamente dal sito ufficiale:

Definire le idee

Iniziamo con un’idea, uno schizzo e utilizziamo questa l’App per organizzare e ispirare le idee.
L’idea è l’essenza stessa di una qualsiasi applicazione e richiede momenti si riflessione e di attenzione.
App Cooker fornisce uno strumento dedicato per questo, fornendo preziosi consigli raccolti da Apple e da altri professionisti del settore.

iOS Mockups

Il motore di mockup supporta l’orientamento , semplici link e unisce assime la  UI di Apple(interfaccia utente) con disegni bitmap, forme vettoriali, testo e immagini.
I prototipi possono prendere vita, senza una sola riga di codice.

L’ Icona marchio di fabbrica dell’App

L’icona è il volto della vostra applicazione. La creazione di grandi icone richiede sperimentazione e diversi tentativi fino a quando la soluzione ideale non sarà trovata. Utilizzando i tool a mano libera, con forme vettoriali o immagini potrete definire l’aspetto delle icone delle vostre idee e vedere i risultati nelle varie dimensioni e in poco tempo.

Strumento Prezzi
App Cooker consente di confrontare un gran numero di scenari di prezzo per trovare il  giusto modello per la vostra applicazione. Supporta sia gli acquisti app che la pubblicità, il che rende facile prevedere ricavi, costi e profitti.

Descrizioni App Store

La descrizione sul prodotto pagina di iTunes è un fattore decisivo per i potenziali acquirenti. App Cooker rende lo scrivere queste informazioni un compito semplice, e fornisce un luogo per localizzare in uno qualsiasi dei App Store di 18 lingue.

Mock-up prima dello sviluppo di codice

Progettare una buona applicazione è difficile. Si deve possedere  creatività, il talento, le risorse, la conoscenza, il tempo e un forte senso di autocritica; le app di successo sono sempre il risultato di un lungo processo di raffinazione.

Abbiamo speso tantissimo tempo, con i tanti clienti e le diverse aziende che ci contattano, per cercare di spiegare il modo migliore di progettare applicazioni per iPhone , iPad e Android.

Con il tempo prima o poi tutti scoprono che la progettazione di un applicazione è molto più che solo il design grafico.

Di seguito vi enuncio  i 10 Principi che ho raccolto dal sito di App cooker:

1) Definire l’idea con precisione

2) Soddisfare le esigenze degli utenti

3) Descrivere un’ importante Interfaccia Utente e Esperienza Utente

4) Utilizzare Grafica sofisticata

5) Iterare per raggiungere la perfezione

6) Essere semplici ma eleganti

7) Un  Icona pulita e “chiara”

8) Parlare a tono basso ma chiaramente

9) Stabilire un prezzo onestamente

10) Pensare Mobile e Tattile

Per concludere,

App Cooker si configura come una applicazione professionale, in quanto permette di progettare tutti gli elementi di una applicazione compatibile con tutti i dispositivi Apple iOS.

Rivolgendosi a tutti coloro i quali hanno intenzione di far sviluppare una propria applicazione,  innanzitutto si dovrà mettere in chiaro l’idea iniziale, la compatibilità con i vari dispositivi e le varie funzionalità, successivamente bisognerà creare i vari elementi grafici del mockup, l’icona, la localizzazione sull’App Store e le prospettive di diffusione e di guadagno.