Uno dei vantaggi dei file Property list, che altro non sono che file testuali che seguono lo standard XML, è quello di poter essere trasformati istantaneamente in oggetti (come array o dictionary) Objective-C. Quando si crea un file Property list:

Uno dei vantaggi dei file Property list, che altro non sono che file testuali che seguono lo standard XML, è quello di poter essere trasformati istantaneamente in oggetti (come array o dictionary) Objective-C. Quando si crea un file Property list:

Se ci si trova a sviluppare in un ambiente dove è impossibile usare tool di debug come FireBug, come ad esempio il simulatore Apple iPad di Xcode, può diventare frustante individuare problemi, uno tra tutto l’errato accesso alle proprietà di un oggetto. Ecco che l’uso della funziona alert() diventa fondamentale!
Xcode 4 permette di sviluppare applicazioni per iPad o iPhone con target inferiore all’odierno iOS 4.3. Tuttavia lo stesso codice fornito con i template “pecca” di presunzione, dando per scontato che la nostra applicazione avrà come target iOS 4 o superiore. Nell’application delegate, ad esempio, Xcode inserisce le seguenti righe di codice:
1 2 3 4 5 6 7 | - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // Override point for customization after application launch. self.window.rootViewController = self.viewController; [self.window makeKeyAndVisible]; return YES; } |
A completare l’articolo How to: custom fonts su iOS 3.2 vi propongo i sorgenti di FontsBook, una semplice applicazione iPhone che mostra in una tabella tutti i font di sistema, raggruppati per famiglia.



Con la release 3.2 di iOS è possibile includere nelle risorse di un’applicazione propri font, da usare esatamente come quelli di forniti di sistema:
Applications that want to use custom fonts can now include those fonts in their application bundle and register those fonts with the system by including the
UIAppFontskey in theirInfo.plistfile. The value of this key is an array of strings identifying the font files in the application’s bundle. When the system sees the key, it loads the specified fonts and makes them available to the application.
Quando non si lavora più da soli per tutti gli sviluppatori arriva il momento di trovare delle linee guida nella scrittura del codice. Protocolli e standard che permettano di “leggere” facilmente ed intervenire (sempre facilmente) nel codice altrui.
Quando su un progetto ci lavorano più programmatori, spesso su linguaggi diversi, è obbligatorio trovare una forma comune di scrittura, di standard nella documentazione interna ed esterna al codice. Nel mio lavoro mi trovo normalmente ad interagire con:
Il simulatore iPhone/iPad in Xcode permette di simulare il doppio tap con la pressione del tasto ALT. Questo è utile per simulare anche la funzione di Pinch, quella usata per ingrandire o allontare contenuti nelle view con scroll o in oggetti UIWebView. Ebbene, alcuni di voi avranno notato che la simulazione delle “due dita” procede in modo simmetrico partendo sempre dal centro dello schermo. Per muovere questo “centro” è sufficiente tenere premuto anche il tasto SHIFT.
Come molti programmatori usano fare, anch’io mi costruisco le mie librerie di funzioni pronte per essere riutilizzate in più progetti e in più contesti. Lasciatemi passare il titolo di questo post, forse un po’ azzardato ma, tuttavia, come vedremo, non lontano dalla realtà.
In Objective-C è possibile scrivere e chiamare codice C/C++, compreso l’assembly se è per questo. Questa sua caratteristica lo rende un linguaggio davvero versatile e, per certi aspetti, fenomenale. Da un lato, infatti, è possibile utilizzare e apprezzare la sintassi prettamente Objective-C, dall’altro è possibile eseguire velocemente porting di codice scritto in ANSI C (magari per Digital Unix o Sun) e utilizzarlo comodamente nelle nostre applicazioni iPhone o iPad; per non parlare di tutto il Kernel BSD già disponibile su Mac OS X!
Per comporre email all’interno di una applicazione iPhone/iPod è sufficiente aggiungere il framework MessageUI. Nel nostro controller inserire l’inclusione del framework e adottare il protocolo MFMailComposeViewControllerDelegate:
Su Apple iPhone e iPod eravamo abituati a gestire un solo file immagine al caricamento dell’applicazione, il file Default.png. Su Apple iPad, invece, la diversa gestione dell’orientamente impone l’adozione di più file immagine, per essere certi di visualizzare lo splash screen corretto in base all’orientamente del dispositivo. Durante l’avvio dell’applicazione, come accadeva per iPhone, non è infatti possibile intervenire da codice per “chiedersi” com’è orientato il dispositivo. Fortunatamente è stato introdotto in automatico il caricamento di speciali file a seconda dell’orientamento:

I file attualmente supportati, oltre al classico Default.png che sconsiglio di utilizzare in quanto viene ridimensionato e deformato in base all’orientamento, sono:
Le versioni PortraitUpsideDown, LandscapeLeft e LandscapeRight possono essere utilizzate per determinare orietamento e verso di quest’ultimo.
Ad applicazione avviata, poi, come consigliato da Apple, è bene “ridisegnare” – ove necessario – le nostre viste agendo all’interno di application:didFinishLaunchingWithOptions.
Ultimi Commenti
Giovambattista Fazioli: @ale: Come indicato @Kevin vedi sul repo di GitHub: https://github.com/gfazioli/Ch roma-Key
Giovambattista Fazioli: @Kevin: See https://github.com/gfazioli/Ch roma-Key
Kevin: Very nice example – would like to see the .fla too!
Ludovica: Ciao! Ti spiego il mio dubbio. Quando scrivo un post non inserisco immagini nell’articolo (se così...
Marco: ciao @Giovambattista Fazioli, grazie per tutte le delucidazioni di questa ottima guida. Avrei un quesito da...