Il Pattern Model View Controller con il linguaggio Swift (Gratuita)

Vai al distributore di lattine della tua facoltà, inserisci 10 centesimi (sarebbe bello), premi un bottone ed il distributore ti restituisce la tua bella lattina di coca cola.

Aspetta perché questo non è un messaggio promozionale della bevanda, è l’applicazione di uno dei modi di programmare più utilizzato nello sviluppo delle applicazioni e non solo. Si chiama pattern Model View Controller e sarà un argomento cardine del corso di sviluppo applicazioni iOS.

Prima di analizzare il sistema è necessario partire da un problema esistenziale.

Chi sei oltre ad essere uno sviluppatore?

Prima di diventare un maestro di arti marziali sono stato, per molti anni, un allievo. Chi è allievo difficilmente riesce a capire le scelte che fa un maestro, bensì segue il suo maestro fin quando quest’ultimo gli fa piacere ciò che insegna. Mentre, chi è maestro, è necessariamente passato dallo stato di allievo e quindi conosce perfettamente ciò che potrebbe frullare nella mente dei suoi apprendisti.

Ma non voglio aprire un dibattito, volevo semplicemente arrivare al punto che, tu, prima d’essere uno sviluppatore, sei e continuerai ad essere un utilizzatore.

Ma cosa centra tutto ciò con lo sviluppo delle applicazioni?

Centra eccome!

Da utilizzatore sfrenato di applicazioni, una delle cose che ti aspetti, è che esse siano semplici da utilizzare. Per semplicità non mi riferisco solo ad una interfaccia intuitiva e minimale, bensì al sistema generale che ti permette, ad esempio, di premere un bottone e scattare una foto.

Questo è il punto. L’utilizzatore non vede mai cosa sta dietro ad un’applicazione, si limita ad interfacciarsi con un sistema semplicissimo che gli permette di fare delle operazioni, a volte, anche complicate.

Ecco perché sono partito dall’esempio del distributore di lattine.

L’utente o User quando si trova davanti al distributore si interfaccia con la sua plancia di comando e non, di certo, con il sistema di distribuzione che sta dentro la macchina. Queste sono scelte di progettazione che chi ha creato la macchina si è posto durante le fasi di sviluppo.

Infatti, l’ingegnere che ha sviluppato quella macchina si sarà posto questa domanda: “Come rendo semplice l’utilizzo di una macchina che all’interno ha un sistema complicato?

E tra le tante prove e tentativi sarà arrivato alla seguente conclusione: “Dato che il sistema complicato non può essere semplificato, io creo un nuovo livello che permette all’utente inesperto di comunicare con il sistema complicato“.

Quindi quel famoso ingegnere avrà sicuramente immaginato uno schema come il seguente:

interfaccia utente mvc

Se vogliamo rapportarlo all’esempio del distributore. Il sistema semplificato è la raggiera di bottoni che ti permette di scegliere la lattina. Mentre il sistema complicato è tutto il meccanismo che va a pescare la lattina nel corretto scompartimento.

Questo stesso principio, ovvero dividere in micro parti sistemi complicati, viene continuamente utilizzato anche nella realizzazione delle applicazioni e software moderni.

Le applicazioni sono composte da interfacce che puoi considerare come i bottoni presenti nel distributore di lattine. Dietro l’interfaccia dell’applicazione poi c’è un mondo oscuro che, da utilizzatore, non ti importa conoscere.

Ciò che importa, per l’utilizzatore, è il fine ultimo. Ovvero l’user si aspetterà sempre di trovare un sistema semplificativo che lo aiuta ad interfacciarsi con l’applicazione.

Ci sei fin qui?

Adesso puoi indossare il tuo abito da sviluppatore.

Quindi, se dividiamo l’interfaccia di un’applicazione dal codice complicato che ci sta dietro, otteniamo un sistema semplice che l’utente comune può utilizzare.

