Nuovi pattern architetturali in arrivo su iOS?
Chiunque abbia sviluppato su iOS, dalla sua versione “preistorica” del 2008 chiamata ancora iPhone OS o prima ancora se si considera anche la piattaforma MacOS, sa perfettamente che Apple da sempre indica uno e un solo pattern architetturale per la costruzione di tutto lo strato UI delle app: MVC.
L’acronimo indica i tre elementi principali che determinano tale architettura:
• Model: il modello che rappresenta il dato da visualizzare e da modificare, sia esso proveniente da servizi web remoti, da un database locale o da altra fonte
• View: la vista, ciò che l’utente fisicamente vede a schermo e con cui può interagire, come bottoni, etichette, immagini…
• Controller: l’entità adibita a fare da ponte tra la vista e il modello; essa alimenta la vista col contenuto del modello, ne riceve gli eventi (pressione di un bottone) e modifica il modello secondo le opportune logiche (ad esempio, la variazione di un valore a seguito della scrittura in un campo di testo da parte dell’utente)
Tutti gli strumenti forniti da Apple si sono sempre conformati a questa visione architetturale, a cominciare dai mattoni fondamentali per costruire l’interfaccia grafica: i ViewController.
Come il nome indica chiaramente, tali elementi sono preposti al ruolo di Controller: gestione totale della Vista e manipolazione del Modello.
Pur essendo un ottimo pattern architetturale, soprattutto in ambiti poco complessi, l’MVC risulta spesso limitante sotto molti punti di vista: il ViewController si ritrova a gestire completamente sia l’interfaccia grafica che il dato, mischiando logiche di UI con logiche di business. Questa mancanza di separazione delle responsabilità porta inoltre a un proliferare di righe di codice, spesso non riutilizzabile e poco mantenibile: il famigerato Massive View Controller, spauracchio di tutti gli sviluppatori iOS.
La community dei developer nel tempo ha adottato e sponsorizzato molte varianti e architetture differenti per ovviare a questi problemi. Nell’ultimo WWDC, la conferenza che Apple tiene ogni anno per aggiornare gli sviluppatori sulle novità dell’ultima release del proprio sistema operativo mobile, Apple ha introdotto alcune interessanti novità che sembrano dare uno spiraglio di luce agli sviluppatori più “ enterprise”, che desiderano adottare soluzioni durature e gestibili nel tempo anche per applicazioni ad elevata complessità. Una su tutte: Combine.
Combine è un framework, un insieme di API che forniscono un meccanismo per processare valori nel tempo. Se la descrizione non sembra indicare qualcosa di particolarmente degno di nota, si pensi invece che Apple è andata a pescare a piene mani dai principi fondanti il Functional Reactive Programming, su cui si basano framework di terze parti attualmente molto diffusi per lo sviluppo su varie piattaforme, iOS compresa.
Chi lo conosce, non avrà difficoltà a riconoscerne gli elementi fondamentali, che si aggiungono alle già ampie abilità di programmazione funzionale di Swift.
Combine infatti è basato sul concetto di Publisher (una entità che “pubblica” valori nel tempo, in maniera asincrona) e Subscriber (una entità che si registra per la ricezione di una determinata informazione da un Publisher e viene attivata all’arrivo di un nuovo valore). Si possono creare catene di Publisher che manipolano il dato e lo ritrasmettono ai Subscriber interessati, così come creare dipendenze di Publisher per attendere la fine di più attività contemporanee o per eseguire più attività in serie facendo in modo che ognuno attenda l’esecuzione della precedente.
La maggior parte degli elementi dell’SDK Apple è già conforme a questo framework ed è già in grado di fornire l’output tramite Publisher (gli oggetti che gestiscono le chiamate di servizi web, i timer o il notification center, ad esempio). Il framework permette inoltre di creare i propri Publisher e Subscriber e di collegarli a piacimento, facilitando l’adozione di nuovi e più flessibili pattern architetturali come l’MVVM (Model – View – ViewModel) che separa la logica del dato (ViewModel) dalla logica dell’interfaccia (View, che in questa accezione comprende anche il ViewController). Grazie all’approccio reattivo, infatti, l’interfaccia della View può aggiornarsi in autonomia in risposta a una modifica del dato nel ViewModel.
Apple non ha dato il supporto ufficiale ad architetture “alternative”, ma i segnali di apertura non mancano: che abbia buttato il cuore oltre l’ostacolo?
Fonte: developer.apple.com