Sofapps · Blog

Liquid Glass vs Material 3: la fine della convergenza nel design mobile

2025-09-02T00:00:00Z

Il 2025 ha cambiato per sempre l’estetica del mondo mobile. Apple ha svelato Liquid Glass, un meta-materiale digitale che porta trasparenza, rifrazione e dinamismo a iOS, iPadOS e macOS.

Google ha risposto con Material 3 Expressive, evoluzione del Material You, fatta di colori audaci, tipografia variabile e animazioni elastiche.

Due visioni che non potrebbero essere più diverse. E che decretano la fine di un’era: quella della convergenza estetica.

Un passo indietro: quando le strade sembravano vicine

Per comprendere la portata di questa divergenza bisogna tornare indietro di oltre un decennio.

Con iOS 7 (2013), Apple archiviò definitivamente lo skeuomorfismo: addio texture di legno e pelle, spazio a tipografia sottile, superfici piatte e leggere trasparenze.

Solo un anno dopo Google presentò Material Design, un linguaggio basato sull’idea della “carta digitale” capace di muoversi e assumere profondità attraverso ombre ed elevazioni.

In quel momento le due strade sembravano correre parallele. Minimalismo, chiarezza e motion design erano valori condivisi, e per gli sviluppatori di terze parti appariva finalmente plausibile immaginare un’esperienza cross-platform coerente.

L’illusione della neutralità

La convergenza estetica di quegli anni aveva favorito strumenti come Flutter o React Native, in grado di proporre interfacce simili tra iOS e Android senza apparire fuori luogo.

Ma l’adozione non fu uniforme: su Android la frammentazione rallentò la diffusione di Material Design, mentre su iOS la rigidità delle guideline accelerò l’allineamento.

Liquid Glass: Apple punta al futuro sensoriale

Con Liquid Glass, Apple introduce un design che va oltre il minimalismo piatto: superfici tridimensionali, rifrazione della luce, trasparenze dinamiche.

È un’estetica che guarda chiaramente al futuro dello spatial computing e alla continuità con visionOS, creando un legame diretto tra smartphone, tablet, desktop e headset.

Un design sensoriale e quasi fisico, che scommette sul lungo periodo.

Material 3 Expressive: il presente di Google

Google, al contrario, evolve il suo linguaggio con Material 3 Expressive, che abbraccia una direzione più immediata e pop.

Colore saturo, tipografia variabile, animazioni elastiche: un’estetica che parla alla Generazione Z e che privilegia l’accessibilità e l’impatto visivo sul breve termine.

Non il futuro del metaverso o della realtà mista, ma un linguaggio vivo, quotidiano e inclusivo.

Conseguenze per sviluppatori e brand

Questa divergenza non è un semplice cambio estetico: per chi sviluppa applicazioni segna la fine della neutralità.

Le strade ora sono tre:

UI nativa con logica condivisa → massima fedeltà estetica alle linee guida di ciascun sistema.
Framework cross adattivi → skin e branching per rispettare le differenze di stile.
Approccio brand-first → sempre più scelto dai grandi player, che impongono un’identità sopra le regole dei sistemi operativi.

In altre parole, la sfida non è più scrivere una sola codebase, ma tradurre un design system in due dialetti diversi, senza perdere coerenza né usabilità.

Una nuova competizione estetica

Liquid Glass e Material 3 Expressive rappresentano due filosofie opposte:

Apple scommette sul futuro, con un’interfaccia sensoriale che prepara la strada allo spatial computing.

Google ottimizza il presente, puntando su accessibilità e vivacità per il pubblico di oggi.

Per gli utenti significa vivere esperienze sempre più caratterizzate dall’ecosistema scelto.

Per gli sviluppatori, significa fare scelte precise e inevitabili su come adattarsi o differenziarsi.

Il design, ancora una volta, non è solo estetica ma strategia competitiva.

YouTubeSi apre su YouTube. Non viene caricato nulla finché non fai clic.

— Happy coding! 🖖🏻

WWDC25: Benvenuto Liquid Glass

2025-06-23T00:00:00Z

Una delle innovazioni più interessanti presentate alla WWDC25 è senza dubbio il nuovo design system, unito a una rinnovata esperienza utente e a nuovi paradigmi d’interfaccia.

Parliamo di Liquid Glass, il nuovo sistema di design introdotto da Apple all’inizio di giugno, che unifica di fatto l’intero parco di sistemi operativi della casa di Cupertino in un unico paradigma visivo. L’obiettivo è assicurare una continuità e una fluidità senza precedenti tra iOS, macOS, iPadOS, watchOS, visionOS e anche tvOS.

Per comprendere appieno questo cambiamento, è utile fare un passo indietro nel tempo, fino al 2007, quando fu presentato il primo iPhone.

Gli inizi dello skeuomorfismo

Per dare vita a quel rivoluzionario dispositivo composto quasi interamente da uno schermo touch da circa 3.5”, Steve Jobs e il suo team optarono per un’interfaccia visiva basata sui principi dello skeuomorfismo. Fu una scelta voluta dallo stesso Jobs, convinto che fosse essenziale dare agli utenti la sensazione di interagire con oggetti familiari, ora finalmente “toccabili” con le dita. Lo skeuomorfismo, infatti, utilizza elementi grafici che imitano oggetti reali per risultare immediatamente comprensibili. La calcolatrice sembrava una calcolatrice fisica; il blocco note aveva le righe gialle di un vero taccuino; il calendario imitava un’agenda in pelle. Tutto studiato per rendere l’interazione il più naturale possibile.

All’epoca, nessuno aveva mai usato uno smartphone interamente touch: i dispositivi concorrenti, combinavano schermo e tasti fisici in un ibrido sgraziato. Jobs voleva qualcosa di radicalmente diverso e lo skeuomorfismo fu un’idea vincente. I pulsanti sembravano tridimensionali, con ombre e riflessi; tutto invitava al tocco. Niente stilo, niente tastiera fisica: solo tap, swipe e pinch.

Il termine skeuomorfismo deriva dal greco:

σκεῦος (skeuos) = strumento, contenitore
μορφή (morphē) = forma

In pratica: “oggetto che mantiene l’aspetto di un altro oggetto più antico o familiare, pur avendo una funzione diversa e moderna”.

Esempi analoghi si trovano anche nel mondo fisico: vasi in ceramica che imitano il metallo, colonne in cemento che ricordano il marmo, bottoni decorativi su giacche che non si aprono, ma richiamano chiusure reali.

Negli anni ’80, questo concetto fece il suo ingresso anche nel digitale: con l’avvento delle interfacce grafiche, si cercava un linguaggio visivo comprensibile per milioni di nuovi utenti. Apple fu tra le prime ad adottare questa filosofia: le icone a forma di cartella, il cestino, il Finder™ stesso sono esempi precoci di skeumorfismo. Questi elementi evolveranno, all’inizio degli anni 2000, nella celebre interfaccia AQUA di MacOSX.

Lo skeumorfismo, quindi, non nasce con l’iPhone, ma trova lì la sua massima espressione. Merito anche di Scott Forstall, sotto la supervisione di Jobs, che tra il 2007 ed il 2009 lo introdusse e ne completò la dimensione in iPhoneOS.

È opinione diffusa che il successo iniziale dell’iPhone sia stato dovuto, in buona parte, proprio a questa scelta visiva rivoluzionaria. L’interfaccia skeumorfica dominò per sei anni, durante i quali maturò e diventò un punto di riferimento anche per sviluppatori indipendenti, che in quel periodo affollavano l’App Store con applicazioni di altissima qualità.

L’avvento del minimalismo di Jony Ive

Nel 2013, con iOS7, Apple abbandona lo skeumorfismo e abbraccia un design piatto (flat), minimalista, firmato da Jony Ive. Tutto si fa bidimensionale, essenziale, a tratti persino monotono. L’interfaccia iniziale richiese vari aggiustamenti: contrasti deboli, elementi interattivi poco evidenti e colori troppo accesi. Ci vollero un paio d’anni prima che l’idea maturasse in un linguaggio coerente e apprezzato dagli utenti.

Apple non fu sola in questo percorso. Il design minimale trovò spazio anche altrove: prima con Microsoft e la sua (breve) avventura nel mobile, poi soprattutto con Google e il suo Material Design, che riprese i concetti di iOS7 e li ampliò. Proprio da Google, Apple riprese — nel tempo — molte idee per evolvere l’interfaccia, culminando con la piena maturità raggiunta in iOS 18, dodici anni dopo.

È tempo di cambiare

Diciotto anni dopo il debutto dell’iPhone, i dispositivi che abbiamo in tasca sono ormai veri e propri computer, con potenze di calcolo un tempo impensabili. Le interfacce minimali — per quanto arricchite da animazioni e transizioni — risultano oggi (troppo) semplici da gestire per hardware così avanzati.

Ecco perché la scelta di Apple, oggi, appare più che sensata: sacrificare una piccola parte di potenza per rendere le interfacce più vive, espressive e pronte alla realtà aumentata. È l’inizio di un nuovo ciclo.

Ma perché questa lunga premessa? Perché Liquid Glass rappresenta una rivoluzione comparabile a quella dello skeumorfismo. Ne riprende i concetti chiave, li rielabora e li incapsula in un nuovo materiale simbolico: il vetro.

Come ha spiegato Craig Federighi in un’intervista al Wall Street Journal, il vetro è il paradigma perfetto per descrivere un’interfaccia pensata per il computing spaziale e la realtà aumentata, basata sulla sovrapposizione di livelli (layers). Ma per rendere questi strati funzionali, serve un sistema coerente, leggibile e usabile sia su dispositivi touch che non touch.

Il vetro risponde a queste esigenze: trasparente, riflettente, fluido. Permette di vedere attraverso, ma anche di interagire con ciò che è in primo piano, mantenendo la continuità visiva dell’ambiente circostante.

Ci vorrà tempo perché questo concetto maturi appieno. Ma una cosa è certa: Apple ha scelto la direzione, e l’ha fatto con coerenza. L’autunno ci mostrerà i primi frutti concreti. Benvenuto, Liquid Glass.

— Happy coding! 🖖🏻

Dynamic Island: L'isola che non c'è ed il nuovo iPhone 14 Pro

2022-09-08T00:00:00Z

Un colpo di genio. Una mossa che nessuno si aspettava. Nemmeno i leakers più incalliti erano riusciti a cogliere l'essenza di quel buco magico che si vociferava, fino ad un paio d'ore prima, dovesse prendere una forma digitale non ben identificata.

Centinaia di parole e minuti spesi a parlarne. I disfattisti erano già pronti ad indicare la fine di Apple, che avrebbe perso il suo brand distintivo: il notch. Qualcun altro, più colto, si domandava se questa scelta non avesse portato a pericolose asimmetrie e difficoltà cognitive rispetto ai contenuti fruiti a schermo. Qualcun'altro giurava di avere le prove che quel notch sarebbe diventato una i di iPhone rovesciata in orizzontale.

Una cosa è certa. Nessuno è riuscito a togliere uno strabiliante effetto sorpresa a Tim Cook ed alla sua Apple.

Così, eccoci qui ad ammirare attoniti e senza parole l'ultimo colpo da maestro messo a segno da Apple nel suo evento di ieri 7 settembre 2022: L'isola dinamica o per dirla in inglese che forse rende meglio, la: Dynamic Island.

Un concetto che esprime chiaramente come il disegno di Apple si evolva negli anni secondo un copione preciso e senza mai andare a casaccio.

Nel 2017 (5 anni fa, ndr.) Apple annuncia al mondo il suo iPhone X, il primo dispositivo dotato di notch, una tacca posizionata al centro dello schermo in alto e destinata ad ospitare gli ingombranti sensori per il riconoscimento facciale e la telecamera frontale. La scelta è fortemente discussa e balza agli occhi della cronaca IT specializzata con un misto di assensi e dissensi, come sempre, aggiungerei.

All'epoca si parlava già di display OLED e l'iPhone X ne era dotato. Abbiamo visto altre 4 revisioni di questo notch passando per Xs, 11, 12 e 13. Nelle ultime revisioni ne è stata ridotta leggermente la dimensione ed in questi 5 anni è diventato un pò parte di noi: un'identità univoca del brand Apple e del dispositivo iPhone. Copiato in innumerevoli tentativi dalla concorrenza, ma mai eguagliato nella sua stupida ed assoluta semplicità.

Siamo nel 2022 ed i tempi sono maturi per andare oltre. Il display montato a bordo del nuovo iPhone 14 Pro ha un valore di contrasto di picco pari a 2.000.000 : 1 ed una resa dei neri pura come non mai.

E' il momento, insomma, di rendere creativi quei buchi sullo schermo che continuano a rimanere indispensabili per ospitare i sensori e le telecamere.

La tecnologia è ora pronta a trasformarsi in magia per dare all'utente la sensazione che quei buchi non siano un impedimento ma, al contrario, una feature per rendere più fluida ed indimenticabile l'esperienza a bordo del nuovo iPhone.

Mi viene da sorridere perché, anche in questo, trovo un'analogia con la filosofia dell'amato e compianto Steve Jobs che, tramutò un problema hardware a bordo degli iPhone 4 in una killer feature e dando vita al mercato delle cover e dei bumper.

Che dire? Il risultato di quest'isola dinamica fa sembrare di colpo tutto vecchio. Qualunque declinazione esistente del notch, sembra di colpo portarci indietro di ben oltre 5 anni dando un senso di vecchio a tutta l'esperienza a contorno.

Mi viene in mente uno spot Apple a me molto caro che, a mio parere, racchiude perfettamente il processo di ideazione e realizzazione di questo capolavoro di sinergia tra hardware e software.

YouTubeSi apre su YouTube. Non viene caricato nulla finché non fai clic.

C'è uno straparlare sul fatto che la Apple di oggi non sappia più innovare e che non ci sia molto altro da tirare fuori dai nostri smartphone. In parte è vero: siamo al confine di un'isola e, prima o poi, dovremo salpare per cercare altre terre.

Sapere innovare è anche questo: vedere all'orizzonte qualcosa che non c'è e trasformare questo qualcosa in un'isola reale e tangibile.

App Tracking Transparency con Combine

2021-05-04T00:00:00Z

Una delle funzionalità più pubblicizzate di iOS 14.5 è la nuova App Tracking Transparency. In giro ci sono moltissimi articoli che cercano di chiarire le posizioni in gioco in questa decisione di Apple e delle controparti come Facebook. Non voglio addentrarmi nell'aspetto politico della questione. Vorrei invece fare una rapida panoramica di ciò che serve per lavorare con questa novità e di cosa significa dal punto di vista tecnologico.

App Tracking Transparency si basa su un solo componente software, una classe chiamata ATTrackingManager.

Swift

class ATTrackingManager : NSObject

Secondo Apple questa classe offre tutto il necessario per chiedere il permesso e ottenere lo stato attuale della richiesta. Collabora con l'Ad framework per identificare gli utenti in forma anonima e consentire di tracciarne abitudini e interessi.

L'Ad framework ha un'istanza condivisa, disponibile in tutto il sistema, sotto forma di una classe chiamata ASIdentifierManager. Possiamo ottenerla nel modo classico:

Swift

ASIdentifierManager.shared()

Inoltre possiamo leggere l'identificatore anonimo corrente in modo altrettanto semplice:

Swift

ASIdentifierManager.shared().advertisingIdentifier

Prima di iOS 14.5 voi (sviluppatori) avevate sempre la possibilità di ottenere questo identificatore sotto forma di oggetto UUID. L'identificatore è anonimo e coerente in tutto il sistema operativo, e permette di tracciare gli utenti tra app e domini diversi. Questo, ovviamente, può compromettere la privacy se uno o più attori in gioco hanno cattive intenzioni (e, credetemi, di attori malintenzionati ce ne sono tantissimi in giro).

Da iOS 14.5 bisogna chiedere il consenso dell'utente, app per app, prima di poter accedere a questo identificatore. Significa che voi (utenti) potete decidere in ogni momento chi può accedere al vostro identificatore, sia all'installazione dell'app sia, se cambiate idea, dalle Impostazioni. Dal punto di vista dei diritti dell'utente è fantastico, e non è nemmeno discutibile.

Il nostro obiettivo di oggi è incapsulare queste classi in un oggetto più comodo, da usare sia con Swift sia con SwiftUI. Per riuscirci useremo alcune funzionalità di base di Combine, in modo da esporre correttamente tutti i pezzi che ci servono.

Per brevità useremo un approccio SwiftUI puro, ma tutto il codice sarà pronto anche per i progetti Swift standard. Cominciamo creando un progetto SwiftUI.

La prima cosa da fare è aggiungere la descrizione nel nostro Info.plist, in modo da popolare correttamente il messaggio che vedranno gli utenti. Come con CoreLocation o Photos, dobbiamo descrivere con una frase efficace cosa ci serve e perché chiediamo il consenso al tracking. Per farlo aggiungiamo una nuova chiave NSUserTrackingUsageDescription e la relativa stringa.

Quando siamo pronti, possiamo scrivere la classe helper che esporrà alla nostra app gli accessor necessari. L'abbiamo chiamata ATTrackingHelper. Poiché vogliamo essere notificati a ogni cambiamento di AuthorizationStatus o di AdvertisingIdentifier, ereditiamo da ObservableObject e marchiamo le due proprietà interessate con @Published. Questo significa che Combine, dietro le quinte, genererà per noi tutto il codice necessario per tracciare i cambiamenti e notificare i subscriber.

L'ultimo pezzo che manca per rendere utile questa classe è un metodo requestAuth(), che interagirà con il framework e popolerà di conseguenza i risultati.

Swift

class ATTrackingHelper: ObservableObject {
    @Published var status = ATTrackingManager.trackingAuthorizationStatus
    @Published var currentUUID = ASIdentifierManager.shared().advertisingIdentifier

    func requestAuth() {
        guard ATTrackingManager.trackingAuthorizationStatus != .authorized else {
            return
        }
        
        ATTrackingManager.requestTrackingAuthorization { status in
            DispatchQueue.main.async { [unowned self] in
                self.status = status
                if status == .authorized {
                    self.currentUUID = ASIdentifierManager.shared().advertisingIdentifier
                }
            }
        }
    }
}

È il momento di un Proof-Of-Concept. Con questo approccio basta dichiarare un ObservedObject nella nostra ContentView. Più o meno così:

Swift

struct ContentView: View {
    @ObservedObject var trackingHelper = ATTrackingHelper()

    var body: some View {
        VStack(alignment: .leading){
            Text("Your advertising ID:").font(.callout)
            Text("\(trackingHelper.currentUUID.uuidString)").font(.caption)
            HStack {
                Spacer()
                Button(action: {
                    trackingHelper.requestAuth()
                }, label: {
                    Text("Ask for tracking")
                })
                Spacer()
            }.padding(.vertical)
        }
        .padding()
    }
}