Dividere l’interfaccia, dal sistema che gli permette di funzionare, prende il nome di: Pattern Model View Controller.

  • Pattern: modo di programmare le cose. Sono delle linee guida che uno sviluppatore deve seguire per poter ottenere un risultato specifico. Un pattern lo hai già incontrato quando ti ho parlato delle funzioni: il pattern divide et impera.
  • Model View Controller: Modello, Vista e Controllore. Inutile che te lo spiego in due righe, continua con la lezione :P

Quindi quando qualcuno ti dice: “Ho sviluppato questa applicazione utilizzando il Pattern X”, ti sta dicendo che ha sviluppato l’applicazione seguendo le linee guida imposte dal sistema X.

Partiamo da un esempio pratico.

Quando utilizzi una qualsiasi applicazione e clicchi su un bottone, ti aspetti che quell’operazione che hai fatto ti restituisca un feedback. Ad esempio quando clicchi nella barra di ricerca del browser, inserisci del testo e premi invio, ti aspetti che venga restituito il risultato della ricerca. Premendo invio, non lo vedi, ma attivi degli algoritmi che cercano la tua informazione all’interno di un database. L’algoritmo trova ciò che ti serviva e te lo restituisce nella tua bella finestra del browser.

Quello che non sai è che il tuo browser sta utilizzando il pattern Model View Controller.

Intanto capiamo quali sono e cosa sono i tre componenti in gioco. L’interfaccia della tua applicazione prende il nome di View, il codice che sta dietro l’interfaccia e che ti permette di cercare le cose si chiama Controller, il database delle informazioni prende il nome di Model.

In generale, potrei dire che un sistema che rispetta il pattern Model View Controller deve essere obbligatoriamente composto da tre componenti:

  • View: o interfaccia, permette all’utente di eseguire delle operazioni grazie ad un sistema semplificato graficamente (bottoni, immagini, ecc.).
  • Controller: il codice che gestisce la View e comunica con il Model.
  • Model: il database delle informazioni o più in generale qualsiasi sistema di conservazione delle informazioni.

Quindi il sistema della distribuzione delle lattine potrebbe essere ristrutturato utilizzando il pattern MVC:

Il Pattern Model View Controller

Il Pattern Model View Controller applicato ad un’applicazione iOS con Swift.

Nella pratica di tutti i giorni, in cosa consiste il pattern Model View Controller?

Xcode e i template che utilizzi per sviluppare le applicazioni già nascono implementando il pattern Model View Controller. Apri il progetto della tua prima applicazione (quella che hai creato qualche lezione fa).

Ormai sai che esiste un file chiamato storyboard che rappresenta l’interfaccia della tua applicazione, un file AppDelegate che gestisce gli stati d’esecuzione della UIApplication e ce n’è un altro che, guarda caso, si chiama ViewController.

Scopriamo insieme come funziona.

Spostati nel Main.storyboard. Al centro c’è l’interfaccia dell’applicazione con i tre bottoni che hai inserito nelle precedenti lezioni:

View del pattern MVC in Swift

L’interfaccia rappresenta ciò che per il pattern MVC è la View.

Ovvero l’interfaccia che crei nello storyboard è il blocco esterno che viene presentato all’utente. Un po’ come la tastiera del distributore di lattine. Non credo ci siano dubbi su questo, infatti quando avvii l’applicazione è questa interfaccia che vedi nel simulatore e che vedrà l’utilizzatore. Quindi il principio che la View è la prima cosa che l’utilizzatore deve vedere è rispettato.

Per il pattern Model View Controller, sotto la tastiera del distributore di lattine, deve esserci un controllore che gestisce le interazione che l’utente esegue con la tastiera.

In questo caso, l’utente interagisce con l’interfaccia dell’applicazione premendo bottoni, utilizzando le gesture (i movimenti con le dita sullo schermo) e scrivendo.

Queste interazioni con la View, non vengono direttamente gestite dall’interfaccia bensì, come definito dal pattern MVC, devono essere gestite da un oggetto intermedio chiamato Controller.

