{"id":8916,"date":"2012-05-18T16:02:35","date_gmt":"2012-05-18T14:02:35","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=8916"},"modified":"2012-05-22T16:01:11","modified_gmt":"2012-05-22T14:01:11","slug":"corso-di-sopravvivenza-ai-crash-come-fare-il-debug-delle-applicazioni-ios-iphone-e-ipad","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/corso-di-sopravvivenza-ai-crash-come-fare-il-debug-delle-applicazioni-ios-iphone-e-ipad\/","title":{"rendered":"Corso di sopravvivenza ai crash: come fare il debug delle applicazioni iOS (iPhone e iPad)"},"content":{"rendered":"

Bentrovati in questo breve articolo che illustra i principali strumenti per il debug delle nostre applicazioni per iOS.
\nNon credo di dover spiegare perch\u00e9 sia necessario fare il debug, quando scriviamo il codice siamo tutti convinti che sia corretto, poi proviamo l’applicazione e BANG… si chiude inaspettatamente…allora che fare? Mettersi seduti comodi e sereni e analizzare bene il codice che abbiamo scritto alla ricerca dell’errore. Senza tirare in ballo scuse come “Sar\u00e0 un bug del sistema operativo… del compilatore… della libreria” perch\u00e9, sebbene anche l\u00ec siano presenti dei bug \u00e8 molto (ma molto) pi\u00f9 probabile che il bug sia proprio nel codice che abbiamo scritto, che sembrava corretto, ma che invece non lo era affatto.<\/p>\n

Fortunatamente Apple ha messo a disposizione dei programmatori un nutrito set di strumenti utili per effettuare il debug delle applicazioni, e altri ancora sono invece utili per effettuare il tuning delle prestazioni. Quindi niente pi\u00f9 scuse e vediamo in dettaglio come scovare i bug nei nostri programmi.<\/p>\n

Per fare qualche esempio ho preparato un progetto davvero pieno di bug, potete scaricarlo da QUESTO indirizzo<\/a>.<\/p>\n

Scaricate quindi ed eseguite il progetto sul simulatore: si presenter\u00e0 con questa minacciosa tastiera il cui unico scopo \u00e8 quello di far andare in crash l’applicazione ogni volta in un modo diverso… da questo punto di vista potremmo dire che l’applicazione non ha BUG…perch\u00e9 fa proprio quello per cui \u00e8 stata pensata! \ud83d\ude42<\/p>\n

Primo bug<\/h4>\n

Una volta eseguito il progetto provate a cliccare sul primo pulsante, il pulsante “Unknow Selector” vedrete che l’applicazione \u00e8 andata in crash e vi verr\u00e0 mostrata questa schermata:<\/p>\n


\n\"debug-di-applicazioni-ios-iphone-ipad-01\"<\/a>
\n<\/center><\/p>\n

Guardiamo bene questa schermata, nella parte sinistra possiamo vedere la lista dei thread che erano in esecuzione al momento del crash, in questo caso erano 4 ed il primo (il cosiddetto “main thread”) \u00e8 andato in crash.<\/p>\n

Quello che si vede espandendo il simbolo del thread \u00e8 lo stack trace<\/strong>, viene mostrato in ordine lo stack del thread, con i nomi dei metodi e delle funzioni.<\/p>\n

Devo divagare per i meno esperti… Che cos’\u00e8 lo stack? Vi sarete resi conto che programmando si possono annidare chiamate di funzioni dentro altre, no? Ad esempio un codice come questo:<\/p>\n

\r\n[self.label setText:[NSString stringWithFormat:@\"%@ - %d\", [[stringa stringByTrimmingCharactersInSet: [NSCharacterSet whiteSpaceAndNewlineCharacterSet]];\r\n], 40 + 2]];\r\n<\/pre>\n
Come fa il computer ad eseguire questa operazione? Se provate a farla a mente vi renderete conto che procederete a step, partendo dal setTex: ma vi fermerete subito in quanto per eseguire il setText avrete bisogno del parametro, ma per calcolare il parametro dovrete calcolare stringWithFormat, per calcolare stringWithFormat vi servir\u00e0 calcolare 40 + 2,  stringByTrimmingCharactersInSet e whiteSpaceAndNewlineCharacterSet.<\/p>\n
Insomma, \u00e8 necessario quindi un meccanismo che permetta di lasciare in asso l’esecuzione di una funzione per eseguire un’altra il cui risultato serve alla prima operazione… questo problema i progettisti l’hanno risolto con lo stack.
\nLe operazioni vengono inserite in una pila (stack in inglese) e vengono rimosse appena vengono completate cos\u00ec che si possa passare alla operazione sottostante.
\nSemplificando, per l’operazione descritta precedentemente potremmo avere uno stack come questo:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-02\"<\/a>
\n<\/center><\/p>\n
Tornando quindi al nostro debugger, sulla sinistra vediamo lo stack delle chiamate, in questo caso le nostre chiamate non sono pi\u00f9 presenti perch\u00e9 sono termiante e vediamo solo le chiamate di sistema.
\nNella finestra principale dove solitamente scriviamo il codice vediamo che c’\u00e8 una riga evidenziata con il messaggio “Thread 1: signal SIGABRT<\/strong>” (vedi: http:\/\/en.wikipedia.org\/wiki\/SIGABRT<\/a>).<\/p>\n
Ma perch\u00e9 viene evidenziata questa riga e che nesso ha con il nostro bug?<\/p>\n
La riposta \u00e8 che poich\u00e9 l’eccezione non \u00e8 stata correttamente gestita da nessuna delle nostre classi allora \u00e8 risalita via via nella gerarchia ed \u00e8 arrivata al top e se anche l\u00ec nessuno la gestisce ecco che l’applicazione crassa.
\nVedremo nel prossimo esempio come gestire localmente un’eccezione in modo che non risalga e faccia crashare il programma.<\/p>\n
Nella parte bassa dello schermo vediamo la schermata che fornisce maggiori dettagli, vediamo infatti che LLDB (il debugger di XCode sostituto del buon vecchio GDB) ha stampato per noi alcuni messaggi, in particolare il secondo recita:<\/p>\n
*** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[UIRoundedRectButton setText:]: unrecognized selector sent to instance 0x6a32a40’<\/strong><\/p>\n
Ci sta dicendo, anche piuttosto chiaramente, che abbiamo provato a richiamare il metodo setText: su un oggetto di tipo UIRoundedRectButton che non ha affatto questo metodo e richiamare un metodo su un oggetto che non lo implementa \u00e8 un’eccezione che fa crashare il programma.<\/p>\n
Capita la causa non ci resta che risolvere il problema, e per risolvere il problema bisognerebbe trovare la riga di codice dove abbiamo richiamato il metodo setTex… cosa non facile su un progetto enorme.<\/p>\n
Dobbiamo trovare una soluzione per intercettare le eccezioni non appena queste vengono sollevate, senza attendere che arrivino in cima, in questo modo potremmo vedere la riga di codice che ha generato l’eccezione e non il file main.c<\/p>\n
Questo fortunatamente \u00e8 possibile farlo ed \u00e8 anche piuttosto semplice, dobbiamo aprire la scheda della gestione dei breakpoint:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-03\"<\/a>
\n<\/center><\/p>\n
Cliccare sul tasto “+” in basso a sinistra, quindi su “Add Exception Breakpoint”:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-04\"<\/a>
\n<\/center><\/p>\n
e infine su “done” assicurandosi di aver selezionato “All” per la voce Exception e “On Throw” per la voce Break. <\/p>\n
Cosa abbiamo fatto? In pratica abbiamo aggiunto un breakpoit, che sar\u00e0 attivato non appena viene sollevata un’eccezione. Ri-eseguiamo il codice e pigiamo sempre il primo bottone, vedremo questa schermata:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-05\"<\/a>
\n<\/center><\/p>\n
Ottimo, il debugger si \u00e8 proprio fermato nella riga di codice incriminata! Infatti notiamo subito che viene richiamato il metodo setText: sul sender, ma il sender \u00e8 un pulsante quindi il metodo corretto \u00e8 setTitle:forState:<\/strong><\/p>\n
Modifichiamo quindi il metodo in questo modo e rieseguiamo il codice, vedremo che l’errore sar\u00e0 sparito:<\/p>\n
\r\n- (IBAction)unknowSelectorErrorTest:(id)sender {\r\n    [sender setTitle:@\"Hello devApp\" forState:UIControlStateNormal];\r\n}\r\n<\/pre>\n
Come abbiamo detto c’\u00e8 un modo per evitare che l’eccezione risalga la gerarchia del nostro programma e lo porti al crash, come si pu\u00f2 fare?<\/p>\n
A voler approfondire l’argomento ci starebbe tutto un intero articolo (o pi\u00f9 di uno). \u00c8 gi\u00e0 tanta la teoria che sta dietro il design delle classi di un’applicazione e, se mettiamo in  conto anche cosa dovrebbe rendersi conto che una classe ha riscontrato un errore, la faccenda si complica ancora di pi\u00f9.<\/p>\n
Quello che dobbiamo fare \u00e8 in pratica dire al nostro programma “ehi, prova ad eseguire questo codice, se qualcosa va storto chiamami. Ah, poi quando finisci, in ogni caso, fai queste operazioni qui…” (si lo so che tendo ad antropomorfizzare i miei programmi… lasciatemi nella mia follia) ma come si fa?<\/p>\n
Semplicemente usando il costrutto:<\/p>\n
\r\n@try {\r\n        <#statements#>\r\n    }\r\n    @catch (NSException *exception) {\r\n        <#handler#>\r\n    }\r\n    @finally {\r\n        <#statements#>\r\n    }\r\n<\/pre>\n
Il primo blocco contiene le operazioni da eseguire e che sono potenzialmente dannose, il blocco @catch “cattura” l’errore che \u00e8 stato eventualmente sollevato dalle righe precedenti, infine il terzo blocco esegue delle istruzioni indipendentemente se ci siano stati o meno degli errori.<\/p>\n
Se provate a guardare il codice del metodo unknowSelectorErrorManaged<\/strong> vedrete che in pratica \u00e8 lo stesso codice “dannoso” del metodo precedente, ma stavolta pu\u00f2 essere eseguito senza far crashare l’intera applicazione perch\u00e9 viene gestito localmente:<\/p>\n
\r\n-(IBAction)unknowSelectorErrorManaged:(id)sender {\r\n    @try {\r\n        [sender setText:@\"Hello devAPP\"];\r\n    }\r\n    @catch (NSException *exception) {\r\n        NSLog(@\"oh snap! %@\", [exception description]);\r\n    }\r\n    @finally {\r\n        NSLog(@\"Operazione terminata\");\r\n    }\r\n}\r\n<\/pre>\n
Questo \u00e8 il messaggio di log:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-05b\"<\/a>
\n<\/center><\/p>\n
Secondo bug<\/h4>\n
Vediamo adesso come lo stack ci pu\u00f2 aiutare a trovare la fonte di un errore, eseguiamo il programma e clicchiamo sul terzo pulsante “Test stack”, il programma crasher\u00e0 e verr\u00e0 mostrata questa schermata:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-06\"<\/a>
\n<\/center><\/p>\n
Il programma si ferma (grazie al breakpoint) nella riga che ha scatenato l’errore ma se vogliamo avere maggiori informazioni ecco che questa volta ci viene in aiuto lo stack trace:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-07\"<\/a>
\n<\/center><\/p>\n
Si possono vedere le tre chiamate effettuate del nostro codice, l’ultima \u00e8 selezionata perch\u00e9 \u00e8 poprio l\u00ec che \u00e8 avvenuto l’errore.<\/p>\n
Cliccando sulle altre righe possiamo andare ad ispezionare il codice chiamante, cos\u00ec da renderci conto di qual \u00e8 lo stato attuale del programma e da dove arrivano i parametri che la nostra funzione sta usando.
\nIn questo caso ci rendiamo conto subito guardano il punto 3 che l’array che viene passato come parametro ha due sole voci, di conseguenza gli indici corretti sono 0 e 1 e non 1 e 2 come ho scritto… correggiamo l’immondo errore e verifichiamo che tutto sia corretto.<\/p>\n
Terzo bug<\/h4>\n
Passiamo adesso al terzo errore. Se clicchiamo sul pulsante “Breakpoint condizionale ()” vedremo che tra parentesi appare un numero progressivo che fa da conta-clik… per\u00f2 c’\u00e8 un problema: se proviamo a cliccare fino a 25 appare un numero stranissimo:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-08\"<\/a>
\n<\/center><\/p>\n
In questo caso non si tratta di un’eccezione, il programma continua a funzionare solo che non si comporta come dovrebbe. Non ci resta che piazzare un breakpoint all’interno del metodo richiamatto dal pulsante per verificare cosa succede.
\nPer piazzare un breakpoint clicchiamo nella barra di fianco al codice, nella riga in cui viene incrementata la variabile counter:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-09\"<\/a>
\n<\/center><\/p>\n
Cos\u00ec facendo l’esecuzione del programma viene bloccata ogni volta che si entra in quel metodo, ma questo pu\u00f2 non essere molto comodo, come in questo caso in cui saremo costretti a far bloccare l’esecuzione 24 volte prima di arrivare al momento in cui vogliamo capire che cosa succede. Clicchiamo allora con il desto sul breakpoint e scegliamo “Edit breakpoint”:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-10\"<\/a>
\n<\/center><\/p>\n
e aggiungiamo la condizione:<\/p>\n

\n\"debug-di-applicazioni-ios-iphone-ipad-11\"<\/a>
\n<\/center><\/p>\n
In questo modo il breakpoint sar\u00e0 attivo solo quando counter varr\u00e0 24 e avremo quindi sicuramente velocizzato tutta l’operazione.<\/p>\n
In particolare eseguendo il debug possiamo vedere che quando counter vale 24 entra in quel brutto if (! ((int)(counter) % (int)(100 \/ 20 * 5)) )<\/code> assegnando poi a counter il valore si sqrt(-1)… nel dubbio che quella riga sia stata scritta sotto l’effetto dell’alcol la cancelliamo e correggiamo il codice.<\/p>\n
Quarto bug?<\/h4>\n
Prima si salutarci lancio un test: nel programma c’\u00e8 ancora un bug<\/strong>, chi lo trova e lo risolve posti la sua idea nei commenti!<\/p>\n
Si conclude qui questo breve articolo sul debug con iOS, per qualsiasi domanda non esitate a chiedere sul nostro forum<\/a>.<\/p>\n
Alla prossima!
\nIgnazioc<\/p>\n","protected":false},"excerpt":{"rendered":"
Bentrovati in questo breve articolo che illustra i principali strumenti per il debug delle nostre applicazioni per…<\/p>\n","protected":false},"author":53,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[8],"tags":[1095,1099,1097,1096,1100,1098],"class_list":["post-8916","post","type-post","status-publish","format-standard","hentry","category-guide-varie","tag-debug-applicazioni-ios","tag-exception-xcode","tag-nsinvalidargumentexception","tag-signal-sigabrt","tag-stack-trace-ios","tag-usare-i-breakpoint-xcode"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/8916","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/comments?post=8916"}],"version-history":[{"count":22,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/8916\/revisions"}],"predecessor-version":[{"id":8983,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/8916\/revisions\/8983"}],"wp:attachment":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/media?parent=8916"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/categories?post=8916"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/tags?post=8916"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}