Ora possiamo chiedere il consenso all'utente, la prima volta che eseguiamo l'app, e popolare la uuidString richiesta. Che bel periodo per essere sviluppatori iOS! :-)

Happy coding! 🖖🏻

SwiftUI dentro UIKit: collegare due mondi

2021-03-24T00:00:00Z

Ieri sera ho partecipato a una room su Clubhouse molto interessante, in cui si parlava di SwiftUI e di interoperabilità con Swift. Il resto dell'articolo è un proof-of-concept che esplora alcune idee emerse durante la chat con Dimitri Giani, Stefano Mondino e Andrea Mengoli.

SwiftUI offre ottime prestazioni e rende semplice costruire anche layout complessi, ma spostare un intero progetto da UIKit a SwiftUI non è sempre fattibile, per molte ragioni (maturità del framework, tempi di consegna, e così via). Allora perché non prendere il meglio dei due mondi?

Esistono decine di tutorial e articoli sull'uso di UIHostingController che, ad oggi, sembra l'unica strada percorribile per realizzare quanto detto sopra. Ieri sera però ci siamo concentrati su un punto di vista un po' diverso:

Spostare in SwiftUI solo porzioni di codice molto piccole.

Per esempio, una delle cose più odiate da ogni sviluppatore iOS è dover usare lo Storyboard per disegnare le celle di una UITableView/UICollectionView.

Non sarebbe bello migrare in SwiftUI solo il contenuto di una UITableViewCell, per migliorare prestazioni, manutenibilità e semplicità, rendendo così a prova di futuro almeno una parte del nostro codice? Era la proposta di Dimitri Giani.

Tutti, io compreso, eravamo scettici: UIHostingController sembrava un approccio molto complicato e sovradimensionato per un compito così critico dal punto di vista delle prestazioni (parliamo dei componenti riutilizzabili di una UIScrollView).

Inutile dire che mi sbagliavo. Almeno in un primissimo test, descritto nel resto di questo articolo, l'approccio funziona benissimo, con qualche accorgimento, e senza alcun problema di prestazioni.

Sopra c'è una bozza di ciò che vogliamo ottenere. Come si vede, la UITableViewCell deve conoscere la proprietà rootView del corrispondente UIHostingController e, poiché ogni istanza di UITableViewCell deve essere riutilizzabile, dobbiamo mantenere questa proprietà unica.

Rendiamo la nostra CustomTableViewCell consapevole di questo creando una costante private che istanzia un UIHostingController e configurando l'oggetto nella primissima fase di awakeFromNib.

Il metodo configure(title:sfIcon:) è solo un segnaposto che sfrutta l'approccio Combine / publisher per comunicare con la corrispondente view SwiftUI. Qui inviamo una semplice Notification quando dobbiamo configurare la SwiftUIView.

Da notare che dobbiamo specificare la proprietà object, perché vogliamo gestire solo una specifica istanza dell'oggetto.

Sì, lo ammetto, sembra davvero un hack...

La controparte SwiftUI è molto semplice. Creiamo solo un contenitore HStack che ospita sia l'immagine di anteprima sia il titolo. Regoliamo anche il frame in modo da occupare tutto lo spazio disponibile senza ulteriori vincoli (la UIView che ci contiene sarà responsabile delle dimensioni del contenitore, N.d.R.). onReceive aggiorneremo i relativi stati, facendo in modo che la view si aggiorni da sola dove serve.

Noterete che ho fatto adottare Equatable alla struct stessa, aggiungendo sia un id sia il relativo metodo in override. Serve per distinguere se dobbiamo scartare o prendere in considerazione la notifica pubblicata ricevuta da NotificationCenter.

Ed è tutto. Anche se questa soluzione è un'architettura di cella molto hackish e sovradimensionata, sono davvero colpito dai risultati: lo scrolling è fluido e senza il minimo glitch.

Sono abbastanza sicuro che esistano altri modi per ottenere lo stesso risultato con meno boilerplate e/o in modo molto più elegante (soprattutto per la comunicazione da UIKit a SwiftUI).

Non vedo l'ora di leggere i vostri commenti e di vedere i vostri commit. Il codice completo è disponibile qui su GITHUB.

Apple Silicon: ritorno al futuro

2020-11-20T00:00:00Z

Il 2020 verrà ricordato come una pietra miliare per l'informatica, più o meno come il 2007 lo fu per la telefonia mobile.

L'Apple di Tim Cook ha ancora una volta segnato un passo storico nel mondo dei computer. Non credo di esagerare paragonando l'introduzione dell'M1 alla storica presentazione dell'iPhone, che sicuramente tutti ricordiamo.

