Lesson 7 - Alberto De Bortoli

iOS Lab for Devs
Developing Apps for iPhone and iPad
Lesson 7

UIGestureRecognizer
Le UIGestureRecognizer forniscono la possibilità di
aggiungere il riconoscimento di alcune gesture su
qualsiasi UIView.
E’ possibile creare dei nuovi UIGestureRecognizer
(tramite subclassing), ma di default esistono questi:
UIGestureRecognizer
• UITapGestureRecognizer
• UISwipeGestureRecognizer
• UIPinchGestureRecognizer
• UIRotationGestureRecognizer
• UIPanGestureRecognizer
• UILongPressGestureRecognizer

UIGestureRecognizer
La sintassi è la seguente:
UITapGestureRecognizer *tap = [[[UITapGestureRecognizer alloc]
initWithTarget:self
action:@selector(method:)]
autorelease];
[tap setNumberOfTouchesRequired:1];
[tap setNumberOfTapsRequired:1];
[myView addGestureRecognizer:tap];
Signature del selettore:
- (void)method:(UIGestureRecognizer *)recognizer;
La view alla quale viene aggiunta la gesture farà retain
della gesture stessa e si occuperà di rilasciarla nella
propria fase di dealloc (automatico).

UIGestureRecognizer
Esiste un protocollo per le UIGestureRecognizer che
definisce questi metodi opzionali:
- (BOOL)gestureRecognizerShouldBegin:(UIGestureRecognizer
*)gestureRecognizer;
- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer
shouldRecognizeSimultaneouslyWithGestureRecognizer:
(UIGestureRecognizer *)otherGestureRecognizer;
- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer
shouldReceiveTouch:(UITouch *)touch;

UIImagePickerController
L’UIImagePickerController è un view
controller che facilita l’accesso alle
immagini salvate nella galleria del
device e alla fotocamera.
Fornisce un’interfaccia predefinita da
Apple e un protocollo
UIImagePickerControllerDelegate.
E’ presentabile come un qualsiasi
altro UIViewController e bisogna
configurarne la proprietà sourceType.

Debugging techniques and
performance tuning

Premessa:
LLVM 3.0 è il compilatore di
nuova generazione adottato da
Apple.
E’ il default ed è
obbligatorio in
Xcode 4.2.
GCC deprecato.
Reference: llvm.org/
LLVM e GCC

Debugging techniques and
performance tuning
Vedremo concetti riguardanti:
• Breakpoints
• Stack trace
• Leaks
• Heap
• Memory Warnings
• Zombies objects
• SIGABRT and EXC_BAD_ACCESS exceptions
• objc_exception_throw breakpoint
• treats warnings as errors (direttiva di compilazione)
• Instruments
• CLANG static analyzer

Enable Zombie Objects 1/2
Quando un oggetto viene deallocato, viene cancellato dalla
memoria. In particolare con l’uso del messaggio autorelease,
l’oggetto viene rilasciato (e deallocato) in un tempo successivo a noi
sconosciuto. Se successivamente tentiamo di accedere all’oggetto,
l’applicazione crasha a causa di un dangling pointer.
In tal caso è estremamente comodo abilitare la modalità “oggetti
zombie”: quando un oggetto deve venire deallocato in realtà esso
viene marcato come “zombie” ma rimane in memoria. Al successivo
accesso (errato) possiamo dunque avere informazioni in console su
che tipo di oggetto era stato referenziato al posto di avere un log
pressoché inutile quale ‘message sent to deallocated instance’ che
non ci farebbe (neanche lontanamente) sapere su quale oggetto
stiamo gestendo la memoria in maniera errata.

Enable Zombie Objects 2/2

objc_exception_throw
breakpoint
In Objective-C non si usa spesso il try-catch e di solito le eccezioni
arrivano al main (senza mai essere catturate).
In tal caso (e senza il breakpoint objc_exception_throw abilitato) il
debugging è difficile e non si riesce a risalire allo statement scatenante
l’eccezione.
objc_exception_throw blocca l’esecuzione al momento del lancio
dell’eccezione.

CLANG static Analyzer
Rileva leak dovuti a una gestione scorretta di retain e release.

Analizzatore di performance:
• Memory allocations
• Leaks
• Network activity
• CPU usage
• ...
Tool disponibile con Xcode
Instruments

ARC 1/5
(Automatic Reference Counting)
*ARC è una killer feature. Punto.*
La gestione della memoria può essere ardua.
• I problemi portano a crash
• i crash causano stress
• lo stress causa il rifiuto dell’app dall’App Store
• il rifiuto dell’app dallo store causa stress
*** non ci piace lo stress ***
Programmare con le regole MRC (Manual Reference Counting, retain/release)
dovrebbe essere banale ma... ci sono molti dettagli... autorelease pools...
ARC formalizza le convenzioni e automatizza le regole.

Cosa fa ARC:
ARC 2/5
A compile time, il compilatore aggiunge retain/release/autorelease al posto del
programmatore.
Tali operazioni sono decidibili (matematicamente).

Cosa NON è ARC:
• No new runtime memory model
• No automation for malloc/free, etc.
• No garbage collector
• No heap scans
• No whole app pauses
• No non-deterministic releases
ARC 3/5
Cosa è ARC:
• Direttiva di compilazione (Project settings in Xcode)
• retain -> strong
• assign -> unsafe_unretained
• assign -> weak (per gli oggetti, set to nil automaticamente, no dangling
pointers)

ARC 4/5
Migrare codice esistente ad ARC
• Rimuovere tutte le chiamate a
retain, release, autorelease;
• Rimpiazzare
NSAutoreleasePool con
@autoreleasepool;
• @property(assign) diventano
@property(weak) per
puntatori a oggetti.

Pro
ARC 5/5
ARC
(automatic)
• no memory
management,
• gestione memoria
determinata a
compile time dal
compilatore
MRC
(manual)
• gestione memoria
determinata a
compile time
Cons ∅ • manuale, soggetta
a errori del
programmatore
Garbage
Collector
• no memory
management
• demone a runtime
(gestione
memoria eseguita
a runtime)