Chi è che controlla la View?

Secondo il Pattern Model View Controller, dietro la View deve esserci un Controller che, nella programmazione di applicazioni è generalmente rappresentato da una classe.

Ad esempio nell’interfaccia sono presenti i bottoni, in futuro vedrai che questi bottoni vengono associati ad un codice presente nella classe del Controller. Così facendo quando cliccherai su quel bottone attiverai il controller che provvederà ad azionare il codice associato.

Ed infatti, ogni interfaccia dell’applicazione è collegata virtualmente ad una classe che le fa da Controller. Per vedere la classe collegata ad un’interfaccia basta vedere nel pannello Identity Inspector. Il primo blocco di informazioni è quello relativa alla custom class, ovvero la classe che fa da controller dell’interfaccia:

Controller associato ad un'interfaccia

Premendo sulla freccia accanto al nome della classe, verrai portato al codice della classe:

Quindi il file ViewController.swift, nello specifico la classe ViewController, svolge il compito del Controller per l’unica interfaccia presente nella nostra applicazione.

Da dove esce fuori? Ti ricordo che hai creato l’applicazione utilizzando il template Single View Application. Questo template, che è conforme al pattern Model View Controller, oltre ad aver inserito la prima interfaccia dell’applicazione, ha anche messo il controller che si occuperà di gestirne il comportamento.

La classe ViewController

Adesso sai che l’interfaccia che ti si para davanti, quando apri il simulatore, è controllata da una classe chiamata ViewController.

Analizziamo un po’ nel dettaglio la classe ViewController:

La classe ViewController è una subclass della classe UIViewController (User Interface View Controller). La classe UIViewController fa parte del framework UIKit ed infatti, sopra la definizione della classe, è presente l’import allo User Interface Kit.

La classe UIViewController, e quindi anche la figlia ViewController, ha il compito di amministrare le View o viste della tua applicazione iOS. Un View Controller gestisce, o può gestire, ogni singola porzione dell’interfaccia della tua applicazione (bottoni, immagini, ecc.).

É la responsabile del caricamento, sullo schermo, di ogni singolo elemento presente nell’interfaccia. Gestisce le interazioni dell’utente con l’interfaccia (come stabilito dal pattern Model View Controller) e coordina il caricamento dei dati presenti nel Model. Qui ad è esempio è dove inserirai il codice per gestire, ad esempio, cosa devono fare i bottoni quando verranno premuti.

La classe nasce di default con due metodi. Entrambi con override quindi vuol dire che sono stati ereditati dalla classe padre UIViewController.

Il didReceiveMemoryWarning è un metodo che non utilizzeremo in questo corso. Viene chiamato quando la memoria del sistema è talmente bassa che potrebbe chiudere la tua applicazione o svuotare delle risorse utilizzate.

L’altro metodo, il viewDidLoad, viene invocato quando l’interfaccia viene caricata in memoria, quindi qualche istante prima di essere visualizzata sullo schermo. Dato che stiamo parlando della prima interfaccia visualizzata dall’applicazione, il viewDidLoad viene chiamato quando la UIApplication sta finendo il suo ciclo di caricamento (guarda la lezione precedente).

Infatti se inserisci un print al suo interno, noterai che verrà stampato un messaggio dopo che l’inizializzazione della UIApplication è terminata:

L’utilizzo della classe lo vedrai nel dettaglio nelle prossime lezioni. Per adesso sai che è per via del pattern Model View Controller che c’è quel file ViewController.swift.

Concentriamoci sempre sul pattern MVC.

La comunicazione tra View, Controller e Model. Il concetto di messaggio ed evento.

Per prima cosa è necessario capire che i tre protagonisti del pattern Model View Controller, sono tre entità separate. Ovvero ogni personaggio è un oggetto a se stante.