Certo, i tempi e gli attori sono molto diversi, ma il risultato finale (e l'esecuzione) lascia a bocca aperta allo stesso modo.

Intel dovrà riorganizzare molte delle sue tabelle di marcia (preistoriche) per provare a ridurre il distacco. Il paragone con il 2007 mi viene naturale: allora Blackberry fu detronizzata dal podio all'improvviso e in modo quasi inaspettato, ma solo per chi non voleva guardare oltre il proprio naso. L'Intel di oggi ha una pipeline produttiva ormai capace solo di creare scaldapiedi. Non voglio sembrare di parte, ma a questo punto la realtà delle cose è più o meno questa.

Il vero problema è che nel mondo dei computer le cose sono molto più complesse di quanto accadde per i telefoni nel 2007. I computer sono animali diversi, con flussi di lavoro e una cultura consolidati, composti da una miriade di piccoli componenti di terze parti: Intel non produce direttamente i computer finiti, ma solo una piccola parte di quei prodotti. E non è un caso.

Apple, invece, fin dall'inizio ha scommesso tutto su un'integrazione totale e senza interruzioni tra hardware e software. Fermatevi un attimo a pensare:

E se, quando tutto ebbe inizio, Wozniak avesse avuto le disponibilità finanziarie (come l'Apple multimilionaria di oggi) per costruirsi un processore tutto suo?

All'epoca le cose erano completamente diverse e Motorola era il partner più vicino nella battaglia contro un nemico comune. Per fortuna di Apple i tempi sono cambiati, e l'Apple di oggi non sembra interessata a "condividere" con il mondo il proprio vantaggio tecnologico (stimato in almeno 6 anni). Vale la pena ricordare che sei anni, nel campo dei computer, sono quasi un'era.

Dell, HP, Lenovo e tutti gli altri hanno poco da fare, se non cercare di colmare il divario cominciando a correre. A mio parere le alternative sono solo due:

Creare un'alleanza (come fu per l'USB) e provare a costruire un processore il più simile possibile all'M1 di Apple.
Restare sulla barca di Intel, sperando che cambi radicalmente la propria impostazione e che qualcosa si muova il prima possibile.

Entrambe le soluzioni sono destinate a fallire per la stessa semplice ragione: il tempo.

Qualunque scelta facciano i concorrenti, ci vorrà tempo. E se è vero, come dicono le voci, che Apple lavora all'M1 da oltre otto anni, questo dà un'idea chiara di quanto ci voglia per raggiungere chi è in testa.

Nel frattempo Apple tornerà a occupare il podio dei "computer più venduti", come nella prima metà degli anni 2000, e, c'è da sperarlo per lei, il circolo virtuoso di lock-in che lega l'ecosistema Apple sarà garantito almeno per il prossimo decennio.

Steve Jobs non avrebbe potuto essere più orgoglioso del suo successore.

Programmare in SwiftUI: ObjectBinding e BindableObject

2020-01-10T00:00:00Z

In un articolo precedente abbiamo visto che in SwiftUI è possibile associare uno o più stati a una View tramite il modifier @State; quest'ultimo deve essere usato con value type allocati all'interno della View che li dichiara. In questo modo la nostra applicazione è in grado di capire autonomamente quando aggiornare l'interfaccia utente in seguito ai cambiamenti della variabile marcata con @State che, ricordiamo, viene identificata come source of truth.

Ma cosa succede se la nostra source of truth è un oggetto complesso, progettato per esempio come una class? In questo caso @State fallisce il suo scopo, perché è pensato per lavorare esclusivamente con le property locali della nostra View.

SwiftUI mette a disposizione un concetto più adatto a questo caso: @ObjectBinding. Si può usare in tutti i casi in cui la property viene passata per riferimento, come accade con le class.

Swift


struct MyCustomObject : View {
    @ObjectBinding var myObject
    var body: some View {
        Text(myObject.someTextProperty)
    }
}

Il protocol BindableObject

Le property con un modifier @ObjectBinding si riferiscono quindi a oggetti di tipo class. Perché una class sia compatibile con il modifier @ObjectBinding, deve adottare il protocol BindableObject.

Nella sua variante più semplice il protocol BindableObject è molto lineare e richiede soltanto che la nostra class implementi una property chiamata didChange, che notificherà gli oggetti View iscritti in modo che possano reagire correttamente ai cambiamenti dell'interfaccia visiva.

Swift


class MyObject : BindableObject {
    let didChange = PassthroughSubject<Void, Never>()
    
    var someTextProperty:String = "" {
        didSet {
            didChange.send( () )
        }
    }
    
    ...
}

Il framework Combine e PassthroughSubject

Perché funzioni, il codice precedente richiede di includere il supporto per il framework Combine all'inizio del nostro file swift.

Swift


import Combine

Il framework Combine è uno strumento molto potente e piuttosto complesso, che vedremo in un prossimo articolo. Per ora ci basta sapere che, tra le tante altre cose, fornisce una class chiamata PassthroughSubject (la nostra property didChange è un'istanza di questa class). Ha il compito di notificare (Publishing) le parti interessate (Subscribers) che si è verificato un evento specifico.

PassthroughSubject, come suggerisce il nome, si comporta in modo molto simile alle notifiche tradizionali messe a disposizione dal framework Foundation di Swift con NSNotificationCenter: l'oggetto specificato come parametro (nel nostro caso Void, dato che non vogliamo passare alcun parametro) viene passato così com'è, senza modifiche, al destinatario insieme a un evento di notifica che fa scattare una nuova ricostruzione della view.

Se si vuole specificare un errore insieme alla notifica, lo si può passare come secondo parametro. Nel nostro esempio questa eventualità non ci interessa, ed è per questo che passiamo Never come secondo parametro nell'invocazione di PassthroughSubject.

Swift


let didChange = PassthroughSubject<Void, Never>()

Una volta creata un'istanza di tipo PassthroughSubject, la possiamo usare per pubblicare il nostro evento ogni volta che vogliamo notificare alle View iscritte i cambiamenti della nostra source of truth.

Per soddisfare quest'ultimo requisito usiamo il costrutto didSet messo a disposizione da Swift, che viene invocato ogni volta che cambia il valore di una property:

Swift


var someTextProperty:String = "" {
    didSet {
        didChange.send( () )
    }
}

In questo modo, quando modifichiamo someTextProperty, viene invocato il costrutto didSet. Al suo interno chiamiamo il metodo send() dell'istanza di PassthroughSubject. Notate come specifichiamo un parametro di tipo Void passando al metodo una coppia di parentesi ().

Così tutti gli oggetti iscritti ai cambiamenti (quelli che hanno dichiarato la loro property come @ObjectBinding) sapranno che è arrivato il momento di aggiornare il loro body.

Fig.1: Semplice schema che illustra i riferimenti con ObjectBinding.

Come potete vedere dallo schema qui sopra, il nostro modello è caratterizzato da una singola istanza in memoria, tramite una class conforme al protocol BindableObject. I nostri oggetti View contengono un riferimento all'oggetto originale.

In questo modo si evita un problema tipico, la duplicazione della source of truth: le modifiche al modello saranno uniche e porteranno all'aggiornamento immediato di tutte le view che fanno riferimento alla nostra class.

Fig.2: Semplice schema che illustra source of truth e ObjectBinding.

Un esempio

Proviamo a mettere in pratica i concetti precedenti con un esempio. Nell'articolo precedente avevamo configurato la nostra CustomTableViewCell per usare una variabile passata per valore, contenente una struct chiamata Person.

Swift


struct CustomTableViewCell : View {
    var model: Person
    
    var body: some View {
    ...

Questo approccio non permetteva alla CustomTableViewCell di essere indipendente rispetto agli aggiornamenti del proprio contenuto: la variabile, infatti, veniva copiata durante la fase di init della CustomTableViewCell.

Ogni modifica al suo contenuto era gestita tramite una variabile @State, posseduta da ContentView, che rigenerava la cella con il nuovo contenuto a ogni cambiamento.

Fig.3: Riferimento a State e a Object binding a confronto.

Con il concetto di @ObjectBinding possiamo rendere unico il modello Person, passando alla CustomTableViewCell solo un riferimento, come mostrato nel grafico qui sopra a destra.

La prima cosa da fare è modificare il nostro modello Person in modo che usi una class che adotta il protocol BindableObject al posto di una struct.

Swift


class Person : BindableObject {
    let didChange = PassthroughSubject<Void, Never>()
    
    var photoName:String { didSet { update() } }
    var title:String { didSet { update() } }
    var subtitle:String { didSet { update() } }
    
    init(photoName: String, title: String, subtitle: String) {
        self.photoName = photoName
        self.title = title
        self.subtitle = subtitle
    }
    
    func update() {
        didChange.send(())
    }
}

Il nostro nuovo modello adotta il protocol BindableObject implementando la property didChange tramite un'istanza di PassthroughSubject.

Ogni property interessata da possibili cambiamenti dell'interfaccia visiva (photoName, title e subtitle) è stata modificata in modo da reagire tramite il costrutto didSet. In questo modo, ogni volta che aggiorniamo una delle variabili, viene attivata la funzione update(), che a sua volta invia una notifica a tutti gli iscritti tramite l'istanza di PassthroughSubject.

Infine modifichiamo la CustomTableViewCell per sfruttare il nuovo modello per riferimento. Per farlo basta anteporre il modifier @ObjectBinding di cui abbiamo parlato.

Swift


struct CustomTableCell : View {
    @ObjectBinding var model: Person
    
    var body: some View {
        return HStack {
            Image(model.photoName)
                .resizable()
                .aspectRatio(contentMode: .fit)
                .clipShape(Circle())
                .frame(width: 60, height: 60, alignment: .center)
            VStack(alignment: .leading) {
                Text(model.title).font(.title)
                Text(model.subtitle).font(.subheadline).fontWeight(.thin)
            }
            Spacer()
        }
    }
}

In questo modo la CustomTableViewCell non ha una copia del modello Person, ma lavora con un riferimento all'area di memoria in cui è conservato il modello originale. Vediamo dove e come creare il modello da passare per riferimento.

Di questo requisito si occuperà ContentView, creando il modello vero e proprio in memoria e passandolo per riferimento alla CustomTableViewCell.

Swift


struct ContentView : View {
    var dataSource:[Person] = [
        Person(photoName: "photoThumb", title: "Mario Rossi", subtitle: "Amministratore"),
        Person(photoName: "photoThumb", title: "Giuseppe Bianchi", subtitle: "Consigliere"),
        Person(photoName: "photoThumb", title: "Luca Verdi", subtitle: "Funzionario"),
    ]
    var body: some View {
        List {
            CustomTableCell(model: dataSource[0])
            CustomTableCell(model: dataSource[1])
            CustomTableCell(model: dataSource[2])
        }
    }
}

List e TableView

Questa nuova versione di ContentView usa un nuovo oggetto chiamato List, che raggruppa gli elementi più o meno come il corrispettivo VStack. La differenza sta nella visualizzazione: il risultato sarà molto simile a una UITableView del framework UIKit.

Quella che vediamo qui sopra è la forma di dichiarazione più semplice di List. Nel prossimo articolo vedremo come rendere dinamico il suo contenuto, in base al modello dichiarato.

--A presto!

Programmare in SwiftUI: introduzione agli stati

2020-01-09T00:00:00Z

Abbiamo visto in un articolo precedente che in SwiftUI una View è una struct che adotta il protocol View. Quindi non eredita alcuna stored property, semplicemente perché non ha nessun padre; viene allocata sullo stack e gestita per valore e non per riferimento (come accade invece con le class in UIKit).

Come funzionano le view in SwiftUI

Dietro le quinte, SwiftUI gestisce le View con l'aiuto di una struttura dati molto efficiente per il rendering a schermo dei contenuti. Per questo motivo è consigliabile usare e creare componenti specializzati e riutilizzabili. Durante lo sviluppo, Cupertino ci rassicura, non dobbiamo esitare a estrarre le view che svolgono un compito specifico e a creare per loro un oggetto View dedicato.

Insieme al body, una View in SwiftUI definisce le sue dipendenze.

Supponiamo di voler creare in SwiftUI una View specializzata nel creare e gestire un pulsante. Il nostro oggetto dovrà occuparsi di un solo compito: alla pressione, la label dovrà cambiare riflettendo il nuovo stato.

Ed è proprio qui che la programmazione dichiarativa dà il meglio: la conseguenza di un'azione come modo per aggiornare l'interfaccia.

L'attributo @State in SwiftUI

Il nostro pulsante avrà quindi una dipendenza tra il suo stato e la sua rappresentazione a schermo. In SwiftUI questa dipendenza è gestita automaticamente dal nuovo modifier @State. Proviamo con un esempio per capire meglio il concetto.

Swift


struct MyButton : View {
    @State private var toggleStatus:Bool = false
    var body: some View {
        Button(action: {
            self.toggleStatus = !self.toggleStatus
        }) {
            Text((toggleStatus == false) ? "Press Me" : "Unpress me")
        }
    }
}

@State lega la variabile toggleStatus all'interfaccia: ogni volta che il suo valore cambia, SwiftUI sa che è necessario generare un nuovo body (e quindi aggiornare la label associata).

Fig.1: Semplice schema che illustra il flusso dei dati del codice precedente.

Provate a rimuovere @State dal codice precedente. Cosa succede e perché?

Rimuovendo l'attributo @State, il compilatore si lamenterà perché stiamo cercando di modificare un valore immutabile: non dimentichiamo che abbiamo a che fare con una struct. Ogni oggetto che viene renderizzato a schermo, infatti, è immutabile per ragioni di performance. In questo modo SwiftUI sa cosa deve essere aggiornato e cosa può essere lasciato fuori. Aggiungendo un modifier @State, stiamo dicendo esplicitamente a SwiftUI:

"Attenzione! Qui c'è un oggetto che potrebbe cambiare il suo stato, quindi dovrai aggiornarne il contenuto."

Di conseguenza, SwiftUI definisce implicitamente una dipendenza tra questa variabile e la presentazione a schermo della View ogni volta che incontra un attributo @State. In questo modo, ogni volta che la variabile cambia valore, SwiftUI sa che la View deve essere ridisegnata con il nuovo valore.

Per fissare questo concetto e vedere quanto sia diverso dalla programmazione tradizionale, facciamo un confronto con UIKit:

Swift


import UIKit

class ViewController: UIViewController {
	@IBOulet var aButton: UIButton!
	var toggleStatus:Bool = false
	
	override func viewDidLoad() {
		super.viewDidLoad()
	}

	@IBAction func buttonDidPressed(sender: UIButton) {
		sender.setTitle((toggleStatus) ? "Unpress me" : "Press me", for: .normal)
		toggleStatus = !toggleStatus
	}
}

Naturalmente in UIKit il codice qui sopra non basta per ottenere una schermata funzionante. Dovremo creare uno Storyboard con un UIViewController e un UIButton. Dovremo inoltre allineare il pulsante al centro con i Constraints e creare i riferimenti @IBOutlet e @IBAction corretti per far funzionare l'intero flusso.

Lasciando da parte la quantità di codice e di operazioni, ovviamente maggiore rispetto a SwiftUI, concentriamoci sul nostro stato. Anche in questo caso, infatti, il nostro pulsante deve conoscere lo stato corrente per poter cambiare la sua rappresentazione (la label). Notate come, nella programmazione imperativa tradizionale, ci siano due problemi concettuali importanti:

toggleStatus è gestito (allocato, inizializzato e modificato) dal Controller.
Non esiste un modo chiaro, a livello di codice, per separare le variabili che riguardano lo stato dell'interfaccia da quelle tradizionali: sono tutte uguali!

Fig.2: Uno schema che illustra le relazioni e il flusso del nostro oggetto Button in UIKit.

È anche evidente come la complessità di questo approccio cresca in modo esponenziale all'aumentare del numero di oggetti e di stati.

Fig.3: Schema che illustra l'aumento della complessità al crescere degli stati gestiti dall'interfaccia.

C'è ancora una cosa da sottolineare: iOS è un sistema operativo multithreaded. Questo significa che le richieste di aggiornamento dello stato e dell'interfaccia possono arrivare da più punti del codice e che i thread lavorano in modo indipendente l'uno dall'altro. Senza un modo chiaro per gestire situazioni di questo tipo si arriva a incoerenze nella UI e quindi a bug difficili da scoprire e da correggere.

Fig.4: In un'applicazione multithreaded il confine tra chi aggiorna l'interfaccia e chi aggiorna lo stato non è chiaro.

La ricerca della verità

Ma come viene gestita in SwiftUI questa dipendenza tra variabili e interfaccia? E cosa rende il sistema resiliente e scalabile, a differenza di un approccio imperativo tradizionale?

Quando SwiftUI elabora una View con una variabile di tipo @State, alloca in memoria uno spazio per questa variabile per conto della View.

Fig.5: Allocazione di una variabile @State in SwiftUI.

Aggiungendo l'attributo @State possiamo modificare un oggetto che sarebbe altrimenti immutabile, come una struct: dietro le quinte, infatti, la variabile viene allocata dal framework SwiftUI in un'area di lettura/scrittura dell'applicazione.

In SwiftUI ogni possibile stato di una View (l'offset di una scrollview, lo stato di un pulsante, il contenuto di uno stack e così via) è gestito da questo concetto, noto come Source of Truth. Seguendo questo concetto è possibile classificare ogni variabile come source of truth oppure come valore derivato.

Fig.6: Schema che mostra la classificazione delle variabili in SwiftUI.

Nel nostro esempio, toggleStatus è una source of truth. Inoltre, dallo schema qui sopra possiamo dedurre che anche tutte le costanti sono una source of truth, mentre una semplice property è un valore derivato.

Vedremo nei prossimi capitoli che esiste un altro meccanismo per passare valori derivati in lettura/scrittura, chiamato @Binding. Con un esempio pratico vedremo anche in cosa un valore derivato differisce dalla corrispondente source of truth. Analizzeremo le differenze con @State e come e quando usare l'uno rispetto all'altro.

Organizzare il codice: l'estrazione delle view

Ora che abbiamo chiaro come una View si aggiorna e ricostruisce il suo contenuto, proviamo a mettere insieme quello che abbiamo imparato con l'esempio dell'ultimo articolo. L'ultima volta avevamo lasciato la nostra ContentView così:

Swift


import SwiftUI

struct ContentView : View {
    var body: some View {
        VStack {
            HStack {
                Image("photoThumb")
                    .resizable()
                    .aspectRatio(contentMode: .fit)
                    .clipShape(Circle())
                    .frame(width: 60, height: 60, alignment: .center)
                    .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
                VStack(alignment: .leading) {
                    Text("Mario Rossi").font(.title)
                    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
                }
                Spacer()
            }
        }
        
    }
}

Chiaramente questo approccio non è mantenibile. Il codice tende ad annidarsi e a crescere verso destra, nella cosiddetta "pyramid of doom".

All'inizio dell'articolo abbiamo accennato a un meccanismo per estrarre le subview, così da rendere il codice scalabile e mantenibile. Vediamo cosa ci offrono il nuovo Xcode 11 e SwiftUI per risolvere questo problema.

Assicuratevi di usare Xcode 11 e portate il mouse sul tag HStack. Tenendo premuto il tasto CMD (⌘), cliccate sul tag, come segue:

Fig.7: Xcode crea automaticamente una nuova struct e ci dà la possibilità di cambiarne il nome.

Xcode crea automaticamente una nuova struct, estrae il contenuto selezionato e lo usa per popolare il body dell'oggetto appena generato. Alla fine dell'operazione ci offre anche la possibilità di cambiare il nome: rinominate la View estratta in CustomTableViewCell.

La nuova versione di ContentView è ora molto più leggibile e leggera, e contiene solo un riferimento a un nuovo oggetto. Come ulteriore comodità, potremmo anche spostare il contenuto di CustomTableViewCell in un nuovo file, per isolare meglio il concetto di componente.

Passare parametri

Non sarebbe interessante passare i parametri giusti alla nostra nuova CustomTableViewCell, per generare una cella con contenuti dinamici come titolo, sottotitolo e immagine? Proviamo a modificare la nostra nuova struct per ottenere questo risultato:

Swift


struct CustomTableCell : View {
    var photoName:String
    var title:String
    var subtitle:String
    
    var body: some View {
        return HStack {
            Image(photoName)
                .resizable()
                .aspectRatio(contentMode: .fit)
                .clipShape(Circle())
                .frame(width: 60, height: 60, alignment: .center)
                .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
            VStack(alignment: .leading) {
                Text(title).font(.title)
                Text(subtitle).font(.subheadline).fontWeight(.thin)
            }
            Spacer()
        }
    }
}

Ora, dentro la ContentView, la nostra CustomTableCell può essere creata con parametri che ne definiscono in modo univoco il contenuto.

Swift


struct ContentView : View {
    var body: some View {
        VStack {
            CustomTableCell(photoName: "photoThumb", 
                                title: "Gianluca Verdi", 
                             subtitle: "Consigliere")
        }
        
    }
}

E se volessimo spingerci oltre e creare, per esempio, un pulsante che cambia il contenuto del campo subtitle?

Il modello, l'oggetto e SwiftUI

Il modello collegato a un oggetto View ha un ruolo fondamentale nel paradigma dichiarativo di SwiftUI. Ogni oggetto ha tipicamente un modello associato che, insieme allo stato, identifica completamente l'interfaccia utente mostrata.

Per esempio, potremmo associare alla nostra CustomTableViewCell un modello di questo tipo:

Swift


struct Person {
    var photoName:String
    var title:String
    var subtitle:String
}

Di conseguenza dovremo modificare la nostra View per sfruttare il nuovo modello appena creato:

Swift


struct CustomTableViewCell : View {
    var model: Person
    
    var body: some View {
        return HStack {
            Image(model.photoName)
                .resizable()
                .aspectRatio(contentMode: .fit)
                .clipShape(Circle())
                .frame(width: 60, height: 60, alignment: .center)
                .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
            VStack(alignment: .leading) {
                Text(model.title).font(.title)
                Text(model.subtitle).font(.subheadline).fontWeight(.thin)
            }
            Spacer()
            }
    }
}

Infine, la ContentView deve riflettere questa modifica per mostrare correttamente a schermo la nostra CustomTableViewCell.

Swift


struct ContentView : View {
    @State private var model = Person(photoName: "photoThumb", 
                               title: "Mario Rossi", 
                            subtitle: "Amministratore delegato")
    
    var body: some View {
        VStack {
            CustomTableViewCell(model: model)
            Button(action: {
                self.model.subtitle = "Consigliere"
            }) {
                Text("Change subtitle")
                .foregroundColor(Color.white)
                .padding(EdgeInsets(top: 8, leading: 8, bottom: 8, trailing: 8))
                .background(Color.blue)
                .cornerRadius(8)
            }
        }
    }
}

Questa volta la variabile model ha l'attributo @State: il proprietario del modello è l'oggetto ContentView, che lo passa per copia (ricordiamo che stiamo lavorando con struct e non con class) alla CustomTableViewCell, la quale a sua volta lo usa per mostrare i campi corrispondenti dei suoi oggetti: Image e Text.

Il pulsante ha un'azione che aggiorna il modello cambiandone il subtitle. Poiché ContentView ha aggiunto l'attributo @State al suo modello, ogni modifica di quest'ultimo fa scattare l'aggiornamento del suo body che, a sua volta, rigenera una nuova CustomTableViewCell con il contenuto aggiornato.

Fig.8: Schema di flusso che illustra l'aggiornamento dello stato dell'oggetto.

Avrete notato che ho aggiunto l'attributo private prima di dichiarare la variabile di stato del modello. Questo perché, come abbiamo spiegato sopra, le variabili marcate con @State appartengono esclusivamente alla View che le dichiara. È quindi una buona idea rafforzare questo concetto marcandole come private.

Vedremo nel prossimo articolo che SwiftUI espone altri modi per gestire i parametri e l'injection quando ci troviamo in situazioni come quella illustrata sopra. In questo caso, infatti, pur essendo corretto dal punto di vista sintattico e funzionale, il nostro flusso soffre di un piccolo problema: la nostra CustomTableViewCell usa una propria copia del modello, che a sua volta è esposto, allocato e gestito da ContentView con una variabile privata.

SwiftUI offre astrazioni molto simili all'attributo @State per gestire queste circostanze e permettere al modello di propagarsi correttamente dove serve.

Cosa succede se cambiamo il modello da struct a class?

Anche se il progetto continuerà a compilare e a girare senza problemi, purtroppo noteremo che in pratica il pulsante non cambierà più il contenuto del campo subtitle.

@State funziona con i value type, mentre le class sono reference type: cambiando il valore di una class marcata con l'attributo @State, la sua modifica interna non fa scattare l'aggiornamento del body.

-- 🖖🏻

Programmare in SwiftUI: costruire view più complesse

2020-01-08T00:00:00Z

Abbiamo visto che SwiftUI richiede sempre di esporre un body che restituisce una View. Nella costruzione di view complesse, però, è necessario comporre queste View con un layout specifico e restituirle sotto forma di un unico oggetto. Per farlo SwiftUI ci viene in aiuto attraverso il concetto di Content View.

Gli oggetti di base con cui abbiamo a che fare, come Text che abbiamo visto nel capitolo precedente, adottano il protocol View. Ci sono altri oggetti, più complessi, che nella dichiarazione della loro API hanno un formato simile a questo:

Swift


public struct VStack<Content> where Content : View

Quella qui sopra è la dichiarazione del componente VStack, che analizzeremo nel resto dell'articolo. Se guardiamo la definizione di Content, vedremo che:

Swift


@_functionBuilder public struct ViewBuilder {
    ...
    public static func buildBlock<Content>(_ content: Content) -> Content where Content : View
    ...
}

In pratica, oggetti come VStack usano un costruttore ViewBuilder per comporre insieme più tipi di View.

La closure ViewBuilder

La closure ViewBuilder ci permette di inserire al suo interno istruzioni tipicamente dichiarative: invece di invocare un metodo addSubview, come facevamo con UIKit, inseriremo una lista con tutte le view contenute direttamente nella closure.

Per capire meglio questo concetto, guardiamo più da vicino la definizione della struct VStack:

Swift


public struct VStack<Content> where Content : View {
    public init(
        alignment: HorizontalAlignment = .center, 
        spacing: Length? = nil, 
        @ViewBuilder content: () -> Content
    )
}

Il parametro content è definito come una closure () -> Content. Il compilatore riconosce questo attributo come implicitamente marcato con @ViewBuilder e sa come trasformarlo in una nuova closure che restituisce una view rappresentante tutto il contenuto dichiarato dentro VStack.

Questo principio è presente in tutti gli oggetti che espongono una clausola where Content: View

Stack View

Una Stack View è una View speciale di tipo Container View che ci permette di restituire una composizione di altri oggetti View, secondo un layout verticale, orizzontale o in profondità.

Continuando i nostri confronti con il framework UIKit, l'oggetto corrispondente che analizzeremo in questo paragrafo è UIStackView. In SwiftUI, però, a parte l'idea di base, resta ben poco della classica UIStackView.

Gli stack attualmente disponibili sono di tre tipi: HStack, VStack e ZStack. Rispettivamente: Horizontal Stack, Vertical Stack e Depth Stack (Z indica la dimensione della profondità).

Questi oggetti, insieme ai modifier che abbiamo visto nel capitolo precedente, ci permettono di sostituire completamente il concetto di Auto Layout e Constraints. Dal punto di vista tecnico questo aumenta molto la reattività e la velocità di rendering dell'applicazione, perché il sistema non deve pre-calcolare nessun constraint o layout specifico: tutto è dichiarato a priori, in puro stile dichiarativo.

Fig.1: Una semplice gerarchia che mostra un tipico uso di VStack.

Nel codice scriveremo qualcosa del genere:

Swift


import SwiftUI

struct ContentView : View {
    var body: some View {
        VStack {
           Image( ... )
           Text( ... )
           Text( ... )
           Text( ... )
           Slider( ... )
        }
    }
}

Come potete vedere, a differenza di UIKit, i riferimenti a metodi come addSubview non ci sono più. In SwiftUI le view si creano interamente con un processo di composizione dichiarativa delle struct. Semplicemente, diciamo al compilatore che la nostra ContentView contiene un container VStack che a sua volta contiene: Image, Text, Text, Text e Slider.

Per ora non ci preoccupiamo dei singoli metodi di creazione. Avremo modo di tornare tra poco sulle immagini e sui controlli avanzati come lo slider. Per ora l'importante è capire esattamente cosa sta succedendo e perché.

Una nota molto importante sul ViewBuilder riguarda la sintassi da usare al suo interno. Anche se siamo in presenza di Swift, dentro questa closure non è possibile usare alcuni operatori tipici a cui siamo abituati, come l'optional unwrapping:

Swift


...
VStack {
    if let anImage = anImage {
       Image( ... )
    }
    Text( ... )
    Text( ... )
    Text( ... )
    Slider( ... )
}

Questo codice produrrà un errore di compilazione. La closure ViewBuilder non è in grado, per ora, di interpretare correttamente il concetto di optional unwrapping. Il codice seguente, invece, funziona correttamente:

Swift


...
VStack {
    if anImage != nil {
       Image( ... )
    }
    Text( ... )
    Text( ... )
    Text( ... )
    Slider( ... )
}

Costruire una TableViewCell personalizzata

Dato che il modo più semplice per imparare un nuovo strumento è metterlo in pratica, in questa sezione proveremo a replicare il comportamento tipico di una UITableViewCell con titolo e sottotitolo. Il risultato che vorremmo ottenere è qualcosa del genere:

Fig.2: La TableViewCell che vorremmo ottenere.

La prima cosa da fare è creare un nuovo progetto con il supporto per SwiftUI:

Fig.3: I passi da seguire

Ora sostituiamo la struct ContentView fornita di default con il codice seguente:

Swift

struct ContentView : View {
	var body: some View {
		VStack(alignment: .leading) {
			Text("Mario Rossi").font(.title)
			Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
		}
	}
}

A questo punto, nel pannello Preview Canvas dovreste vedere comparire come per magia il risultato delle vostre istruzioni:

Fig.4: Il pannello Preview di Xcode 11 mostra il risultato delle nostre dichiarazioni al framework SwiftUI.

Se non vedete nulla, assicuratevi prima di tutto di lavorare su macOS Catalina 10.15: il sistema di Live Preview funziona esclusivamente in questo ambiente. Se siete già su 10.15 ma non vedete ancora la live preview, verificate di aver attivato il pannello Canvas come segue:

Fig.5: Perché la Live Preview funzioni bisogna essere su Catalina 10.15 e aver attivato il pannello Canvas.

Semplice? Certo! Ci mancano ancora alcuni elementi per completare il lavoro. La prima cosa è l'immagine. Scaricate l'immagine di riferimento che trovate in fondo all'articolo e, dopo aver selezionato la cartella Assets.xcassets del vostro progetto, trascinateci dentro l'immagine appena scaricata.

Fig.6: Importare un'immagine per il nostro esercizio nella cartella degli asset.

L'oggetto Image

Ogni framework deve poter dialogare, in modo più o meno completo e complesso, con le immagini. SwiftUI offre un supporto davvero notevole per questo tipo di oggetti, che non farà rimpiangere nemmeno il suo cugino UIImageView.

Image è un oggetto View (il risultato è un oggetto conforme al protocol View). Nella sua forma più semplice, gli forniamo il nome di un'immagine da mostrare:

Swift


Image("photoThumb")

Il risultato è una View con l'immagine passata come argomento. Se proviamo a inserire questa istruzione dentro la VStack:

Swift


...
VStack(alignment: .leading) {
    Image("photoThumb")
    Text("Mario Rossi").font(.title)
    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
}
...

il risultato non sarà esattamente quello sperato:

Fig.7: Il primo tentativo con Image non è esattamente quello sperato!

Proviamo a risolvere il problema. La prima cosa da fare è allineare l'immagine in orizzontale con il resto del contenuto. Vi ricordate quando parlavamo di VStack?

Il suo compito è allineare verticalmente la lista di elementi forniti nel suo blocco ViewBuilder. È chiaro, quindi, che bisogna modificare leggermente lo schema delle view su cui stiamo lavorando, aggiungendo un'ulteriore variante di Stack fornita da SwiftUI: HStack.

Fig.8: Il nuovo schema ad albero di come vorremmo modificare la nostra ContentView.

Swift


struct ContentView : View {
    var body: some View {
        HStack {
            Image("photoThumb")
            VStack(alignment: .leading) {
                Text("Mario Rossi")
                    .font(.title)
                Text("Amministratore delegato")
                    .font(.subheadline)
                    .fontWeight(.thin)
            }
        }
    }
}

Fig.8a: Secondo tentativo

Molto meglio!

Dobbiamo ancora sistemare la forma e la dimensione dell'immagine. La prima cosa da fare è dire alla nostra immagine che deve essere ridimensionabile e mantenere il suo aspectRatio.

Swift


...
Image("photoThumb")
    .resizable()
    .aspectRatio(contentMode: .fit)
...

Poi vorrei darle una forma circolare e forzarne la dimensione a 60pt:

Swift


...
.clipShape(Circle())
.frame(width: 60, height: 60, alignment: .center)
...

e, infine, vorrei aggiungere un po' di padding a sinistra, diciamo 20 punti:

Swift


...
.padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
...

Tutto insieme:

Swift


struct ContentView : View {
    var body: some View {
        VStack {
            HStack {
                Image("photoThumb")
                    .resizable()
                    .aspectRatio(contentMode: .fit)
                    .clipShape(Circle())
                    .frame(width: 60, height: 60, alignment: .center)
                    .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
                VStack(alignment: .leading) {
                    Text("Mario Rossi").font(.title)
                    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
                }
            }
        }
        
    }
}

L'oggetto Spacer

A questo punto la nostra CustomTableView sembra completa, ma resta un piccolo problema: sembra allineata al centro invece che a sinistra.

Il problema dipende dal fatto che gli stack, per impostazione predefinita (ricordo che quello su cui stiamo lavorando si espande in orizzontale, HStack), sono pensati per occupare tutto lo spazio disponibile sul loro asse principale, dividendolo in parti uguali tra i figli.

Quindi, per allineare tutto l'oggetto a sinistra, bisogna aggiungere un'ulteriore view neutra chiamata Spacer. La View Spacer è una view flessibile che si espande automaticamente lungo tutto l'asse principale dello stack in cui viene inserita. Aggiungeremo questa View come ultimo elemento del nostro stack orizzontale:

Swift


struct ContentView : View {
    var body: some View {
        VStack {
            HStack {
                Image("photoThumb")
                    .resizable()
                    .aspectRatio(contentMode: .fit)
                    .clipShape(Circle())
                    .frame(width: 60, height: 60, alignment: .center)
                    .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
                VStack(alignment: .leading) {
                    Text("Mario Rossi").font(.title)
                    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
                }
                Spacer()
            }
        }
        
    }
}

Ecco come apparirà la nostra preview a lavoro completato:

Fig.9: La gerarchia ad albero finale della CustomTableViewCell.

Nota: l'attuale versione di Xcode 11 contiene un problema noto che non ridimensiona correttamente l'immagine quando si usa l'opzione .fit, producendo invece una sorta di effetto di stiramento del contenuto.

Nel prossimo capitolo vedremo alcune regole di buona condotta per rendere il codice il più minimale e compatto possibile, adottando tecniche di estrazione delle subview. Vedremo anche un'introduzione al passaggio dei parametri e a come SwiftUI gestisce lo stato dei suoi elementi.

-- 🖖🏻

Programmare in SwiftUI: class e struct in SwiftUI

2020-01-07T00:00:00Z

Sono piuttosto sicuro che a tutti sia venuta in mente, almeno una volta, questa domanda.

"Se il concetto alla base di una View è il protocol, cosa succede se provo a usare una class?"

Proviamo ad analizzarla nel dettaglio.

Swift


class ContentView: View {
   var body: some View {
      Text("Hello World")
   }
}

Il codice qui sopra, pur essendo sintatticamente perfetto, produce un errore. Il compilatore si lamenta del fatto che la class è troppo mutevole durante l'esecuzione. Una class è infatti indeterminata per sua natura: cosa succederebbe se la stessa ContentView avesse una sottoclasse?

Il protocol View non saprebbe come garantire l'unicità. * Self * continuerebbe a riferirsi a ContentView e la sottoclasse violerebbe questa regola.

Swift


class SomeView<T: View> {
   var body: some View {
      Text("Hello World")
   }
}

oppure, più semplicemente:

Swift


final class ContentView: View {
   var body: some View {
      Text("Hello World")
   }
}

A questo punto, se è davvero necessario, possiamo usare una class per lavorare in SwiftUI.

Programmare in SwiftUI: l'oggetto View

2020-01-06T00:00:00Z

Abbiamo visto che SwiftUI è un framework dichiarativo. Il risultato visivo che vediamo sul nostro dispositivo nasce da una serie di istruzioni con cui diciamo al compilatore come vogliamo vedere la nostra interfaccia. Ma se la UIView era il cuore pulsante di UIKit, qual è l'equivalente in SwiftUI? La risposta è un nuovo oggetto, chiamato View.

Che cos'è una View?

La prima vera grande differenza rispetto a una UIView è che in SwiftUI una View è una struct che adotta un protocol. L'esempio base fornito da Apple comincia così:

Swift


struct ContentView: View {
   var body: some View {
      Text("Hello World")
   }
}

Quello qui sopra è un oggetto SwiftUI perfettamente funzionante, chiamato ContentView, che contiene (restituisce) nel suo body una label con "Hello World".

Noterete che ho parlato di "contenere" (return l'ho solo accennato tra parentesi). Uno dei cardini di SwiftUI è infatti la riusabilità del codice e il concetto di View riutilizzabili come se fossero mattoncini Lego ™.

Fig.1: Gerarchia ad albero dell'esempio precedente.

Una view, quindi, definisce un pezzo della nostra User Interface.

Tutto in un'app SwiftUI può essere ricondotto a una View, che definisce un pezzo della nostra interfaccia. Di conseguenza, le view complesse sono costruite a partire da elementi semplici che cooperano tra loro, formando una gerarchia ad albero. Dietro le quinte, il compilatore gestisce tutte le View e le traduce in una struttura dati molto efficiente che mostra a schermo il contenuto richiesto. Ma come funziona questa composizione?

Un solo requisito: body

Abbiamo detto che una View è una struct che adotta il protocol View. L'unico requisito di questo protocol è fornire alla nostra View un body, responsabile del contenuto del nostro oggetto. Il body è una closure speciale che restituisce un contenuto anch'esso sotto forma di View. Per esempio, nel codice di Apple visto sopra:

Swift


...
   var body: some View {
      Text("Hello World")
   }
...

In questo caso il body della nostra View è un componente di base, chiamato Text, che a sua volta restituisce un oggetto conforme al tipo some View richiesto dal body. Questa sintassi fa parte di un concetto nuovo introdotto con Swift 5.1, chiamato Opaque Types. Per ora basta sapere che l'opaque type richiesto dal body ci permette di scambiare oggetti di cui non conosciamo in anticipo il tipo specifico, ma che è ben determinato a livello di compilazione (a differenza di un semplice protocol).

Opaque types

Restituire un opaque type sembra molto simile a usare un protocol, ma i due costrutti differiscono perché l'opaque type conserva il tipo. Un opaque type si riferisce a un tipo specifico, anche se chi chiama la funzione non è in grado di vedere quale sia. Un protocol, invece, può riferirsi a qualunque tipo che lo adotti: offre quindi più flessibilità sul tipo restituito, mentre gli opaque type ci danno garanzie precise sul tipo restituito.

Facciamo un esempio per chiarire meglio il concetto:

Swift

mport UIKit

protocol Humanoid {
}

struct Woman : Humanoid {
}

struct Man : Humanoid {
}

func child() -> Humanoid {
	Bool.random() ? Woman() : Man()
}

Il protocol Humanoid è adottato da due struct: Man e Woman. La funzione child restituisce un Humanoid che può essere, con uguale probabilità, uno dei due casi. A questo punto creiamo due istanze di Humanoid:

Swift


let first = child()
let second = child()

e, siccome siamo curiosi di sapere se i nostri figli sono maschi o femmine, proviamo a confrontarli:

Swift


print((first == second))

A questo punto il compilatore ci rimprovererà, giustamente, perché Humanoid non è confrontabile: non adotta il protocol Equatable. Niente male, penserete. Proviamo ad adottarlo:

Fig.2: Output del Playground.

Il problema è che Humanoid non può essere confrontato perché Swift non ha alcuna garanzia che gli elementi restituiti siano di un tipo confrontabile. Ricordo che qualunque struct può adottare il protocol, implementando i metodi richiesti.

Per risolvere questo problema sono nati gli opaque type. Il codice precedente può essere trasformato così:

Swift


import UIKit

protocol Humanoid : Equatable {
}

struct Woman : Humanoid {
}

struct Man : Humanoid {
}

func boy() -> some Humanoid {
	Man()
}

func girl() -> some Humanoid {
	Woman()
}

let primogenito = boy()
let secondogenito = girl()

Un'osservazione importante sul codice qui sopra: come potete vedere, ho dovuto creare due funzioni diverse (boy per il maschio, girl per la femmina), perché uno dei requisiti principali quando si lavora con un opaque type è che i metodi devono restituire un solo tipo di oggetto. Ritroverete questo concetto molto spesso in SwiftUI quando lavoreremo con le View.

Programmare in SwiftUI: introduzione

2020-01-05T00:00:00Z

SwiftUI segna sicuramente l'inizio di un nuovo capitolo nella storia dello sviluppo in casa Apple. Da anni assistiamo al proliferare di framework basati sul concetto di interfacce dichiarative: il web ne è un esempio lampante, ma non mancano esempi illustri nello sviluppo mobile. Siamo continuamente bombardati da messaggi di marketing che affermano come:

"mantenere un'unica codebase per tutte le piattaforme è il modo migliore per aumentare la produttività aziendale e fornire soluzioni efficaci ai nostri clienti."

React Native (Facebook) e Flutter (Google) sono un esempio eccellente di questa proposta. Non è scopo di questo articolo fare un'analisi comparativa di queste tecnologie: ho citato questi due esempi per mostrare come la tendenza del software negli ultimi anni si stia muovendo in direzioni diverse da quelle a cui siamo stati abituati finora.

I nostri dispositivi sono sempre più potenti e questa potenza trova la sua naturale collocazione in interfacce e paradigmi di interazione sempre più sofisticati e complessi. L'anno scorso scrissi un pezzo sull'uscita di iPhone X e sulla sensazione di fluidità che questo nuovo dispositivo, unito alle ultime scelte stilistiche di iOS 11 e 12, mi aveva suscitato.

Animazioni fluide, continue e coerenti, gesture fuse nell'esperienza di navigazione. Sono solo alcuni esempi di quello che sto cercando di trasmettervi: l'asticella delle aspettative si è alzata ancora una volta e queste nuove caratteristiche non sono facilmente esprimibili con un framework tradizionale.

"La natura discreta dei linguaggi imperativi è in forte difficoltà, rispetto al senso di continuità e fluidità imposto dalle nuove interfacce."

Apple è sempre stata una società molto conservativa (Objective-C continua a funzionare e a compilare senza problemi) riguardo ai propri ambienti di sviluppo e, in generale, a tutto il suo ecosistema. L'introduzione di Swift, 5 anni fa, con i suoi nuovi paradigmi e la sua sferzata di modernità era già stata un grosso segnale di cambiamento da parte di Cupertino. Ma era chiaro che non bastava. Così, a sorpresa per tutti, ecco arrivare la risposta di Apple agli altri colossi del web: SwiftUI.

SwiftUI è un framework dichiarativo orientato ai componenti. Dimentichiamoci, dunque, del pattern MVC, dove i controller facevano da mediatori tra view e modelli. Tutto quello che abbiamo in SwiftUI è uno stato e una view derivata dallo stato. Non appena lo stato cambia, SwiftUI ricostruisce l'interfaccia tenendo conto delle modifiche.

Quelli che seguono sono i nostri appunti di viaggio personali, presi durante lo studio di questo framework così nuovo e, per certi versi, misterioso. Abbiamo ritenuto utile condividerli con tutti voi, nella speranza che siano un punto di partenza per imparare qualcosa di davvero entusiasmante.

--Buon viaggio!

TextField e UIViewRepresentable

2019-06-28T00:00:00Z

A prima vista, quando ho provato SwiftUI per la prima volta dopo la presentazione del WWDC19, una delle preoccupazioni più grandi riguardava sicuramente l'oggetto TextField: non c'era modo di chiudere la tastiera, né di spostare il focus da un TextField all'altro.

probabilmente alcuni dettagli non erano ancora pronti durante la presentazione iniziale.

iOS13 beta2, insieme a molti altri miglioramenti, sembra risolvere almeno in parte i problemi legati al TextField: quando si preme il tasto Invio, la tastiera ora viene chiusa correttamente. Non ci sono indizi, però, su un meccanismo per cambiare il focus tra più TextField all'interno dello stesso container View. Purtroppo dobbiamo anche segnalare un bug importante della beta2 che riguarda il meccanismo di chiamata della closure onCommitHandler quando la tastiera viene chiusa: quest'ultima non viene mai chiamata.

In questo articolo proveremo ad aggirare tutti questi problemi creando un TextField personalizzato che prende il meglio di quello che c'è oggi in SwiftUI e in UIKit. I lettori più attenti avranno probabilmente già capito dove voglio arrivare:

Costruiremo un componente personalizzato in UIKit che usa la vecchia e perfettamente funzionante UITextField e lo esporremo in SwiftUI attraverso il protocol UIViewRepresentable.

UITextField e i delegate

UIKit mette a disposizione un oggetto chiamato UITextField che sfrutta la tecnica del delegate per offrire un'esperienza di tastiera fluida ed efficace.

Quello che faremo è creare una class che eredita da UITextField e, allo stesso tempo, adotta il protocol UITextFieldDelegate. In questo modo avremo un unico oggetto da esporre per l'integrazione con SwiftUI.

La prima cosa da fare è dichiarare la nostra class, che chiameremo WrappableTextField:

Swift

class WrappableTextField: UITextField, UITextFieldDelegate {
    var textFieldChangedHandler: ((String)->Void)?
    var onCommitHandler: (()->Void)?
    
    func textFieldShouldReturn(_ textField: UITextField) -> Bool {
	...
    }
    
    func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
	...
    }
    
    func textFieldDidEndEditing(_ textField: UITextField) {
	...
    }
}

Il codice qui sopra mostra lo scheletro dei metodi delegate che implementeremo per completare la class Wrapper.

Come anticipato, la nostra class estende UITextField e adotta il protocol delegate UITextFieldDelegate. Abbiamo anche aggiunto due variabili locali che contengono due closure opzionali personalizzate. Rispettivamente:

La closure textFieldChangedHandler verrà invocata ogni volta che la UITextField cambia.
La closure onCommitHandler verrà invocata al termine dell'editing, alla pressione del tasto Invio.

Vediamo ora, passo per passo, le singole implementazioni dei metodi che aggiungeremo alla nostra class.

textField:shouldChangeCharactersInRange:replacementString:

Il metodo delegate shouldChangeCharactersInRange:replacementString: viene invocato automaticamente dal sistema ogni volta che scriviamo qualcosa con la tastiera. Ci permette di eseguire controlli sul contenuto, restituendo un valore booleano a seconda che il contenuto inserito sia permesso o meno dalle nostre regole di validazione.

Swift

func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
    if let currentValue = textField.text as NSString? {
        let proposedValue = currentValue.replacingCharacters(in: range, with: string)
        textFieldChangedHandler?(proposedValue as String)
    }
    return true
}

Nel nostro caso basterà comporre la nuova stringa risultante dall'inserimento dell'input dell'utente e di quella attualmente presente nella UITextField. Per semplicità convertiamo il tipo String in un NSString di Foundation, che offre tutti gli strumenti per comunicare direttamente con l'oggetto NSRange fornito come parametro di input dal metodo.

Una volta convertita la stringa, applichiamo la trasformazione proposta dal metodo:

replacingCharacters(in: range, with: string)

passando come parametri i due valori forniti in input dal metodo: range e la stringa inserita dall'utente. Il risultato sarà la composizione tra l'input dell'utente e il contenuto attuale della UITextField.

Questo valore sarà quello che passeremo in input alla closure definita in precedenza:

textFieldChangedHandler?(proposedValue as String)

textFieldDidEndEditing:

L'implementazione di questo metodo, richiamato dal sistema al termine della fase di editing, è molto semplice: dovrà solo invocare la closure personalizzata definita prima. In questo modo potremo eseguire un blocco di codice arbitrario ogni volta che l'editing termina.

Swift

func textFieldDidEndEditing(_ textField: UITextField) {
    onCommitHandler?()
}

textFieldShouldReturn:

L'ultimo metodo da implementare è textFieldShouldReturn. La sua implementazione ci permetterà di costruire un meccanismo molto semplice per spostare il focus dal nostro TextField ad altre class simili contenute nella stessa container view. Vediamo come funziona.

La prima cosa che facciamo è chiedere all'elemento textField corrente un riferimento alla propria superview?.superview?, seguendo uno schema simile a quello rappresentato nel diagramma seguente:

Se viene restituito un oggetto valido, invochiamo il suo metodo viewWithTag, passando il tag corrente incrementato di uno. In questo modo siamo riusciti a creare un meccanismo di navigazione molto elementare, che permette di risalire fino al container e chiedergli altre view con un tag specifico.

Swift

func textFieldShouldReturn(_ textField: UITextField) -> Bool {
    if let nextField = textField.superview?.superview?.viewWithTag(textField.tag + 1) as? UITextField {
        nextField.becomeFirstResponder()
    } else {
        textField.resignFirstResponder()
    }
    return false
}

Se il valore restituito esiste ed è di tipo UITextField, abbiamo trovato un'altra UITextField e possiamo passarle il controllo. Altrimenti chiudiamo semplicemente la tastiera.

La nostra class Wrappable è pronta. Ora non resta che collegarla a SwiftUI.

UIViewRepresentable

SwiftUI mette a disposizione un protocol molto utile, chiamato UIViewRepresentable, che permette di esporre tutti quegli oggetti UIKit che finora non sono stati integrati nativamente in SwiftUI.

Adottando questo protocol è possibile costruire un oggetto che espone nativamente a SwiftUI il contenuto di una UIView. Richiede di implementare solo due metodi:

Swift

struct SATextField: UIViewRepresentable {

    func makeUIView(context: UIViewRepresentableContext<SATextField>) -> WrappableTextField {
	...
    }
    
    func updateUIView(_ uiView: WrappableTextField, context: UIViewRepresentableContext<SATextField>) {
	...
    }
}

Il primo metodo si occupa di creare la nostra UIView e di fornirla a SwiftUI in un formato some View compatibile, ammesso dal protocol di SwiftUI come abbiamo visto nei tutorial precedenti.

Il secondo metodo verrà invocato ogni volta che la nostra UIView deve essere aggiornata per riflettere un cambiamento nell'interfaccia utente (un po' come la property body che abbiamo visto negli oggetti nativi di SwiftUI).

Infine aggiungiamo al nostro oggetto alcune variabili locali che useremo per guidare il comportamento della class WrappableTextField dichiarata in precedenza:

Swift

struct SATextField: UIViewRepresentable {
    private let tmpView = WrappableTextField()
    var tag:Int = 0
    var placeholder:String?
    var changeHandler:((String)->Void)?
    var onCommitHandler:(()->Void)?

    ...
}

Queste variabili saranno i parametri richiesti per creare l'oggetto SwiftUI. Verranno passate alla class Wrapper istanziata prima ed esprimono, rispettivamente: il valore del tag da associare al TextField, le closure necessarie per gestire i cambiamenti dell'input dell'utente e la fine dell'editing, e il valore da associare al placeholder della nostra UITextField.

Il contenuto del metodo makeUIView associa semplicemente i parametri inseriti dall'utente durante la creazione dell'oggetto SwiftUI ai parametri corrispondenti esposti dalla class WrappableTextField.

Swift

func makeUIView(context: UIViewRepresentableContext<SATextField>) -> WrappableTextField {
    tmpView.tag = tag
    tmpView.delegate = tmpView
    tmpView.placeholder = placeholder
    tmpView.onCommitHandler = onCommitHandler
    tmpView.textFieldChangedHandler = changeHandler
    return tmpView
}

Il metodo updateUIView imposta la hugging priority della nostra UITextField in modo che si adatti a tutto lo spazio disponibile nel Container View, in modo coerente con tutti gli altri oggetti:

Swift

func updateUIView(_ uiView: WrappableTextField, context: UIViewRepresentableContext<SATextField>) {
    uiView.setContentHuggingPriority(.defaultHigh, for: .vertical)
    uiView.setContentHuggingPriority(.defaultLow, for: .horizontal)
}

Mettiamo tutto insieme: un esempio reale

Proviamo a usare il nostro nuovissimo SATextField in un esempio pratico:

Swift

struct ContentView : View {
    @State var username:String = ""
    @State var email:String = ""
    
    var body: some View {
        VStack {
            HStack {
                Text(username)
                Spacer()
                Text(email)
            }
            SATextField(tag: 0, placeholder: "@username", changeHandler: { (newString) in
                self.username = newString
            }, onCommitHandler: {
                print("commitHandler")
            }).padding(EdgeInsets(top: 8, leading: 8, bottom: 8, trailing: 8))
            SATextField(tag: 1, placeholder: "@email", changeHandler: { (newString) in
                self.email = newString
            }, onCommitHandler: {
                print("commitHandler")
            }).padding(EdgeInsets(top: 8, leading: 8, bottom: 8, trailing: 8))
        }
    }
}

Fatto, ragazzi! Con poche righe di codice abbiamo creato un oggetto TextField che risponde ai cambi di focus e al completamento dell'editing, in attesa che la prossima beta di iOS13 risolva i problemi attuali dell'oggetto TextField nativo.

Un gioco TicTacToe in SwiftUI

2019-06-18T00:00:00Z

Oggi proviamo a costruire un gioco TicTacToe in meno di 160 righe con SwiftUI, il nuovo framework dichiarativo di Apple che promette di sostituire nel prossimo futuro il suo fratello UIKit. Apriamo Xcode.

In queste ore sono uscite la beta 2 di Xcode e quella di macOS Catalina. Vi consiglio caldamente di installarle entrambe: abbiamo notato un netto miglioramento generale delle prestazioni e una maggiore reattività di Xcode sotto ogni aspetto.

Una volta aperto Xcode, creiamo un nuovo progetto chiamato TicTacToe e controlliamo che la spunta su SwiftUI sia attiva. Premiamo next e scegliamo una cartella in cui salvare il progetto.

Terminata l'inizializzazione, Xcode mostra lo scheletro del progetto pre-generato. Passiamo a ContentView.swift e iniziamo subito a dare forma alla logica del gioco.

Nel TicTacToe due avversari si sfidano su una scacchiera 3x3, ciascuno con il proprio segno, X oppure O. Vince chi per primo allinea tre segni uguali in orizzontale, in verticale o in diagonale.

La prima cosa da fare, quindi, è creare un model che rifletta quanto appena detto.

Scriviamo un enum che rappresenti lo stato di una casella. Può essere vuota, occupata da noi o dal computer.

Swift

enum SquareStatus {
    case empty
    case visitor
    case home
}

Per giocare ci serve una scacchiera 3x3. Proviamo quindi a definire il model di una singola casella:

Swift

class Square: BindableObject {
    let didChange = PassthroughSubject<Void, Never>()
    
    var status: SquareStatus {
        didSet {
            didChange.send(())
        }
    }
    
    init(status: SquareStatus) {
        self.status = status
    }
}

La classe Square adotta il protocollo BindableObject. Gli oggetti che adottano questo protocollo notificano i subscriber nel framework SwiftUI quando una o più delle loro proprietà cambiano.

Per farlo bisogna adottare correttamente il protocollo, aggiungendo un'istanza che pubblica un evento quando l'oggetto cambia. Questa istanza si chiama didChange:

Swift

let didChange = PassthroughSubject <Void, Never> ()

PassthroughtSubject è una classe messa a disposizione dal framework Combine che ci permette di pubblicare una notifica a tutti i richiedenti. La notifica ha due parametri: l'output e un eventuale errore.

Per ora vogliamo solo avvisare tutti che qualcosa è cambiato nell'oggetto Square. Poiché nessuno dei due parametri ci interessa, passiamo Void come primo e Never come secondo. Il primo indica che non passiamo alcun output, il secondo che non c'è possibilità di errore.

Definiamo poi la proprietà status della nostra casella e, al suo interno, aggiungiamo un meccanismo che invia una notifica quando ne cambiamo il valore:

Swift

var status: SquareStatus {
    didSet {
        didChange.send(())
    }
}

Possiamo passare adesso al Model vero e proprio che descrive il gioco e la scacchiera. Lo chiameremo ModelBoard:

Swift

class ModelBoard {
    var squares = [Square]()

    init() {
        for _ in 0...8 {
            squares.append(Square(status: .empty))
        }
    }

Cominciamo dichiarando la variabile array che conterrà le singole caselle della scacchiera. Nella funzione init aggiungiamo 9 elementi di tipo Square, tutti con status .empty

A fine partita ci servirà un metodo per riportare il gioco allo stato iniziale:

Swift

func resetGame() {
    for i in 0...8 {
        squares[i].status = .empty
    }
}

Ora serve un modo per controllare se la partita è finita.

Una partita finisce quando non ci sono più caselle libere oppure quando uno dei due giocatori allinea tre simboli prima dell'altro.

Swift

var gameOver: (SquareStatus, Bool) {
    get {
        if thereIsAWinner != .empty {
            return (thereIsAWinner, true)
        } else {
            for i in 0...8 {
                if squares[i].status == .empty {
                    return (.empty, false)
                }
            }
            return (.empty, true)
        }
    }
}

La variabile getter thereIsAWinner controlla semplicemente tutte le combinazioni vincenti:

Swift

private var thereIsAWinner:SquareStatus {
    get {
        if let check = self.checkIndexes([0, 1, 2]) {
            return check
        } else  if let check = self.checkIndexes([3, 4, 5]) {
            return check
        }  else  if let check = self.checkIndexes([6, 7, 8]) {
            return check
        }  else  if let check = self.checkIndexes([0, 3, 6]) {
            return check
        }  else  if let check = self.checkIndexes([1, 4, 7]) {
            return check
        }  else  if let check = self.checkIndexes([2, 5, 8]) {
            return check
        }  else  if let check = self.checkIndexes([0, 4, 8]) {
            return check
        }  else  if let check = self.checkIndexes([2, 4, 6]) {
            return check
        }
        return .empty
    }
}

La funzione checkIndex prende in input un array di interi (gli indici) e restituisce un SquareStatus opzionale: .home o .visitor se c'è un vincitore, nil altrimenti:

Swift

private func checkIndexes(_ indexes: [Int]) -> SquareStatus? {
    var homeCounter:Int = 0
    var visitorCounter:Int = 0
    for anIndex in indexes {
        let aSquare = squares[anIndex]
        if aSquare.status == .home {
            homeCounter = homeCounter + 1
        } else if aSquare.status == .visitor {
            visitorCounter = visitorCounter + 1
        }
    }
    if homeCounter == 3 {
        return .home
    } else if visitorCounter == 3 {
        return .visitor
    }
    return nil
}

Ci serve un modo per fare una mossa. Per il giocatore umano controlliamo se la casella selezionata è vuota. Se lo è, ne cambiamo lo status in .home

Dato che implementiamo solo una partita Uomo contro Macchina, alla fine dobbiamo anche far partire la mossa del computer.

Swift

func makeMove(index: Int, player:SquareStatus) -> Bool {
    if squares[index].status == .empty {
        squares[index].status = player
        if player == .home { aiMove() }
        return true
    }
    return false
}

La mossa dell'intelligenza artificiale è davvero semplice: si estrae un indice a caso, si controlla se la casella è vuota e, in caso affermativo, la si riempie con il flag .visitor.

Swift

private func aiMove() {
    var anIndex = Int.random(in: 0 ... 8)
    while (makeMove(index: anIndex, player: .visitor) == false && gameOver.1 == false) {
        anIndex = Int.random(in: 0 ... 8)
    }
}

Ora che il model è pronto, dobbiamo interagire con SwiftUI per costruire una View che rispetti il model Square. Chiamiamola SquareView:

Swift

struct SquareView: View {
    @ObjectBinding var dataSource:Square
    var action: () -> Void
    var body: some View {
        Button(action: {
            self.action()
        }) {
            Text((dataSource.status != .empty) ?
                (dataSource.status != .visitor) ? "X" : "0"
                : " ")
                .frame(minWidth: 60, minHeight: 60)
                .background(Color.gray)
                .padding(EdgeInsets(top: 4, leading: 4, bottom: 4, trailing: 4))
        }
    }
}

Prima di tutto aggiungiamo il property wrapper @ObjectBinding davanti al datasource Square.

In questo modo diciamo a SwiftUI che la SquareView è interessata alle notifiche di cambiamento del model. Quando ne arriverà una, SwiftUI farà calcolare automaticamente un nuovo body alla SquareView.

Dentro il body controlliamo se lo status è diverso da .empty. In tal caso scriviamo X oppure O a seconda del giocatore.

.frame, .background e .padding sono solo ritocchi estetici della casella.

Infine dobbiamo modificare la ContentView per ospitare la scacchiera, creando a questo scopo una variabile private che chiamiamo checker:

Swift

struct ContentView : View {
    private var checker = ModelBoard()
    @State private var isGameOver = false

Definiamo anche una proprietà @State per sapere se la partita è finita: deve essere @State perché vogliamo aggiornare il body della ContentView una volta terminato il gioco.

Poiché ogni SquareView è identica e il suo comportamento cambia solo in base all'indice, definiamo anche un metodo buttonAction:

Swift

func buttonAction(_ index: Int) {
    _ = self.checker.makeMove(index: index, player: .home)
    self.isGameOver = self.checker.gameOver.1
}

In questo modo ogni SquareView invoca il metodo con il proprio indice e viene eseguito il codice relativo alla posizione indicata.

Infine possiamo costruire il body completo, che riflette le 9 SquareView (3 righe da 3):

Swift

var body: some View {
    VStack {
        HStack {
            SquareView(dataSource: checker.squares[0]) { self.buttonAction(0) }
            SquareView(dataSource: checker.squares[1]) { self.buttonAction(1) }
            SquareView(dataSource: checker.squares[2]) { self.buttonAction(2) }
        }
        HStack {
            SquareView(dataSource: checker.squares[3]) { self.buttonAction(3) }
            SquareView(dataSource: checker.squares[4]) { self.buttonAction(4) }
            SquareView(dataSource: checker.squares[5]) { self.buttonAction(5) }
        }
        HStack {
            SquareView(dataSource: checker.squares[6]) { self.buttonAction(6) }
            SquareView(dataSource: checker.squares[7]) { self.buttonAction(7) }
            SquareView(dataSource: checker.squares[8]) { self.buttonAction(8) }
        }
    }

Un'ultima cosa riguarda il feedback per l'utente: vogliamo avvisarlo con un popup quando la partita finisce o quando qualcuno vince.

Per farlo possiamo usare il View modifier .presentation. Nella sua forma più semplice accetta:

Un booleano condizionale che decide se mostrarlo o no
Un parametro message con un Text per il corpo dell'alert
Un dismissButton: con un Alert.Button

Swift

.presentation($isGameOver) { () -> Alert in
    Alert(title: Text("Game Over"),
          message: Text(self.checker.gameOver.0 != .empty ?
            (self.checker.gameOver.0 == .home) ? "You Win!" : "iPhone Wins!"
            : "Parity"), dismissButton: Alert.Button.destructive(Text("Ok"), onTrigger: {
                self.checker.resetGame()
            }) )
}

Ed è tutto! Come promesso, in meno di 160 righe di codice abbiamo un TicTacToe perfettamente funzionante. Se facciamo Build and Run, la nostra applicazione apparirà così:

iPadOS, Catalyst e Sidecar

2019-06-17T00:00:00Z

Avevo deciso di non parlare ed esprimere commenti sul nuovo iPad Pro sin dalla sua prima uscita. In fondo, pensavo si trattase dell’ennesima mossa commerciale di una Apple con al comando Tim Cook – abile uomo d’affari e solo lontanamente visionario – che mira al profitto ed alla vendita in un segmento commerciale oramai saturo. No, parlarne avrebbe solo alimentato il brusio dei blogs e dei fanatici, in un modo o nell’altro.

Mi sbagliavo. Questo prodotto merita tutta la nostra attenzione per una serie di ragioni che proverò a raccontarvi.

Andiamo per ordine. Il mercato dei tablet è saturo ed in discesa vertiginosa. KGI, sostiene che insieme ad iPhone contribuirà ad un calo mai visto, durante il periodo 2016/2020, delle vendite di dispositivi iOS. Sarà anche vero, ma questo non significa che non ci sia spazio per innovare.

Probabilmente l’utente medio coglierà queste innovazioni con ritardo o forse non le coglierà proprio, ma questo non significa che a Cupertino non stiano provando ad innovare. Quello che ci si aspetta da un Tablet – e che Phil Schiller ha teatralmente raccontato durante la presentazione del 21 Marzo 2016 – è l’abilità di rimpiazzare in tutte le attività quotidiane i nostri vecchi personal computer. Apple sostiene dalla prima introduzione di iPad Pro che il nuovo iPad è il sostituto ideale del «noioso» PC anni ‘80. Meglio, è l’interpretazione in chiave moderna del modo di esprimersi, creare, studiare e divertirsi. Sarà vero?

Approfittando delle novità presentate alla WWDC 2019, ho deciso di effettuare un test approfondito con un iPad Pro per capirne lo stato dell’arte e quanto la proposizione di cui sopra sia vicina alla realtà. Non ho usato la tastiera venduta come accessorio per una semplice ragione: si può usare solo in una posizione forzata (quindi niente scrittura estrema sul divano o nel letto) e costa uno sproposito. Per questa mia settimana di prova ho deciso di usare una molto più performante e confortevole tastiera Apple bluetooth; ho la libertà di muovermi e mettermi come e dove voglio. Oltretutto, quando sono in mobilità non vedo proprio cosa potrei farmene di una tastiera fisica in generale.

Apple pencil, invece, è spettacolare. L’uso della matita è così radicato nella nostra cultura moderna che usarne una con un iPad risulterà quasi più naturale delle dita stesse (per alcune attività le dita continuano ad essere superiori in termini di efficacia e riscontro).

Anche la nuova revisione della penna ha fatto passi da gigante rispetto alla prima versione che aveva un cappuccio per nascondere il jack di ricarica praticamente perso prima ancora di aprire la confezione, nessun alloggiamento dove conservare la penna nell’iPad con sicurezza e, tralascerei volentieri questo dettaglio, un meccanismo di ricarica davvero controverso.

Sicuramente siamo ad un punto di svolta, ma dire che il nuovo iPad è un sostituto del personal computer è quantomeno una forzatura. Il mio mestiere è scrivere applicazioni oltre che coordinare un team di sviluppatori. Tutte operazioni che definisco «complesse» non per il loro contenuto, ma per la modalità di espletarle. Immaginate una giornata tipo con un centinaio di email a cui rispondere, una ventina di telefonate su cui prendere appunti, due o tre progetti Xcode aperti su cui fare revisione del codice ed una infinità di documenti da consultare, annotare e scrivere. Sono assolutamente convinto che questo mestiere sia dannoso per la propria salute mentale e fisica, ma oramai è troppo tardi per cambiare rotta ed in fondo, mi piace molto.

Chiaramente, con queste premesse, l’iPad Pro non può assolutamente essere un sostituto del mio MacBook Pro: ci sono troppe cose che risultano più macchinose e meno precise. Così come ci sono operazioni che risultano estremamente semplici, veloci ed efficaci. Prendere appunti, rispondere alle email, scrivere quest’articolo e comunicare è di una semplicità disarmante.

Non fraintendetemi, non è un discorso di potenza: il nuovo iPad ne ha da vendere e basta fare una piccola ricerca per vedere l’esplosione rigogliosa di centinaia di comparazioni di potenza tra iPad e Macbook. Siamo davanti ad un gioiello, in termini di tecnologia, che non ha nulla da invidiare ad un portatile di fascia alta.

Fortunatamente per noi, il problema è un altro. È evidente che iOS per come lo conosciamo mostra i suoi limiti. Per chi ha avuto modo di usare e lavorare con la prima versione di iOS non potrà che notare gli incredibili cambiamenti e sforzi che sono stati fatti negli anni. iOS7 ha cambiato il nostro modo di pensare le interfacce; iOS8 ci ha mostrato che non è una questione di quante applicazioni riesci a tenere aperte in contemporanea ma di come le fai dialogare tra loro; iOS9 ha consolidato la comunicazione tra dispositivi rendendo un piacere per la mente il passaggio da un dispositivo all’altro. iOS 10, 11 e 12 sono stati un continuo affinare dettagli di stabilità , stilistici, di usabilità e di esperienza che pochi altri nel mondo del software hanno avuto il coraggio di fare in un periodo così lungo: ci vuole coraggio a non inondare ogni nuovo rilascio del sistema operativo con funzionalità poco testate, poco usabili e poco studiate.

Mancava ancora qualcosa per chiudere il cerchio. Questo qualcosa Microsoft ha provato, a suo modo, a rappresentarlo con Windows 10 e Microsoft Surface. Google prova a rappresentarlo da anni con il concetto di un web (e di un browser) confluente in cui è possibile fare tutto, aspettando che arrivi Fuchsia.

Apple, invece, con una mossa a sorpresa, ha mostrato la sua visione della tanto agognata convergenza tra i dispositivi. Sto parlando di iPadOS e di Catalyst.

Essere una grande azienda non è facile. Ti confina dietro una difficile posizione in cui tutti si aspettano sempre “qualcosa in più”. Apple, dunque, doveva rendere questo concetto in maniera diversa — Think different, direbbe qualcuno.

Nessun utente Apple si sarebbe accontentato di avere il desktop e la barra di Finder sul proprio iDispositivo. D’altronde si sa, gli utenti Apple sono un pò più esigenti e creativi.

E così, ecco arrivare iPadOS. Non è un nuovo sistema operativo ma, semplicemente, una estensione di quell’iOS che oramai siamo stati abituati ad usare ed amare. Estensioni che ne abilitano funzionalità nuove e mai viste: Multitasking, Desktop e funzionalità di interconnessione che tutti avevamo solo sognato. Dando un occhiata da vicino alle API disponibili con iOS13, si nota che ci sono un’infinità di nuove risorse per creare drivers e meccanismi di comunicazione ed interfaccia USB. Fantastico.

Non credo ci sarà una convergenza piatta e scontata come quella che ci ha mostrato e raccontato Microsoft. Non credo che succederà mai che lo schermo del mio Macbook diventi touch. Allo stesso tempo, però, vedo che portare un’applicazione nativa su macOS da iPad è un gioco da ragazzi e che lo schermo del mio iPad può diventare quella superficie tattile tanto desiderata con cui colloquiare con il proprio computer attraverso Sidecar.

Apple, proverà a mostrare come lo stile e la visione d’insieme, prima di tutto, possano essere il principio di un cambiamento sottile ed elegante, ma non per questo meno efficace, al nostro modo di dialogare con le macchine.

A mio personale modo di vedere, questo giugno la WWDC ha presentato davvero tante grandi novità, tra queste l’introduzione di iPadOS, Continuity e Catalyst.

Sarà probabilmente un evento che resterà nella storia e che segnerà un passaggio epocale per tutti quelli che hanno ancora bisogno del vecchio desktop e della barra di Finder per lavorare. Se non mi credete, provate a collegare una tastiera al nuovo iPad Pro e premete ⌘+Tab.

Programmare con SwiftUI

2019-06-13T00:00:00Z

SwiftUI segna senza dubbio l'inizio di una nuova era nella storia della programmazione Apple. Negli ultimi anni abbiamo visto moltiplicarsi i framework basati sull'idea di interfacce dichiarative e di programmazione reattiva. Il web ne è l'esempio più evidente, ma non mancano casi importanti anche nello sviluppo mobile. Siamo continuamente bombardati da messaggi di marketing secondo cui:

mantenere un'unica codebase per tutte le piattaforme è il modo migliore per aumentare la produttività aziendale e offrire soluzioni efficaci ai nostri clienti.

React Native (Facebook) e Flutter (Google) sono un ottimo esempio di questa proposta. Non è lo scopo di questo articolo confrontare queste tecnologie: ho citato i due esempi per mostrare come la tendenza del software negli ultimi anni stia andando in direzioni diverse da quelle a cui siamo stati abituati finora.

I nostri dispositivi sono sempre più potenti, e questa potenza trova il suo posto naturale in interfacce e paradigmi di interazione sempre più sofisticati e complessi. L'anno scorso ho scritto un pezzo sull'uscita di iPhone X e sulla sensazione di fluidità che questo nuovo dispositivo, insieme alle ultime scelte stilistiche di iOS 11 e 12, mi aveva lasciato.

Animazioni morbide, continue e coerenti, gesture integrate nell'esperienza di navigazione. Sono solo alcuni esempi di ciò che voglio dire: l'asticella delle aspettative si è alzata ancora una volta, e queste novità non si esprimono facilmente con un framework tradizionale.

La natura discreta dei linguaggi imperativi fatica a reggere il confronto con il senso di continuità e fluidità imposto dai nuovi paradigmi di interfaccia.

Apple è sempre stata un'azienda molto conservatrice (Objective-C continua a funzionare e a compilare benissimo) per quanto riguarda i suoi ambienti di sviluppo e, in generale, l'intero ecosistema.

L'introduzione di Swift cinque anni fa, con i suoi nuovi paradigmi e il suo slancio di modernità, era già stato un grande segnale di cambiamento da parte di Cupertino. Ma era chiaro che non bastava. Così, a sorpresa per tutti, arriva la risposta di Apple agli altri giganti del web: SwiftUI.

SwiftUI è un framework dichiarativo orientato ai componenti. Dimentichiamo quindi il pattern MVC, in cui i controller facevano da mediatori tra view e model. In SwiftUI abbiamo solo uno stato e una view derivata dallo stato. Non appena lo stato cambia, SwiftUI ricostruisce l'interfaccia tenendo conto delle modifiche.

In una serie di post cercherò di condividere i miei pensieri e i miei appunti di viaggio personali durante lo studio di questo framework nuovo e, per certi versi, misterioso.

Ho pensato che potesse essere utile, nella speranza che sia un punto di partenza per imparare qualcosa di nuovo e davvero entusiasmante.

Happy Coding!

WWDC18: ARKit 2, confronto delle prestazioni del tracking 2D

2018-06-18T00:00:00Z

Uno dei trend tecnologici più interessanti dell'ultimo anno è stato di sicuro la realtà aumentata. Tutti i grandi nomi hanno fatto qualcosa in proposito, Apple compresa, che ha investito molte risorse e molto tempo su questo tema e, come ha detto Tim Cook:

…la realtà aumentata potrebbe essere la prossima grande novità…

Se il 2017 è stato l'anno della pietra miliare, con l'introduzione di un framework completo per l'AR, il 2018 è senza dubbio l'anno della maturità di questa tecnologia, grazie ad ARKit 2.

Molte cose sono cambiate a favore di usabilità, manutenibilità e semplicità: tutti aspetti che possono aiutare molto a diffondere una tecnologia presso il grande pubblico. Il resto dell'articolo racconta la mia esperienza personale con il nuovo framework ARKit, sottolineando miglioramenti e differenze tra iOS 11 e iOS 12. Come in ogni buon articolo per sviluppatori, serve un caso di studio su cui lavorare per spiegare meglio l'argomento. Partiamo da questo.

Creeremo una semplice applicazione che usa la realtà aumentata per mostrare offerte speciali e informazioni aggiuntive quando si inquadrano dei biglietti da visita.

Opzionalmente, l'applicazione caricherà le informazioni necessarie da un JSON remoto e mostrerà poi all'utente i relativi arricchimenti visivi quando servono.

Per prima cosa apriamo Xcode e creiamo un nuovo progetto AR, compilando tutti i campi richiesti:

Per impostazione predefinita Xcode crea una scena iniziale del tutto inutile ai fini di questo articolo. Eliminiamola e apriamo il file ViewController.swift creato automaticamente.

Dato che la scena generata automaticamente non ci interessa più, modifichiamo di conseguenza il metodo viewDidLoad. Ci basta assegnare all'outlet sceneView l'istanza giusta come delegate, più qualche opzione utile per il debug.

Swift

override func viewDidLoad() {
 super.viewDidLoad()
 
 sceneView.delegate = self
 
 sceneView.showsStatistics = true
 sceneView.autoenablesDefaultLighting = true
 sceneView.automaticallyUpdatesLighting = true
}

La classe ARSCNView è il punto di ingresso di qualsiasi app AR. Combina i contenuti virtuali con il mondo reale visto attraverso la fotocamera del dispositivo e si occupa anche di molte altre cose interessanti, come mappare i tocchi sulle coordinate del mondo reale. ARSCNView usa un approccio basato su delegate: implementando il suo ARSCNViewDelegate possiamo aggiungere contenuti virtuali a qualsiasi oggetto reale che ARKit rileva automaticamente, quasi per magia.

Come si intuisce, ARKit è il framework responsabile della realtà aumentata. Per funzionare va prima inizializzato correttamente. Aggiungiamo un metodo che lo faccia:

Swift

func resetTrackingConfiguration() {
    guard let referenceImages = ARReferenceImage.referenceImages(inGroupNamed: "Photos", bundle: nil) else { return }
    
  var configuration:ARConfiguration!
    if #available(iOS 12.0, *) {
        configuration = ARImageTrackingConfiguration()
        (configuration as! ARImageTrackingConfiguration).trackingImages = referenceImages
        (configuration as! ARImageTrackingConfiguration).maximumNumberOfTrackedImages = referenceImages.count
    } else {
        configuration = ARWorldTrackingConfiguration()
        (configuration as! ARWorldTrackingConfiguration).detectionImages = referenceImages
    }
    
    let options: ARSession.RunOptions = [.resetTracking, .removeExistingAnchors]
    sceneView.session.run(configuration, options: options)
}

Il metodo resetTrackingConfiguration si occupa di creare e avviare una ARSession che funzioni correttamente, a partire da una ARConfiguration.

ARSession è un oggetto condiviso (singleton) che gestisce la fotocamera del dispositivo e i sensori di movimento, per darci un'esperienza di realtà aumentata completa. I movimenti della camera vengono fusi con i dati dei sensori di inclinazione e di spostamento e con quelli degli altri sensori, in modo da orientare in maniera rapida e coerente il mondo artificiale dentro l'applicazione. L'istanza di ARSCNView creata dallo storyboard contiene già un riferimento alla ARSession condivisa predefinita, quindi non dobbiamo inizializzarla: ci basta creare una ARConfiguration valida.

ARConfiguration è una classe astratta e non la usiamo direttamente. Useremo invece istanze di ARWorldTrackingConfiguration e di ARImageTrackingConfiguration, che ne sono implementazioni concrete. Ce ne sono altre che si occupano solo di tracciare l'orientamento del dispositivo (AROrientationTrackingConfiguration) oppure i volti e le espressioni facciali (ARFaceTrackingConfiguration), ma non sono rilevanti per questa discussione.

ARWorldTrackingConfiguration è la classe principale per le sessioni di world tracking. Introdotta con iOS 11, è in grado di rilevare e tracciare molti elementi interessanti del mondo reale, tra cui oggetti 3D, piani infiniti e immagini 2D. Sono le immagini 2D quelle che interessano a noi; tuttavia iOS 12 introduce una nuova specializzazione della classe astratta ARConfiguration, chiamata ARImageTrackingConfiguration.

Come la sua predecessora, è in grado di tracciare immagini 2D, ma con parecchi miglioramenti, come il tracking in tempo reale e la gestione automatica del caso in cui l'immagine esce dall'inquadratura. Ci torneremo tra poco.

Dato che vogliamo supportare sia iOS 11 sia iOS 12 per poterne confrontare le prestazioni, dobbiamo prevedere configurazioni personalizzate per entrambe le versioni. Se iOS 12 è disponibile, useremo la nuova implementazione di ARConfiguration:

Swift

if #available(iOS 12.0, *) {
 configuration = ARImageTrackingConfiguration()
 (configuration as! ARImageTrackingConfiguration).trackingImages = referenceImages
 (configuration as! ARImageTrackingConfiguration).maximumNumberOfTrackedImages = referenceImages.count
}

altrimenti useremo quella standard:

Swift

else {
 configuration = ARWorldTrackingConfiguration()
 (configuration as! ARWorldTrackingConfiguration).detectionImages = referenceImages
}

in entrambi i casi diciamo alla sessione condivisa di usare la configurazione appena costruita, per tutto il resto della discussione:

Swift

let options: ARSession.RunOptions = [.resetTracking, .removeExistingAnchors]
sceneView.session.run(configuration, options: options)

Ora che abbiamo configurato correttamente la ARSession, ci servono delle immagini da dare in pasto al motore di tracking della ARCamera. Selezioniamo gli Assets del progetto:

e con il tasto destro nella colonna di sinistra creiamo un nuovo AR Resource Group:

Chiamiamolo Photos e aggiungiamo qualche biglietto. La cosa più importante qui è indicare per ogni biglietto le dimensioni reali stimate: il motore 3D ha bisogno di questa informazione per stimare correttamente l'oggetto nel mondo 3D.

Come si vede, uno dei biglietti ha un'icona di avviso. Clicchiamoci sopra:

Xcode ci avverte che l'istogramma e i contrasti del biglietto non sono ottimali per il riconoscimento dell'immagine. Per il momento ignoriamolo.

La nostra app di prova deve poter tracciare immagini 2D e associarle a oggetti del mondo reale tramite gli anchor. ARAnchor è la classe che rappresenta posizione e orientamento nel mondo reale, mappando l'oggetto rilevato in una scena AR. Tra le altre proprietà contiene una matrix_float4x4 che definisce rotazione, traslazione e scala dell'anchor nelle coordinate del mondo.

Swift

open var transform: matrix_float4x4 { get }

Quando si usa una ARWorldTrackingConfiguration o una ARImageTrackingConfiguration, ARKit crea automaticamente gli anchor corrispondenti ogni volta che trova nella scena una corrispondenza con le nostre immagini di riferimento. Dobbiamo solo implementare il relativo delegate, per aggiungere al nuovo anchor l'oggetto corrispondente sotto forma di SCNNode.

Swift

func renderer(_ renderer: SCNSceneRenderer, nodeFor anchor: ARAnchor) -> SCNNode? {
    if let imageAnchor = anchor as? ARImageAnchor {
        let node = SCNNode()
        node.name = anchor.identifier.description
        var labelNode:SCNNode?
        
        switch imageAnchor.referenceImage.name {
        case "card1":
            labelNode = self.addLabel(text: "Hi, Costantino!\nYour loyalties points are 2032.", anchor: imageAnchor)
        case "card2":
            labelNode = self.addLabel(text: "Last tweet from Costantino:\n#WWDC18 #ARKit2 rocks!", anchor: imageAnchor)
        default:
            break
        }
        
        if let labelNode = labelNode {
            node.addChildNode(labelNode)
            
            node.opacity = 0.0
            
            DispatchQueue.main.async {
                node.runAction(SCNAction.fadeIn(duration: 3.0))
            }
            
            return node
        }
    }
    return nil
}

SCNNode è il mattoncino base di tutte le app AR. Unisce le coordinate 3D con gli oggetti della scena, come luci, camera e altri contenuti visualizzabili. Come per le UIView, gli SCNNode seguono una gerarchia ad albero che permette di annidarli con semplici primitive come

Swift

open func addChildNode(_ child: SCNNode)
open func removeFromParentNode()

Il metodo renderer:nodeFor: viene chiamato ogni volta che viene rilevata una nuova corrispondenza tra il nostro insieme di immagini e il mondo reale. Dato che viene chiamato anche per qualsiasi nuovo ARAnchor aggiunto alla scena (piani rilevati, oggetti 3D e così via), conviene verificare che si tratti di un ARImageAnchor per essere sicuri che tutto funzioni come previsto:

Swift

if let imageAnchor = anchor as? ARImageAnchor {
   …
}

poi creiamo un nuovo SCNNode che conterrà tutto il necessario e facciamo uno switch sul nome dell'immagine rilevata: è la logica principale che distingue le immagini del nostro dataset.

Swift

switch imageAnchor.referenceImage.name {
    case “card1”:
    …
    case “card2”:
    …
    default:
    …
 }

infine, se riusciamo a creare un nodo valido, lo aggiungiamo alla gerarchia e restituiamo il nodo principale:

Swift

if let labelNode = labelNode {
 node.addChildNode(labelNode)
 
 …
 return node
}

Per dare un tocco professionale, vogliamo aggiungere animazioni di fade in e fade out a tutto il flusso. Dato che renderer:nodeFor: viene chiamato sul main thread, conviene eseguire runAction in modo asincrono, per essere certi di non avere animazioni scattose.

Swift

DispatchQueue.main.async {
    node.runAction(SCNAction.fadeIn(duration: 3.0))
}

Per i più curiosi

addLabel è un metodo di supporto che genera un oggetto SpriteKit 2D valido. Dato che lavoriamo con immagini 2D tracciate, vogliamo aggiungere alla scena dei contenuti virtuali 2D, per dare all'utente la sensazione che le informazioni aggiuntive compaiano proprio sopra l'oggetto reale.

Swift

func addLabel(text: String, anchor: ARImageAnchor) -> SCNNode {
    let plane = SCNPlane(width: anchor.referenceImage.physicalSize.width,
                         height: anchor.referenceImage.physicalSize.height)
    
    let planeNode = SCNNode(geometry: plane)
    planeNode.eulerAngles.x = -.pi / 2
        
    let skScene = SKScene(size: sceneSize)
    
    skScene.backgroundColor = UIColor(white: 0.0, alpha: 0.0)
    
    let substrings: [String] = text.components(separatedBy: "\n")
    for aSubstring in substrings {
        let lbl = SKLabelNode(text: aSubstring)
        lbl.fontSize = 20
        lbl.numberOfLines = 1
        lbl.fontColor = UIColor.white.withAlphaComponent(0.85)
        lbl.fontName = "Helvetica-Bold"
        let y = CGFloat(substrings.index(of: aSubstring)! + 1) * lbl.fontSize
        lbl.position = CGPoint(x: 20, y: y)
        lbl.horizontalAlignmentMode = .left
        lbl.yScale *= -1
        skScene.addChild(lbl)
    }
    
    let material = SCNMaterial()
    material.isDoubleSided = false
    material.diffuse.contents = skScene
    plane.materials = [material]
    
    return planeNode
}

Per prima cosa creiamo uno SCNPlane con le dimensioni fisiche dell'immagine rilevata. SCNPlane è un oggetto geometrico rettangolare e piatto, che ha il compito di contenere il nostro testo bidimensionale. Ma dato che siamo in un mondo 3D, dobbiamo racchiuderlo in uno SCNNode.

Swift

let planeNode = SCNNode(geometry: plane)
planeNode.eulerAngles.x = -.pi / 2

Dobbiamo anche ruotare il planeNode risultante, perché per impostazione predefinita viene generato perpendicolare alla radice. A questo punto non è ancora stato creato nessun oggetto 2D né alcun testo: per farlo ci serve una scena SpriteKit.

SKScene è l'equivalente di SCNScene nel mondo 2D gestito da SpriteKit. Rappresenta il contenuto di una scena 2D e da sola non ha nulla da mostrare, perché, come la sua gemella 3D, è solo un contenitore. Per generare il testo 2D useremo SKLabelNode, che funziona in modo molto simile alla UILabel di UIKit: si configurano testo, font e altri parametri in modo molto diretto.

Swift

 let lbl = SKLabelNode(text: aSubstring)
 lbl.fontSize = 20
 lbl.numberOfLines = 1
 lbl.fontColor = UIColor.white.withAlphaComponent(0.85)
 lbl.fontName = “Helvetica-Bold”

Purtroppo non c'è un supporto nativo per andare a capo su più righe con il carattere di ritorno a capo (\n), quindi dobbiamo ricrearlo a mano. Per farlo usiamo una semplice tokenizzazione della stringa originale.

Swift

let substrings: [String] = text.components(separatedBy: “\n”)

for aSubstring in substrings {
    …
}

La parte più interessante è come mappiamo il contenuto SpriteKit 2D nel mondo 3D. Per riuscirci usiamo SCNMaterial, la classe che definisce l'aspetto di una geometria 2D quando viene renderizzata in un mondo 3D. Come in ogni motore 3D, la nostra SCNScene ha luci e materiali che reagiscono ad esse in fase di rendering. Ci basta indicare al nostro SCNMaterial che vogliamo usare come materiale il contenuto della SKScene creata prima.

Swift

let material = SCNMaterial()
material.isDoubleSided = false
material.diffuse.contents = skScene

La proprietà isDoubleSided è impostata a false, perché non ci interessa il lato posteriore del nostro testo. La proprietà diffuse è di tipo SCNMaterialProperty, un semplice contenitore per la texture del materiale. Per fortuna può contenere quasi qualsiasi cosa, compresa un'intera SKScene. Alla fine diciamo al piano creato prima di usare come sorgente il materiale personalizzato appena preparato.

Swift

plane.materials = [material]

Se avete seguito tutto quello che abbiamo fatto finora ed eseguite il progetto su iOS 12, tutto funzionerà alla perfezione e resterete colpiti da un tracking 2D preciso e convincente. Se invece eseguite lo stesso codice su iOS 11, resterete delusi dalle prestazioni di tracking, piuttosto scarse.

Inoltre c'è un bug davvero fastidioso che lascia per sempre nel mondo 3D le immagini 2D rilevate. Se ricordate, all'inizio dell'articolo ho scritto che

una delle novità più interessanti di ARImageTrackingConfiguration è la nuova gestione degli oggetti che scompaiono dallo schermo.

Dato che su iOS 11 non c'è niente del genere, dobbiamo costruirci da soli un workaround. Useremo una struct privata per tenere tutte le informazioni necessarie:

Swift

struct SANodeAnchor {
 var date:Date
 var node:SCNNode
 var anchor:ARAnchor
}

dichiarandone un array privato nel nostro ViewController. Ci serve anche un polling periodico della scena, per eliminare gli oggetti non più validi

Swift

private var lastUpdate = [String:SANodeAnchor]()
private var scheduledTimer:Timer?

il nostro metodo viewDidAppear si occuperà di definire il timer qui sopra

Swift

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    
    if #available(iOS 12.0, *) {
        
    }
    else {
        if let scheduledTimer = scheduledTimer {
            scheduledTimer.invalidate()
        }
        scheduledTimer = Timer.scheduledTimer(withTimeInterval: 3.0, repeats: true) { [unowned self] (timer) in
            for (_, nodeStruct) in self.lastUpdate {
                if Date().timeIntervalSinceNow - nodeStruct.date.timeIntervalSinceNow > 3 {
                    nodeStruct.node.removeFromParentNode()
                    self.sceneView.session.remove(anchor: nodeStruct.anchor)
                }
            }
        }
    }
}

Dobbiamo solo aggiornare l'array di cache lastUpdate quando oggetti nuovi o già rilevati vengono interpretati correttamente nella scena. Per questo useremo un altro metodo delegate di ARSCNViewDelegate:

Swift

func renderer(_ renderer: SCNSceneRenderer, didUpdate node: SCNNode, for anchor: ARAnchor) {
    if let identifier = node.name {
        let aStruct = SANodeAnchor(date: Date(), node: node, anchor: anchor)
        lastUpdate[identifier] = aStruct
    }
}

In questo modo anche su iOS 11 riusciamo a smettere di tracciare gli oggetti 2D indesiderati sullo schermo.

Il progetto completo è disponibile su Github. Mentre scrivo, un bug affligge Xcode 10 e impedisce di usare le immagini del dataset quando si installa l'app su dispositivi con iOS 11.

Di conseguenza, su iOS 11 l'app non rileverà nessuna immagine 2D se installata da Xcode 10. Per aggirare il problema, bisogna eseguire il progetto qui sopra con Xcode 9 quando lo si installa su un dispositivo con iOS 11, commentando i simboli sconosciuti legati ad ARImageTrackingConfiguration.

Caricare i dataset da remoto

Una nota finale sul caricamento dinamico del dataset. Il codice qui sopra si basa su un dataset statico, memorizzato nel progetto. Potrebbe però essere meglio caricare il dataset dinamicamente da un server remoto. Per questo ho preparato un semplicissimo esempio in JSON.

Codice

[
 {
  "imageURL" : "https://www.sofapps.it/card1.jpg",
  "name" : "card1",
  "width" : 0.096
 },
 {
  "imageURL" : "https://www.sofapps.it/card2.jpg",
  "name" : "card2",
  "width" : 0.058
 }
]

Scarichiamo questo JSON dalla nostra app:

Swift

func loadRemotedataset(fromURL: URL, _ completion: @escaping ([Card]?, Error?)->Void) {
    URLSession.shared.dataTask(with: fromURL) { (data, response, error) in
        if let error = error {
            DispatchQueue.main.async {
                completion(nil, error)
            }
        }
        else if let data = data {
            var retArray = [Card]()
            do {
                if let json = try JSONSerialization.jsonObject(with: data, options: .allowFragments) as? [[String:Any]] {
                    for aRow in json {
                        if let aString = aRow["imageURL"] as? String,
                            let anURL = URL(string: aString),
                            let aName = aRow["name"] as? String,
                            let width = aRow["width"] as? CGFloat
                        {
                            retArray.append(Card(url: anURL, name: aName, width: width))
                        }
                    }
                    DispatchQueue.main.async {
                        completion(retArray, nil)
                    }
                }
                else {
                    throw NSError(domain: "JSON parse error", code: -1, userInfo: nil)
                }
            }
            catch {
                DispatchQueue.main.async {
                    completion(nil, error)
                }
            }
        }
    }.resume()
}

e carichiamo i biglietti in modo dinamico:

Swift

func createDataset(_ completion: @escaping ([ARReferenceImage]?, Error?) -> Void) {
    self.loadRemotedataset(fromURL: URL(string: "https://www.sofapps.it/sampleDataset.json")!) { (response, error) in
        if let error = error {
            print("something happened in the way to heaven...", error)
            completion(nil, error)
        }
        else if let response = response {
            var retArray = [ARReferenceImage]()
            for aCard in response {
                let response = URLSession.shared.synchronousDataTask(with: aCard.url)
                if let error = response.2 {
                    print("something happened in the way to heaven...", error)
                }
                else if let data = response.0, let anImage = UIImage(data: data) {
                    var orientation = CGImagePropertyOrientation.up
                    switch anImage.imageOrientation {
                    case .up:
                        orientation = .up
                    case .down:
                        orientation = .down
                    case .left:
                        orientation = .left
                    case .right:
                        orientation = .right
                    default:
                        orientation = .up
                    }
                    if let cgImage = anImage.cgImage {
                        let aReferenceImage = ARReferenceImage.init(cgImage, orientation: orientation, physicalWidth: aCard.width)
                        aReferenceImage.name = aCard.name
                        retArray.append(aReferenceImage)
                    }
                }
            }
            completion(retArray, nil)
        }
    }
}

anche il nostro metodo resetTrackingConfiguration va adattato per tenere conto del caricamento a runtime:

Swift

func resetTrackingConfiguration() {
    self.createDataset { [weak self] (referenceImages, error) in
        if let error = error {
            print("oops!, something happened on the way to heaven...", error)
        }
        else if let referenceImages = referenceImages {
            var configuration:ARConfiguration!
            
            if #available(iOS 12.0, *) {
                configuration = ARImageTrackingConfiguration()
                (configuration as! ARImageTrackingConfiguration).trackingImages = referenceImages
                (configuration as! ARImageTrackingConfiguration).maximumNumberOfTrackedImages = referenceImages.count
            } else {
                configuration = ARWorldTrackingConfiguration()
                (configuration as! ARWorldTrackingConfiguration).detectionImages = Set(referenceImages.map { $0 })
            }
            
            let options: ARSession.RunOptions = [.resetTracking, .removeExistingAnchors]
            self?.sceneView.session.run(configuration, options: options)
        }
    }
}

A questo punto l'app dovrebbe funzionare sia su iOS 11 sia su iOS 12, caricando dinamicamente dal server il contenuto del dataset.

Buon coding!

Riferimenti

Un workflow di sharing personalizzato con CloudKit

2018-06-02T00:00:00Z

CloudKit dà grande importanza alla privacy e alla sicurezza degli utenti. Poiché una delle preoccupazioni principali del mio ultimo lavoro, Lookii, riguardava proprio la privacy degli utenti, è stata un'ottima occasione per approfondire le reali potenzialità del framework.

Da iOS 10 CloudKit include una funzionalità integrata per condividere dati privati tra i partecipanti di un container, chiamata CKShare. Purtroppo online ci sono pochissimi articoli sull'argomento e la documentazione di Apple non entra nel dettaglio dei temi avanzati. Tutti gli articoli che ho citato nelle note descrivono il flusso base della condivisione con CloudKit, con alcune varianti interessanti che però non si adattavano esattamente al mio caso. Non tratterò le basi, per le quali rimando alle note. Mi concentrerò invece su un workflow specifico e più avanzato, che potrebbe essere utile a qualcun altro.

Il caso d'uso

Immaginiamo di avere un'applicazione che condivide informazioni degli utenti. Alcune devono restare private ed essere condivise solo tra amici, altre invece devono essere accessibili pubblicamente a tutti i partecipanti del container.

Supponiamo che il nostro tipo di CKRecord sia MyUser e contenga le seguenti informazioni pubbliche:

Swift

firstName: String
lastName: String
thumbnail: Data
privateShareUrl: String

Altri dati non saranno pubblici, per ragioni di privacy. Per questi useremo un altro CKRecord, che chiameremo PrivateInfo, con il seguente contenuto:

Swift

phoneNumber: String
email: String

Stavolta il record non farà parte del database pubblico. Verrà invece salvato in quello privato, accessibile solo al proprietario del record, e inserito in una RecordZone che sarà condivisa con i partecipanti scelti.

Uno schema generale del caso d'uso descritto potrebbe essere questo:

Il workflow generale di CloudKit e i suoi limiti

Come detto, una delle preoccupazioni principali nell'usare il workflow di sharing predefinito di CloudKit riguardava le opzioni di personalizzazione della UI, molto limitate. In particolare il workflow base segue uno schema molto rigido:

Chi condivide deve occuparsi di:

Creare il CKShare
Passarlo a una specifica UICloudSharingController
Creare un URL da condividere con app di terze parti

Gli utenti che vogliono essere aggiunti devono:

Toccare il link per accettare l'URL condiviso
Implementare alcuni delegate in UIApplication

Anche se la sua linearità lo rende facilissimo da integrare, questo approccio manca di alcune funzionalità avanzate. Per esempio, non vorrei disturbare gli utenti con flussi complicati che interrompono la naturale esperienza dell'app. Vorrei invece eseguire il workflow il più possibile in background, liberando mittente e destinatario da dialoghi inutili e da cambi di contesto tra un'app e l'altra.

Sarebbe bello poter scegliere i destinatari delle mie informazioni private semplicemente toccando l'icona dell'utente nella mia app.

Implementazione

La prima cosa da fare è abilitare la userDiscoverability tra gli utenti dell'app, altrimenti il resto del processo non funzionerà a causa dei vincoli di privacy.

Per fortuna Apple ha previsto un approccio molto semplice: basta una semplice richiesta di permesso all'utente, che potete inserire nelle prime fasi della vita dell'app:

Swift

//ask for userDiscoverability otherwise you will obtain nil each time you try to search for him
CKContainer.default().requestApplicationPermission(CKApplicationPermissions.userDiscoverability) { (status, error) in
    switch status {
    case .granted:
        print("granted")
    case .denied:
        print("denied")
    case .initialState:
        print("initial state")
    case .couldNotComplete:
        print("an error as occurred: ", error ?? "Unknown error")
    }
}

Una volta ottenuto il permesso dell'utente siamo pronti a partire. Creiamo un CKRecord utente molto semplice (quello che sarà pubblico):

Swift

func createPublicRecord() {
    let aRecord = CKRecord(recordType: "MyUser")
    aRecord.setObject("John" as CKRecordValue, forKey: "firstName")
    aRecord.setObject("Appleseed" as CKRecordValue, forKey: "lastName")

    let container = CKContainer.default()
    let publicDatabase = container.publicCloudDatabase
    
    publicDatabase.save(aRecord, completionHandler: { (record, error) -> Void in
        if let error = error {
            print(error)
        }
        else {
            print("record saved successfully")
        }
    })
}

Poi, come parte del processo iniziale, dobbiamo creare una zona specifica con cui esporre una vista dei nostri record privati agli utenti scelti (i nostri amici preferiti):

Swift

func createFavZone(completionHandler:@escaping (CKRecordZone?, Error?)->Void) {
    let container = CKContainer.default()
    let privateDatabase = container.privateCloudDatabase
    let customZone = CKRecordZone(zoneName: "FavZone")
    
    privateDatabase.save(customZone, completionHandler: ({returnRecord, error in
        completionHandler(returnRecord, error)
    }))
}

Infine creiamo un record privato che contiene tutte le nostre informazioni preziose:

Swift

func createPrivateRecord() {
    let container = CKContainer.default()
    let privateDatabase = container.privateCloudDatabase

    let recordZone: CKRecordZone = CKRecordZone(zoneName: "FavZone")
    let aRecord = CKRecord(recordType: "PrivateInfo", zoneID: recordZone.zoneID)

    aRecord.setObject("+393331112223" as CKRecordValue, forKey: "phoneNumber")
    aRecord.setObject("john@appleseed.com" as CKRecordValue, forKey: "email")

    
    privateDatabase.save(aRecord, completionHandler: { (record, error) -> Void in
        if let error = error {
            print(error)
        }
        else {
            print("record saved successfully")
        }
    })
}

Notate che il record è legato alla CKRecordZone creata prima.

Come avrete notato, non abbiamo ancora scritto il campo privateShareUrl che fa parte del record pubblico: è la parte cruciale di tutto l'approccio descritto in questo articolo. Il comportamento standard, infatti, si basa sulla UICloudSharingController, che mostra all'utente un dialogo in cui si sceglie cosa e come condividere. Il risultato del dialogo è un URL da usare con app di terze parti come Messaggi, Mail o altro per comunicare l'intenzione di condividere qualcosa.

A peggiorare le cose, dall'altra parte il destinatario deve toccare il link che a sua volta apre la nostra app e chiama il corrispondente metodo delegate di UIApplication. Quest'ultimo ci restituisce alla fine un'istanza di CKShareMetadata, che possiamo usare per leggere le informazioni condivise.

Il nostro approccio

Poiché la nostra applicazione ha già degli utenti, vorrei aggirare questo workflow usando il campo privateShareUrl come punto di ingresso per chiunque abbia bisogno di leggere le informazioni private di uno specifico utente.

Apple dichiara che l'URL di condivisione di un CKShare è stabile e non cambia a meno che non si cambi il root record associato.

Il mio piano è simulare il workflow base di sharing usando il campo privateShareUrl che abbiamo nel database pubblico per ogni utente. Questo campo conterrà l'URL originale del CKShare. In questo modo ogni utente che vuole leggere le informazioni private di uno specifico partecipante accederà all'URL e verificherà se ha il permesso di accedere ai campi privati esposti.

Gli utenti che vogliono condividere le proprie informazioni private con gli amici, invece, possono semplicemente aggiungerli all'URL di condivisione, senza disturbare i destinatari con app di terze parti e messaggi. Ottimo!

La prima cosa da fare è impostare un accesso predefinito pari a nessuno per le nostre informazioni private. In questo modo, nello stato iniziale, nessuno può accedere ai nostri dati privati. Solo quando aggiungiamo qualcuno alla condivisione potrà accedere ai dati. Apple dichiara che il permesso pubblico predefinito di un CKShare è già configurato su nessun accesso.

Swift

func createDefaultShareProfileURL() {
    let container = CKContainer.default()
    let privateDatabase = container.privateCloudDatabase
    
    let query = CKQuery(recordType: "PrivateInfo", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
    let recordZone: CKRecordZone = CKRecordZone(zoneName: "FavZone")
    
    privateDatabase.perform(query, inZoneWith: recordZone.zoneID) { (results, error) -> Void in
        if let error = error {
            print(error)
        }
        else if let results = results, let ourRecord = results.first {
            let share = CKShare(rootRecord: ourRecord)
            
            let modOp: CKModifyRecordsOperation = CKModifyRecordsOperation(recordsToSave: [ourRecord, share], recordIDsToDelete: nil)
            modOp.savePolicy = .ifServerRecordUnchanged
            modOp.modifyRecordsCompletionBlock = { records, recordIDs, error in
                if let error = error  {
                    print("error in modifying the records: ", error)
                }
                else if let anURL = share.url {
                    let container = CKContainer.default()
                    let publicDatabase = container.publicCloudDatabase
                    let query = CKQuery(recordType: "MyUser", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
                    var myPublicProfile:CKRecord?
                    
                    publicDatabase.perform(query, inZoneWith: nil) { (results, error) -> Void in
                        if let error = error {
                            print("error: ", error)
                        }
                        else if let results = results {
                            for aRecord in results {
                                if aRecord.creatorUserRecordID?.recordName == "__defaultOwner__" {
                                    myPublicProfile = aRecord
                                    break
                                }
                            }
                        }
                        if let myPublicProfile = myPublicProfile {
                            myPublicProfile.setObject(anURL.absoluteString as CKRecordValue, forKey: "privateShareUrl")
                            publicDatabase.save(myPublicProfile, completionHandler: { (record, error) -> Void in
                                if let error = error {
                                    print("error: ", error)
                                }
                                else {
                                    print("all done, folks!")
                                }
                            })
                        }
                    }
                }
            }
            privateDatabase.add(modOp)
        }
    }
}

Ora, ogni volta che un utente vuole vedere le informazioni private condivise da un altro, controllerà il privateShareUrl designato per l'utente in questione:

Swift

func refreshUserInformation(_ userRecordID: CKRecordID) {
    let container = CKContainer.default()
    let publicDatabase = container.publicCloudDatabase
    
    publicDatabase.fetch(withRecordID: userRecordID) { (record, error) in
        if let error = error {
            print(error)
        }
        else if let record = record {
            let firstName = record.object(forKey: "firstName") as? String
            let lastName = record.object(forKey: "lastName") as? String
            
            //do something with firstName and lastName, updating UI
            
            if let shareURL = record.object(forKey: "privateShareUrl") as? String {
                let sharedDatabase = container.sharedCloudDatabase
                let anURL = URL(string: shareURL)!
                
                let op = CKFetchShareMetadataOperation(shareURLs: [anURL])
                op.perShareMetadataBlock = { shareURL, shareMetadata, error in
                    if let error = error {
                        print(error)
                    }
                    else if let shareMetadata = shareMetadata {
                        if shareMetadata.participantStatus == .accepted {
                            let query = CKQuery(recordType: "PrivateInfo", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
                            let zone = CKRecordZoneID(zoneName: "FavZone", ownerName: (shareMetadata.ownerIdentity.userRecordID?.recordName)!)
                            sharedDatabase.perform(query, inZoneWith: zone, completionHandler: { (records, error) in
                                if let error = error {
                                    print(error)
                                }
                                else if let records = records, let firstRecord = records.first {
                                    let phoneNumber = firstRecord.object(forKey: "phoneNumber") as? String
                                    let email = firstRecord.object(forKey: "email") as? String
                                    
                                    //do something with private infos
                                }
                            })
                        }
                        else if shareMetadata.participantStatus == .pending {
                            let acceptOp = CKAcceptSharesOperation(shareMetadatas: [shareMetadata])
                            acceptOp.qualityOfService = .userInteractive
                            acceptOp.perShareCompletionBlock = { meta, share, error in
                                if let error = error {
                                    print(error)
                                }
                                else if let share = share {
                                    let query = CKQuery(recordType: "PrivateInfo", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
                                    let zone = CKRecordZoneID(zoneName: "FavZone", ownerName: (share.owner.userIdentity.userRecordID?.recordName)!)
                                    sharedDatabase.perform(query, inZoneWith: zone, completionHandler: { (records, error) in
                                        if let error = error {
                                            print(error)
                                        }
                                        else if let records = records, let firstRecord = records.first {
                                            let phoneNumber = firstRecord.object(forKey: "phoneNumber") as? String
                                            let email = firstRecord.object(forKey: "email") as? String
                                            
                                            //do something with private infos
                                        }
                                    })
                                }
                            }
                            container.add(acceptOp)
                        }
                    }
                }
                op.fetchShareMetadataCompletionBlock = { error in
                    if let error = error {
                        print(error)
                    }
                }
                container.add(op)
            }
        }
    }
}

Semplice ed efficace. Ho messo insieme un'applicazione di prova con un caso d'uso completo, disponibile su GitHub.

Happy Coding! 🖖🏻

Stored properties ed extension: un approccio Swift puro

2018-03-28T00:00:00Z

Una delle domande più frequenti sulle extension di Swift riguarda le stored properties. Quante volte avete desiderato una stored property nella vostra ultima, fantastica extension, per parametrizzare qualche comportamento?

Come forse sapete, Swift non permette le stored properties nelle extension. È una scelta di design: "Extensions may not contain stored properties."

L'errore più comune è cercare di aggirare il limite con qualcosa del genere:

Swift

extension UIViewController {
    var myStoredProperty:Bool {
        get {
            return self.myStoredProperty
        }
        set(newValue) {
            self.myStoredProperty = newValue
        }
    }
}

Anche se il codice compila senza errori, ci si accorge presto che è completamente sbagliato: il riferimento ciclico alla computed property fa girare il codice in loop finché l'heap non è saturo di chiamate quasi identiche.

Il secondo approccio comune è cercare su Google. Si trovano alcuni trucchetti ingegnosi per aggiungere qualcosa che assomigli al concetto di stored property da usare dentro le extension (vedi i riferimenti).

Uno dei workaround più (ab)usati si affida al runtime di Objective-C, con una soluzione basata sulle funzioni objc_getAssociatedObject e objc_setAssociatedObject.

Anche se queste soluzioni non hanno nulla di sbagliato, un approccio Swift puro sarebbe molto più elegante. È questo il motivo del post: provare a creare un'extension Swift pura con supporto alle stored properties.

La soluzione proposta è molto semplice. Parte dall'assunto che le extension non accettano stored properties ma solo computed properties. Elaborando il concetto di struct, che sono tipi per valore, finiamo per aggirare il design delle extension aggiungendo di fatto il concetto di stored property. Il tutto in puro Swift.

Un proof-of-concept vale più di mille parole. Ecco qui:

Swift

import UIKit

extension UIViewController {
    struct Holder {
        static var _myComputedProperty:Bool = false
    }
    var myComputedProperty:Bool {
        get {
            return Holder._myComputedProperty
        }
        set(newValue) {
            Holder._myComputedProperty = newValue
        }
    }
}

La struct Holder conterrà il valore privato che la nostra computed property espone al mondo, dando l'illusione del comportamento di una stored property.

29/03: Aggiornamento

Come fatto notare da Paolo, anche se l'approccio funziona, andrebbe rivisto almeno in due punti per risolvere quanto segue:

Visibilità private per la struct Holder (al momento chiunque può accedere alle struct statiche di servizio e cambiarne il valore senza ulteriori controlli).
Istanze multiple della classe estesa. L'approccio proposto soffre di un problema molto fastidioso: se si creano più istanze della classe estesa, ogni istanza condividerà lo stesso valore statico della struct Holder. Il problema dipende dalla natura della keyword static. Con un po' di fantasia possiamo essere creativi e risolvere la questione.

Quello che segue dovrebbe fare al caso nostro:

Swift

extension UIViewController {
    private struct Holder {
        static var _myComputedProperty = [String:Bool]()
    }
    
    var myComputedProperty:Bool {
        get {
            return Holder._myComputedProperty[self.debugDescription] ?? false
        }
        set(newValue) {
            Holder._myComputedProperty[self.debugDescription] = newValue
        }
    }
}

Qui abbiamo sfruttato una specie di hash table per conservare tutti i possibili valori che appartengono a istanze diverse della classe. Notate che self.debugDescription è un approccio davvero "grezzo", e andrebbe elaborato un modo più conciso e intelligente per distinguere i riferimenti di istanze diverse. In ogni caso, come poc sembra funzionare.

30/03: Aggiornamento

Non immaginavo che ci fosse un interesse così grande per questo argomento! Grazie a tutti. C'è ancora margine di miglioramento in questo approccio e, dopo una discussione molto cordiale con il mio amico Davide, ho deciso di dare un seguito all'articolo per includere alcuni dei suoi suggerimenti e migliorare l'hash table. Dato che usiamo una static var per emulare una hash table, non c'è più ragione di affidarsi alla struct. D'accordo. Questo farà risparmiare un bel po' di righe di codice. Vorrei anche migliorare il meccanismo della chiave della hash table usando l'indirizzo di memoria, come fanno i puntatori. La nuova versione dell'approccio è la seguente:

Swift

extension UIViewController {
    private static var _myComputedProperty = [String:Bool]()
    
    var myComputedProperty:Bool {
        get {
            let tmpAddress = String(format: "%p", unsafeBitCast(self, to: Int.self))
            return UIViewController._myComputedProperty[tmpAddress] ?? false
        }
        set(newValue) {
            let tmpAddress = String(format: "%p", unsafeBitCast(self, to: Int.self))
            UIViewController._myComputedProperty[tmpAddress] = newValue
        }
    }
}

Molto, molto meglio! C'è ancora un piccolo problema di "memory leak", ma questa è un'altra storia.

Happy swifty coding! 🖖🏻

Creiamo un accessorio per HomeKit

2018-02-01T00:00:00Z

Quest’articolo vuole essere una breve guida introduttiva su come creare un accessorio compatibile con HomeKit sfruttando componentistica di riuso ed open source. Alla fine dell’articolo, se avrete seguito correttamente tutti i passi, potrete giocare con un telecomando per il vostro cancello automatico di casa comandabile ed azionabile con Siri / HomeKit. Come bonus, avrete la possibilità di aggiungere un sensore ambientale di umidità/temperatura.

Ingredienti:

1x Raspberry PI3
1x Arduino YUN (opzionale)
1x Telecomando cancello automatico RF 433Mhz
1x Transistor NPN
1x Resistenza 2.2k
1x Qualche cavo
1x DHT22 (opzionale)
5x Pazienza

Background

HomeKit è il protocollo di Apple a cui gli sviluppatori ed aziende che creano hardware e dispositivi per la domotica devono aderire se intendono essere compatibili con l’assistente vocale Siri e l’applicazione Home installati di default su tutti i nuovi dispositivi iOS.

HomeKit è un protocollo, ovvero una serie di regole e specifiche a cui i propri servizi devono aderire per potere essere integrati in maniera semplice e veloce con i dispositivi Apple. Il protocollo (nella versione developer no-profit) può essere scaricato e studiato liberamente a patto di accettare prima la licenza Apple annessa. Per maggiori informazioni è possibile andare qui:

developer.apple.comApple Developer documentationUsing the HomeKit Accessory Protocol Specification

Concettualmente, per potere creare qualcosa di funzionante (ed utile) con HomeKit è necessario creare due macro componenti che dialoghino tra di loro:

Un bridge o gateway che parla con il protocollo HomeKit e converte tutti i nostri segnali input / output analogici e digitali in caratteristiche esposte al protocollo HAP.
Una o più caratteristiche in grado di parlare con il server.

Tipicamente, le caratteristiche sono oggetti molto semplici ed elementari (lampadine, interruttori, sensori di temperatura, etc.). Per ragioni di costo e compattezza, dunque, risulta difficile potere implementare su di essi anche la logica di dialogo con il server.

La soluzione più comune che viene adottata dalla maggior parte dei produttori è quella di creare un ulteriore indirezione — denominata HUB — che permette di “raccogliere” più dispositivi elementari sotto un unico raccoglitore che poi si occupa ed ha la capacità logica di parlare con il server; la serie smart living di IKEA e quella di Philips funzionano con questo principio. Ne consegue che le caratteristiche sono più leggere ed economiche al prezzo di un ulteriore oggetto da aggiungere alla catena che in verità non è una grossa complicazione o problema, considerando il fatto che riduce il costo complessivo degli oggetti finali, sensibilmente.

Fortunatamente, per quanto riguarda il gateway è già presente da tempo una implementazione open parecchio stabile e modulare, basata su node e che adotta ed implementa tutte le funzionalità e specifiche richieste per creare un Gateway di accessori per HomeKit richieste dal protocollo HAP.

github.comGitHub HomebridgeHomebridge is a lightweight NodeJS server you can run on your home network that emulates the iOS HomeKit API.

Il funzionamento è molto semplice. Attraverso un file di configurazione si dichiarano gli accessori supportati dal gateway. Questi accessori altro non sono che dei plugin software, rappresentanti particolari caratteristiche esposte. Il file di configurazione è un semplice file JSON e gli accessori sono degli oggetti JSON appartenenti ad un array. Alcuni parametri dei singoli accessori sono obbligatori, altri sono opzionali e dipendono dalle singole implementazioni, essendo dei parametri di inizializzazione specifici.

Implementazione — Gateway

Per prima cosa andremo a configurare il nostro gateway. Per questo compito ho deciso di usare un raspberry PI 3 su cui preventivamente avevo installato raspbian JESSIE:

raspberrypi.orgOperating system images – Raspberry PiThe Raspberry Pi is a tiny and affordable computer that you can use to learn programming through fun, practical projects. Join the global Raspberry Pi community.

Per installare homebridge, invece, vi basterà seguire le istruzioni riportate sulla pagina github del progetto. Io non ho riscontrato nessuna difficoltà.

Una volta completata l’installazione saremo in grado di lanciare il nostro gateway con il comando homebridge. Al primo avvio, il server ci avviserà del fatto che non sono configurati degli accessori e, dunque, l’utilità del gateway è davvero limitata.

Esiste una community molto attiva su npm ed, in pratica, si trova un plugin per quasi tutte le esigenze immaginabili. Nel nostro caso andremo a costruire un accessorio per aprire un cancello automatico, ossia per attuare un interruttore “stateless” di un telecomando RF. Aggiungeremo anche, se lo riteniamo opportuno, un sensore di umidità e temperatura che ci fornirà informazioni importanti (a costo praticamente zero) nella stanza in cui andremo a posizionare il nostro hub homekit.

Prima di passare alla costruzione dei nostri sensori ed alla configurazione del nostro HUB è necessario completare la configurazione del nostro gateway, aggiungendo due moduli in grado di parlare correttamente con i sensori sopra descritti:

npmjs.comhomebridge-http-temperature-humiditySupports https devices on HomeBridge Platform.

npmjs.comhomebridge-http-switch Pluginhomebridge-http-switch is a Homebridge plugin with which you can configure HomeKit switches which forward any requests to a defined http server.

una volta installati, saranno disponibili da subito. ci basterà configurare opportunamente il file config.json di homebridge.

JSON

{
  "bridge": {
    "name": "Home1bridge",
    "username": "CD:32:D2:E1:CC:33",
    "port": 50800,
    "pin": "031-43-153"
    },

  "description": "This is an example configuration file.",

  "accessories": [
    {
      "accessory": "HttpTemphum",
      "name": "Soggiorno",
      "url": "http://yuji.local/arduino/temp",
      "httpMethod": "GET",
      "humidity": true,
      "cacheExpiration": 60
    },
    {
      "accessory": "HTTP-SWITCH",
      "name": "Cancello",
      "switchType": "stateless",
      "onUrl": "http://yuji.local/arduino/switchOn"
    }
  ]
}

Al di la dei parametri banali quali nome e stanza, ogni modulo si aspetta di parlare con un indirizzo HTTP e ricevere determinate risposte per le operazioni richieste; ci basterà implementare questa logica semplice per completare il lavoro. Il gateway, infatti, si occuperà di tutto il resto per parlare correttamente con il protocollo Apple HAP.

Implementazione — HUB e sensoristica

Per costruire il nostro HUB che raggruppa e parla con i sensori, ho deciso di usare un vecchio arduino YUN che avevo comprato per un altro progetto e messo da parte in un cassetto. Tuttavia, se lo preferirete, potrete usare lo stesso raspberry che avete usato per costruire il gateway. Vi basterà riadattare i concetti di cui vi sto per parlare.

Il nostro HUB dovrà implementare un server http che risponda agli endpoint specificati nel file di configurazione di homebridge sopra, restituendo i valori estratti dai nostri sensori collegati ai PIN di input/output del microcontrollore di Arduino.

Prima di scrivere il codice per il nostro arduino, però, facciamo una pausa e dilettiamoci un pò di elettronica, costruendo quello che serve per trasformare un normale telecomando RF per cancelli automatici in un telecomando pilotato da Arduino.

Per prima cosa dovremo individuare i pin del nostro pulsante di apertura e saldargli due spezzoni di filo.

Nel frattempo avremo posizionato il nostro transitor N-P-N su una breadboard, opportunamente configurato con una resistenza da 2.2k sull’attuatore.

La base del transistor andrà collegata al pin 7 di arduino. L’emettitore, invece, andrà ad uno dei cavi che abbiamo appena saldato sul telecomando. Il collettore verrà collegato ad uno dei capi del pulsante del telecomando ed alla massa di arduino.

In questo modo, avremo creato un circuito normalmente aperto che si chiude (premendo di fatto il pulsante del telecomando) solo quando arriva un impulso di una certa soglia inviato dal pin digitale. Ci resta da codificare queste informazioni in un linguaggio comprensibile per il nostro microcontrollore.

Arduino YUN è una piattaforma ibrida molto interessante basata su un server linux, un modulo wifi ed un microcontrollore AT (del tutto simile a quello usato su arduino uno). Il pregio di Arduino, rispetto altri concorrenti, è quello di essere assolutamente semplice ed efficace nella gestione degli input/output analogico/digitali, offrendo un linguaggio di programmazione basato su C di rapida comprensione. Per poter eccitare il nostro pin 7 di cui sopra, ci basteranno poche righe di codice:

C++

digitalWrite(7, HIGH);
delay(2000); 
digitalWrite(7, LOW);

a quanto sopra dobbiamo aggiungere la logica per il server HTTP. Arduino YUN include già una mini piattaforma HTTP server/client esposta in maniera molto semplice attraverso due oggetti di libreria denominati ClientBridge e ServerBridge. Il server bridge ci servirà per ascoltare le richieste provenienti dal mondo esterno ed il client per scrivere le nostre risposte a chi ci ha chiamato.

C++

/*
  A simple HomeBridgeHub example for HomeBridge
  Author: Costantino Pistagna
*/

#include <dht.h>
#include <Bridge.h>
#include <BridgeServer.h>
#include <BridgeClient.h>

dht DHT;

BridgeServer server;
String startString;

#define DHT22_PIN 7
#define REMOTEDOOR_PIN 4

void setup()
{
  pinMode(REMOTEDOOR_PIN, OUTPUT);
  digitalWrite(REMOTEDOOR_PIN, LOW);

  Bridge.begin();

  server.listenOnLocalhost();
  server.begin();
  Process startTime;
  startTime.runShellCommand("date");
  while (startTime.available()) {
    char c = startTime.read();
    startString += c;
  }
}

void loop()
{
  BridgeClient client = server.accept();
  if (client) {
    String command = client.readString();
    command.trim();       
//    Console.println(command);
    if (command == "temp") {
      int chk = DHT.read22(DHT22_PIN);
      switch (chk)
      {
        case DHTLIB_OK:
        client.print("{ \"temperature\":");
        client.print(DHT.temperature-2);
        client.print(", \"humidity\":");
        client.print(DHT.humidity);
        client.println("}");
        break;
        case DHTLIB_ERROR_CHECKSUM:
        client.println("{ \"status\" : \"Checksum error\"");
        break;
        case DHTLIB_ERROR_TIMEOUT:
        client.println("{ \"status\" : \"Timeout error\"");
        break;
        default:
        client.println("{ \"status\" : \"Unknown error\"");
        break;
      }
    }
    else if (command == "switchOn") {
      client.println("{\"status\" : \"OK\"}");
      digitalWrite(REMOTEDOOR_PIN, HIGH);
      delay(2000);      
      digitalWrite(REMOTEDOOR_PIN, LOW);
    }
    client.stop();
  }
  delay(50);
}

Resta da aggiungere il controllo di temperatura. Il sensore DHT22 è un sensore digitale ottimo per lo scopo: dal costo contenuto e dalla precisione digitale, non richiede taratura e può essere usato con una delle molte librerie per dispositivi a tecnologia DHT presenti.

github.comDHTlibArduino library for DHT temperature and humidity sensor. AVR optimized

il pin 1 è il pin di alimentazione
il pin 2 è il pin dove vengono modulati e serializzati i dati
il pin 3 è inusato
il pin 4 è la massa.

collegheremo il pin 2 al pin 4 del nostro arduino yun.

leggere la temperatura e l’umidità anche in questo caso è molto semplice:

C++

int chk = DHT.read22(DHT22_PIN);
switch (chk)
{
    case DHTLIB_OK:
    client.print("{ \"temperature\":");
    client.print(DHT.temperature-2);
    client.print(", \"humidity\":");
    client.print(DHT.humidity);
    client.println("}");
    break;
    case DHTLIB_ERROR_CHECKSUM:
    client.println("{ \"status\" : \"Checksum error\"");
    break;
    case DHTLIB_ERROR_TIMEOUT:
    client.println("{ \"status\" : \"Timeout error\"");
    break;
    default:
    client.println("{ \"status\" : \"Unknown error\"");
    break;
}

Conclusioni — wrap it up

Bene. E’ il momento di mettere insieme tutti i pezzi. Una volta avviato lo sketch sul nostro Arduino, verifichiamo che tutti i comandi funzionino correttamente:

/temp

/switchOn

A questo punto ci basterà avviare homebridge e configurare opportunamente la nostra applicazione Home inserendo il qrcode che appare a schermo e seguendo i passi illustrati dall’app Home di Apple. Alla fine avremo qualcosa di questo tipo a schermo:

e la possibilità di parlare con il nostro amato dispositivo chiedendogli:

Che temperatura c’è a casa?

oppure ancora:

Apri il cancello

Considerazioni finali

homebridge è una piattaforma open molto flessibile che permette di dialogare con il protocollo HAP di Apple in maniera rapida ed efficace attraverso mini moduli e semplici tecnologie basate su http.