Undolog.com

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!

Continua...

<a target="_blank" href="http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/func/NSLog">NSLog()</a> è una funzione utilissima durante le fasi iniziali di un progetto, per il testing e il debug di un’applicazione per Apple iPhone o, più in generale, in ambiente XCode. Essendo appunto una funzione, esattamente come le altre, la sua presenza si farà sentire anche quando rilasceremo (release) il nostro eseguibile. Diventa quindi necessario rimuovere, in qualche modo, tutte le righe di NSLog() dal nostro codice, sia perchè non più necessarie, sia perchè le chiamate a NSLog() potrebbero influire sulle performance della nostra applicazione, soprattutto se abbiamo inserito NSLog() all’interno di loop.

Escludiamo subito la soluzione del “cerca” ed “elimina”; perchè un domani ci potrebbero servire nuovamente. Escludiamo anche la soluzione del “cerca” e “commenta”, scomoda per lo stesso motivo di prima. Fortunatamente una soluzione pulita, semplice e corretta la troviamo sfruttando le istruzioni condizionali del compilatore. Quello che faremo, in pratica, e dire al compilatore di escludere – se si verifica una determinata condizione – durante la compilazione del nostro sorgente le righe che contengono NSLog().

Le direttive di compilazioni e le istruzioni condizionali del compilatore, sono uno strumento molto potente e diffuso. Chi proviene dallo sviluppo ANSI-C le conosce sicuramente molto bene e le avrà utilizzte in moltissime situazioni. La particolarità di queste “istruzioni” risiede nel fatto, sopra accennato, di essere viste dal compilatore e non dall’eseguibile. Questa loro caratteristica le rende utili in moltissimi casi e permette di risolvere problematiche altrimenti assai fastidiose.

Vediamo subito un esempio di codice che, come preannunciato, permette di “eliminare” dalla compilazione parti di codice, nel nostro caso NSLog():

Le istruzioni condizionali del compilatore fanno parte della stessa famiglia della #define; anch’esse, infatti, sono precedute dal carattere “cancelletto” (#). Nell’esempio mostrato abbiamo definito una costante ACTIVE_NSLOG; le successive righe di codice dicono al compilatore di “includere” la riga NSLog() solo se ACTIVE_NSLOG è definito. Se abbiamo avuto la cura, durante la stesura del nostro codice, di inserire le chiamate a NSLog() all’interno del blocco #ifdef ... #endif, basterà eliminare la definizione della costante ACTIVE_NSLOG per far sparire, alla prossima compilazione, tutti i nostri NSLog().

Una soluzione migliore e definitiva

Vediamo adesso come impostare l’ambiente XCode per migliorare ancor di più ciò che abbiamo fatto sopra! Prima di tutto scegliamo un nome di costante che useremo nei nostri progetti per escludere dalla compilazione NSLog(). Potete scegliere il nome che più vi piace, da DEBUG a MIO_DEBUG o quello che preferite. Aprite il vostro progetto, nuovo o vecchio. Inserite tutti gli NSLog() all’interno del blocco (o di un blocco):

Selezionate il file principale del vostro progetto, cliccate con il tasto destro e scegliete la voce Get Info.

Si aprira la finestra con le informazioni sul progetto:

Selezionate la scheda Build, verificate di essere in configurazione Debug (è questa la chicca), andate nella sezione User-Defined e aggiungete, tramite il bottone in basso a sinistra, un nuovo campo chiamato OTHER_CFLAGS. A questo assegnamoli il valore -DMIO_DEBUG=1. La sintassi è -D{mia define}=1.

Questa procedura ha due vantaggi:

1. Non dobbiamo inserire nel codice la #define MIO_DEBUG 1, ma lo facciamo tramite le informazioni sul progetto. Quindi, quando andremo a compilare la versione di rilascio (quella senza gli NSLog()) non dobbiamo ricordarci di eliminare la riga #define MIO_DEBUG 1
2. La costante è definita in relazione alla configurazione, nel nostro caso Debug. Quindi, passando alla configurazione di rilascio (release) la costante sarà assente e le righe con NSLog() non verranno compilate

