Nel capitolo precedente abbiamo scritto tutto il codice necessario e fatto le opportune connessioni con Interface Builder per creare una sorta di "memoria" per le preferenze utente dell’applicazione. Andiamo adesso a commentare l’esecuzione della nostra applicazione.
Una volta cliccato su build and run il simulatore mostrerà, come interfaccia, i due bottoni per le lingue e nella label sarà presente il testo Nessuna preferenza. A questo punto andiamo a cliccare sul bottone della lingua inglese: come potremo vedere il contenuto della label non verrà aggiornato in quanto la lettura della preferenza viene eseguita solamente al lancio dell’applicazione. A questo punto è sufficiente cliccare una volta il tasto Home del simultatore per mettere in background l’applicazione. Clicchiamo nuovamente sul tasto Home per due volte facendo apparire la barra delle applicazione attive che sono in background; chiudiamo quella relativa alla nostra applicazione. Una volta chiusa, se rilanciamo l’applicazione, la schermata mostrata conterrà sempre i due bottoni, ma il contenuto della label risulta essere valorizzato con la stringa INGLESE.
Vale la pena spendere qualche minuto per sottolineare l’importanza del metodo syncronize. Quando ci troviamo a lavorare con una variabile di tipo NSUserDefault è come se lavorassimo con un comunissimo file di testo: è possibile, infatti, inserire del testo, cancellarlo e modificarlo. Come in un normale documento di testo, per rendere le modifiche effettuate permanenti, è necessario il salvataggio dei dati. Stessa cosa vale per l’NSUserDEfault dove dobbiamo utilizzare il metodo syncronize per rendere le modifiche apportate consistenti. Abbiamo sottolineato l’importanza di questo metodo in quanto spesso, per distrazione, il programmatore può ometterlo ed ovviamente l’applicazione si comporterà in un modo non voluto. L’individuazione di questo tipo d’errore, nel nostro caso l’omissione di una riga di codice, risulta molto difficile in quanto il compilatore non segnalerà nessun problema ma avremo un’applicazione che si comporta in maniera anomala.
Nella nostra applicazione di esempio abbiamo utilizzato NSUserDefault per salvare una stringa utilizzando il metodo setObject, ma se voglio salvare il valore di un intero o un booleano posso usare lo stesso metodo? La risposta, ovviamente, è no in quanto un intero o un boolenao non sono oggetti. E’ duqnue necessario utilizzare un metodo diverso, come per esempio setInteger:forKey: per gli interi oppure setBool:forKey: per un booleano. Ovviamente è necessario anche utilizzare metodi diversi per il get del dato: andremo ad usare integerForKey: per gli interi e boolForKey: per i booleani.
A questo punto può sorgere spontanea la domanda: ma esiste solo questo modo per poter salvare i dati? Ovviamente no, esistono molti altri metodi per il salvataggio permanente dei dati (per esempio attraverso l’uso di file .plist oppure utilizzando un database SQLite). L’utilizzo di NSUserDEfault è indicato quando i dati da salvare in maniera permanente non sono molti e dunque risulta perfetto per il salvataggio di preferenze dell’utente come la lingua da utilizzare, il volume della musica o il punteggio record in un gioco. Su set di dati molto grossi, come potrebbe essere l’elenco telefonico di una città, la struttura semplice di NSUserDefault incide sensibilmente sulle prestazioni, soprattutto quando si esegue una ricerca. Per set così grandi è necessario l’uso di un database che permette la normalizzazione delle tabelle e l’utilizzo degli indici rendendo la ricerca un’operazione estremamente veloce. Ovviamente un database SQLite ci offre alte prestazioni, tutto a scapito della facilità d’uso. Questo perchè se con NSUserDEfault bastava una linea di codice per salvare un dato e un’altra per recuperarlo, se si utilizza un database avremo la necessità di creare la tabella elencando tutti i suoi campi e il tipo di dato che andranno a contenere, effettuare le opportune connessioni tra tabelle e molto altro ancora.