Quindi la View è un oggetto per fatti suoi, come lo sono il Controller ed il Model. Per quanto riguarda il Controller è facile da intuire perché è presente una classe, figlia della UIViewController, che viene istanziata dalla UIApplication durante le fasi di caricamento dell’applicazione.

Mentre per la View e per il Model questo può essere meno intuitivo perché non sono presenti delle classi ad hoc.

In realtà la View o interfaccia che vedi nello storyboard è una semplificazione, o rappresentazione di un codice, che da qualche parte è presente all’interno di Xcode. Quindi il fatto che vedi un qualcosa di grafico non ti deve far pensare che sia effettivamente così. Sotto il file storyboard è presente un codice che viene gestito in automatico da Xcode. Ergo, anche l’interfaccia è un oggetto.

Il Model invece è qualcosa che creerai tu durante le fasi di sviluppo dell’applicazione. Può essere una classe, un array o un dizionario. In ogni caso verrà istanziato e sarà comunque un oggetto.

Premessa fatta!

Adesso, se ci sono tre oggetti separati che cooperano tra loro per far funzionare un unico sistema, com’è che si mettono in contatto?

Quando clicchi sul bottone di un’applicazione, la View, genera un evento. Ovvero l’applicazione o UIApplication comunica al sistema che è successo qualcosa.

Un evento è come un allarme. L’applicazione, alla pressione del bottone dice: “Ehii!! Attenzione! Qualcuno ha premuto un bottone”.

A questo punto, l’applicazione, intercetta l’evento e lo invia sotto forma di messaggio al Controller della View, chiedendogli: “Per caso puoi gestire questo evento?”. Se il Controller è stato progettato per gestire l’evento, allora attiverà il rispettivo codice, altrimenti non succederà niente.

Ipotizziamo che deve succedere qualcosa. Ad esempio la pressione del bottone deve stampare sulla View il numero di appuntamenti rimasti.

Quindi il Controller intercetta l’evento “bottone premuto, carica gli appuntamenti” ed attiva il codice per il recupero degli ultimi appuntamenti. A questo punto il codice ha bisogno delle informazioni contenuto dal Model ed invia, a sua volta, un nuovo messaggio al Model chiedendogli di restituire il numero di appuntamenti rimasti. Se ipotizziamo il Model come un array, allora sta chiedendo all’array di restituire il numero di appuntamenti rimasti, ad esempio, con un array.count – Il model non è per forza qualcosa di complicato come un Database:

Il pattern model view controller. L'invio di messaggi ed eventi

A questo punto il processo funziona a ritroso.

Il Model trova l’informazione richiesta dal Controller e la rispedisce indietro sotto forma di messaggio. Il Controller intercetta l’evento, quindi completa il precedente, ed invia l’informazione alla View. La View aggiorna la sua interfaccia e mostra all’utente il numero di appuntamenti rimasti.

Pattern MVC. Sistema di eventi e messaggi tra i componenti

L’importanza del pattern Model View Controller

Una delle cose importanti del pattern Model View Controller è che View e Model non si parlano mai. Infatti tra i due è sempre presente un Controller.

Un Controller è un intermediario. Immagina che ci sono due persone che hanno litigato. Una è la View e l’altra è il Model. Dato che entrambe non si vogliono parlare, entra in gioco il Controller che fa da ambasciatore tra le due persone coinvolte. In questo modo, quando la View avrà bisogno di un’informazione presente nel Model, lo comunicherà al Controller che provvederà a chiederla al Model.

Ora, ipotizziamo che tu voglia vendere una cipolla ad una persona. La cipolla è il tuo Model, il negozio di frutta e verdura il tuo Controller e la View il tuo acquirente.

Cosa succede se quell’acquirente non vuole acquistare la cipolla?

Te lo dico io!

Se l’acquirente non vuole acquistare la cipolla, ci sarà sicuramente qualcun altro a farlo. Quindi pur cambiando acquirente, ovvero View, la tua cipolla ed il tuo negozio rimangono invariati.

