View-based application e ViewController – Guida Sviluppo App iOS

Dopo una breve parentesi sulla gestione della memoria, apriamo un nuovo progetto in Xcode e questa volta scegliamo, come template, View-based application (ho assegnato a questo nuovo progetto il nome "TutorialMrWebmaster").

Come possiamo vedere vengono generati due file

• TutorialMrWebmasterAppDelegate
• TutorialMrWebmasterViewController

entrmbi con i rispettivi file di intestazione.

Se andiamo ad aprire il file header del delegato vedremo che ci sono alcune novità rispetto a quanto visto precedentemente. Prima di tutto viene effettuata una dichiarazione della classe TutorialMrWebmasterViewController con la seguente linea di codice:

@class TutorialMrWebmasterViewController

Questa direttiva sta ad indicare al compilatore che la classe è definita da qualche parte all’interno del progetto senza importarla. Ma perchè non abbiamo usato il consueto #import? Perchè, per esempio, se avessimo avuto la necessità di importare nel viewcontroller il delegato, dato che le due classi si sarebbero incluse a vicenda, non l’avremo potuto fere. Nel nostro caso base, tuttavia, non sussistendo questo pericolo, al posto del costrutto sopra presentato avremo potuto tranquillamente utilizzare #import.

La seconda aggiunta che troviamo nel codice è la dichiarazione di un oggetto relativo al ViewController della classe.

TutorialMrWebmasterViewController *viewController;

con la rispettiva property.

Il ViewController

Prima di andare a vedere cosa contiene il ViewController, bisogna capire che cosa rappresenta. Facendo una traduzione letteraria della parola vediamo che questo oggetto non è altro che un "controllore della vista", questo oggetto, cioè, si preoccupaerà di gestire tutto ciò che accade alla vista, come per esempio la pressione di un bottone da parte di un utente. Ovviamente è possibile associare ad un ViewController la gestione di più viste. Dato che i dispositivi mobili hanno uno schermo molto più piccolo rispetto a quello di un computer, in molti casi è necessario utilizzare un ViewController che gestisce più viste per poter mostrare all’utente l’intero contenuto. In questo caso il ViewController dovrà gestire la gerarchia di view caricando e rimuovendo dalla window la view corretta. E’ buona norma, comunque, far gestire al ViewController un numero ristretto di view e magari creare più ViewController per generare un codice più leggibile e di più facile manutenzione. Per esempio, in un gioco si potrebbe pensare di creare un viewController per il menù e tanti ViewController quante sono le voci del menù (vedremo più avanti come fare): per esempio, ne avremo uno per il gioco vero e proprio, un altro per la pagina di opzioni, un’altro per il settaggio della lingua e così via.

Se apriamo il file di implementazione relativo al ViewController vedremo che sono presenti alcuni metodi che però sono commentati. E’ opportuno fare una rapida analisi sull’utilità dei metodi principali:

• initWithNibName: si può effettuare un override di questo metodo per effettuare dei setup dell’applicazione prima che venga caricata la vista. In questo metodo solitamente si inserisce la dichiarazione nella quale viene associato un delegato ad un controller.
• loadView: in questo metodo può essere inserito il codice relativo alla struttura della nostra view tutto tramite codice. E’ possibile creare una gerarchia di view o di altri elementi UI. Nelle applicazioni di esempio lavoreremo principalmente su questo metodo.
• viewDidLoad: in questo metodo andremo ad inserire il codice per aggiungere altri elementi dopo che è già stata caricata la view da un file .xib. Questo è un metodo molto utilizzato dato che solitamente si costruisce la struttura base della view con Interface Builder e poi vengono aggiunti alcuni elementi, per esempio dipendenti dallo statod dell’applicazione, direttamente via codice.
• shouldAutorotateToInterfaceOrientation: metodo nel quale si specifica se si vuole il resize della view nel caso in cui si ruoti il dispositivo da verticale ad orizzontale o viceversa.