Conclusioni

La procedura sopra descritta può essere utile in una moltidutine di altri casi che, con NSLog(), non hanno nulla a che fare. Le istruzioni condizionali del compilatore possono aiutarci in una vastissima gamma di contesti. Spesso sono utilizzate dai programmatori per determinare il tipo di sistema operativo, la versione, il target, la presenza di processori matematici, mantenendo uno stesso “identico” sorgente.

Per capirci, come esempio, possiamo utilizzre la nostra costante MIO_DEBUG anche per intervenire in altre zone del codice:

Per completare, ecco alcuni esempi e varianti:

Continua...

La nuova features delle revisioni di WordPress può essere controllata ed impostata tramite la define globale WP_POST_REVISION. La sua definizione può essere inserita nel file wp-config.php:

Continua...

Per alcuni sviluppatori basta sapere che esiste una nuova versione del loro pacchetto di sviluppo preferito per correre ad acquistare l’aggiornamento. Altri, e non a torto, mantengono una maggiore calma e "pretendono" di conoscere gli effettivi miglioramente della nuova versione prima di modificare le proprie abitudini. Nel caso di Adobe Flash CS3 non c’è molto da attendere, visto gli innumerevoli cambiamenti che ha subito il pacchetto da quando Macromedia è stata acquisita da Adobe.
Ecco, quindi, 10 semplici, ma importanti, motivi che, a mio personale parere, bastano per convincersi ad eseguire l’aggiornamento ad Adobe Flash CS3. Mi soffermerò, ovviamente, solo sulle caratteristiche che mi hanno colpito personalmente; questo non vuole essere un elenco esaustivo di tutte le numerose novità introdotte con la suite CS3, solo un volo radente per anticipare qualche features della versione CS3.

1. Installazione

L’installazione è gradevole e rapida, rispetto alle precedenti versioni. Si integra, tra l’altro, con tutti i prodotti Adobe (Dreamweaver CS3, Photoshop CS3 extended, ecc…) il che rende le operazioni di installazione/rimozione ed aggiornamento un vero piacere.

2. Compatibilità a ritroso

Una questione spesso sottovalutata, ma sempre tenuta in considerazione nella storia di Flash: la possibilità di gestire le precedenti versioni del prodotto. In Flash CS3 ci sono tutti gli strumenti sia per migrare che per manipolare le precedenti versioni dei nostri filmati. Troviamo questa possibilità sia nel debug (un debug separato per Actionscript 2.0 e Actionscript 3.0) sia in fase di compilazione del filmato. Scrivere da subito applicazioni Flash in Actionscript 3.0 potrebbe essere controproducente in determinati contesti. Se il vostro sito target ha un traffico notevole potrebbe capitare che molti utenti non hanno ancora installato le ultime versioni del Player Flash per il browser e quindi non vedrebbero il filmato. Tuttavia, come già detto, Flash CS3 permette di sviluppare applicazioni Flash mantendedo la compatibilità a ritroso e quindi non vedo in questo un grosso ostocalo nell’upgrade del prodotto.

3. Interfaccia grafica e IDE

L’IDE di Flash CS3 (come quella di Dreamweaver CS3) è stata rivisitata al meglio. I pannelli (vedi figura qui a sinistra), spesso scomodi nelle precedenti versioni, sono stati completamente ridisegnati e adesso il loro uso è notevolemente meno invasivo. Inoltre la possibilità di ridurre ad icona i pannelli (vedi figura qui a destra) è una vera trovata che rende l’interfaccia gradevole e funzionale. Quando un pannello si trova in modalità icona occupa molto meno spazio e con un semplice click è possibile aprire il pannello principale prima sempre visibile.
Tutta l’IDE, insomma, è stata rivista compresa la zona centrale con la finestra per l’editing grafico e del codice. Non vi segnalo tutti i cambiamenti altrimenti vi rovinerei la sorpresa…

Continua...