In generale quindi, un sistema di tipo Model View Controller è adattabile a più contesti differenti. Cioè, se in un altro progetto ti serve il Model utilizzato in un altro progetto, puoi esportarlo sicuramente perché sai che il suo unico scopo è quello di essere un Model. Alla stessa maniera se hai bisogno di una View o di un Controller.

Il fatto che gli oggetti del MVC siano specializzati, ovvero ognuno di essi ha un compito ben specifico, ti da la possibilità di poterli scorporare ed inserire in sistemi di altri progetti.

Per il momento sembreranno cose astruse, durante il corso noterai come moltissime applicazioni non sono altro che un rimaneggiamento di sistemi utilizzati in altre applicazioni.

Considerazioni

Tutto il mondo delle applicazioni gira intorno al pattern Model View Controller. Non c’è applicazione che non funzioni grazie al MVC.

Appena entrerai nel vivo della programmazione e sviluppo delle applicazioni, cioè dalla prossima lezione, inizierai ad apprezzare la bellezza di questo sistema.

Come gioco e come esercizio, prova a guardarti attorno. Cerca gli oggetti che funzionano mediante questo sistema, ti accorgerai che quasi tutti implementano il pattern Model View Controller.

Buona Programmazione!

Changelog

  • 18/10/2016 – Aggiunto il changelog e modifiche generali al testo per la compatibilità con Xcode 8.

Torna a: Corso creare applicazioni per iOS con il linguaggio Swift > Le Basi dello Sviluppo Applicazioni
  • Ferro

    Ciao Peppe, veramente ma veramente complimenti per il tuo metodo di esporre gli argomenti. Questo non è il primo corso online che seguo, e finora nessuno era andato in profondità e con questa chiarezza. Ora una domanda, imparerò ad utilizzare come Model un database esterno già collegato ad una web app? Grazie mille

    • Ciao Ferro,

      Grazie mille per il complimento! Sicuramente ci saranno altri corsi dove vanno più nel dettaglio tecnico delle varie questioni che tratto. Però sento (dato che ci sono passato anche io) che quello di utilizzare similitudini o argomentazioni un po’ più semplici è uno dei sistemi che vanno bene per chi si avvicina a questo settore. Poi magari più in là si va nel dettaglio, ma se non si comincia con qualcosa di semplice e comprensibile si finisce per non spingersi mai oltre…

      Per il resto, fino a qualche settimana fa avevo in mente di trattare nel dettaglio Parse.com. Oggi, con la notizia che lo chiuderanno nel 2017, credo che abbandonerò questo progetto a favore di iCloud e quindi del framework CloudKit.

      Parlerò di altre soluzioni integrate (Firebase, da poco acquisita da Google o Amazon server) in degli articoli sul blog e sicuramente più in là arriverà qualcosa riguardo il setting e la comunicazione con un proprio DB su macchina virtuale/dedicata.

      Grazie ancora per il complimento,
      Per qualsiasi problema rimangono a disposizione ;)

      • Ferro

        Ciao Peppe,
        ormai sei la mia guida!!!!
        Ho aggirato (o risolto) il problema della lettura di dati da un database esterno, prendendo ispirazione dal tutorial sul parsing JSON.
        Ora ho il problema di inviare dati tramite un JSON ad un url, ma spero di riuscirci prima o poi, a meno che tu non mi dia un input ;)
        Ovviamente un bel tutorial dei tuoi sarebbe il top!!!!
        Grazieeee

        • Ciao Ferro!!! grazie mille per il complimento.

          Il prossimo tutorial che ho in programma (dei gratuiti) è sul modello di revenue delle applicazioni. Il successivo è sulle inApp e magari come terzo gli metto la comunicazione con un server in entrata e uscita ;)

          • Ferro

            Li attendo tutti con grandissima ansia!!!!
            Grazie ancora

  • Alain Desitter

    prova

Start typing and press Enter to search

come funziona una applicazione iOS con linguaggio swiftaccount-page