Debug di applicazioni Android

Identificare e correggere qualche errore di sintassi durante lo sviluppo di un'app Android è un processo notevolmente facilitato da Android Studio, che oltre a segnalarlo ci suggerisce anche alcune soluzioni al problema. Il difficile è, come in altre
tecnologie di programmazione, capire gli errori di funzionamento o scoprire perché un'app si comporta in modo indesiderato. In genere non possiamo fare affidamento ai messaggi visualizzati sul dispositivo, spesso troppo generici:

Il programmatore deve perciò dotarsi di strumenti per la rilevazione e risoluzione di errori, e fortunatamente l'SDK di Android ed il nostro IDE ce ne forniscono diversi.

Logcat

Android SDK mette a disposizione uno strumento di log, denominato Logcat, che può essere consultato continuamente per monitorare l'esecuzione della nostra applicazione. Lo troviamo nel pannello Android Monitor di Android Studio e, precisamente, nella scheda denominata logcat:

Al suo interno troviamo molte righe di testo in un formato simile al seguente:

01-03 10:02:56.878 ..... I/ESEMPIO_DEBUG: Ho cliccato su Floating Action Button

Il messaggio si riferisce, quindi, a un log del 1° marzo (01-03), alle ore 10 e 2 minuti. Questa riga di log
è classificata con livello Info (informazione, identificabile dalla I prima del carattere /) ed ha un tag ESEMPIO_DEBUG ed un testo descrittivo dell'evento: Ho cliccato su Floating Action Button.

I log possono essere di diversi livelli, a seconda dell'importanza che vogliamo attribuirgli ed al periodo in cui stiamo utilizzando l'applicazione: se siamo in fase di sviluppo, ad esempio, di test o in funzionamento normale:

• verbose: l'informazione è di carattere puramente descrittivo del funzionamento dell'applicazione;
• debug: è un messaggio che serve ad analizzare punti critici dell'applicazione. Il suo ruolo è importante in fase di sviluppo;
• information: messaggio informativo;
• warning: rappresenta una situazione anomala, che non implica però un errore;
• error: segnalazione di errore.

I log possono essere prodotti in maniera personalizzata nel proprio codice Java tramite la classe Log, appartenente al package android.util. Essa offre un metodo statico per ognuno dei livelli sopra menzionati: Log.v (verbose), Log.d (debug), Log.i (information), Log.w (warning), Log.e (error). I parametri che gli passeremo saranno due oggetti String: il primo rappresenta il tag (etichetta che ci permetterà di distinguere i messaggi nel flusso di log), e il secondo sarà il testo del messaggio.

Ad esempio, il messaggio di log visto prima è stato generato all'interno di un listener associato ad un click di un Floating Action Button:

FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
fab.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
Log.i("ESEMPIO_DEBUG", "Ho cliccato su Floating Action Button");
/* altro codice relativo al click del Floating Action Button */
}
});

I log possono essere consultati anche da riga di comando, specificando l'opzione logcat al programma adb:

adb logcat

Il programma adb si trova nella cartella dell'SDK di Android, precisamente nella directory platform-tools. Con adb potremo quindi consultare i log senza aprire Android Studio. Inoltre, potremo filtrare il log in base al tag, con l'opzione -s:

adb logcat -s "ESEMPIO_DEBUG"

Una volta aperta sul dispositivo la nostra app, ogni volta che selezioneremo il Floating Action Button verrà quindi prodotta una nuova riga di log.

Eccezioni Java

In Logcat, viene fornito anche l'output delle eccezioni Java, importante per verificare il nostro codice in fase di debugging. Immaginiamo di aggiungere un errore al codice visto precedentemente:

FloatingActionButton fab = null;
// La riga seguente genererà una NullPointerException
fab.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
/* codice relativo al click del Floating Action Button */
}
});

A causa dell'eccezione che sarà generata, Android Studio produrrà un messaggio di errore in Logcat:

Potremo quindi capire lo stack di chiamate che hanno causato il verificarsi dell'eccezione. Osservando l'output si può notare una porzione di messaggi che si riferiscono a parti di codice che non abbiamo scritto noi (rettangolo verde) ed una che si riferisce proprio alla nostra MainActivity (rettangolo azzurro). In particolare ci viene detto che l'errore è stato riscontrato alla riga 22. Possiamo cliccare sul link MainActivity:22 per essere riportati alla porzione di codice "incriminata".

A questo punto non resta che utilizzare il debugger, strumento assolutamente fondamentale proprio per la ristrettezza di informazioni prodotte dai dispositivi.

Per verificare che non ci siano errori nell'esecuzione del codice, effettuando quindi il debugging dell'app, possiamo inserire uno o più breakpoint nel codice, cliccando sul bordo sinistro dell'editor di codice di Android Studio: in questo punto verrà mostrato un pallino rosso.

Fatto ciò possiamo avviare il debugger cliccando sul pulsante a forma di insetto.

Quando l'esecuzione raggiungerà la riga in cui abbiamo posto il breakpoint, essa verrà bloccata - pur mantenendo l'app in esecuzione - e mostrerà nella finestra Variables i valori delle nostre variabili così come sono memorizzate in quel momento dell'esecuzione:

Nella finestra Variables possiamo notare che la variabile fab è impostata a null: avremmo potuto capire, quindi, a cosa potesse essere dovuta l'eccezione precedente. Con l'esperienza si potrà imparare a collocare i breakpoint nei punti più adatti. In questo caso, è stata scelta la riga di codice segnalata dall'eccezione, ma potremmo anche osservare il funzionamento dell'applicazione in diversi altri punti, in base alle nostre necessità. Potremo aggiungere tutti i breakpoint che riteniamo necessari, disattivandoli una volta soddisfatti dalle osservazioni. Quando il debugger si ferma ad una determinata riga, la evidenzia di blu (almeno nelle impostazioni standard di Android Studio); è bene sottolineare che le istruzioni in essa contenute non sono state ancora eseguite. Per poter eseguire la riga e passare alla successiva si dovranno utilizzare i comandi reperibili nel menu Run tra cui, il più immediato, Step over.