Impariamo ad animare pulsanti, etichette e imageView senza creare un casino di classi

Avrete sentito da qualche parte che disporre delle competenze giuste ma non metterle in pratica è un po’ come avere i denti ma bere solo latte. Voi direte: “Ok, basta teoria. Dicci come sfruttare la POP nelle nostre app”.

Affinché i miei lettori possano rendere produttivo il tempo trascorso leggendo i miei articoli, mi aspetto da loro che comprendano i Completion Handlers e che possano realizzare un’implementazione base usando Protocol. Se non avete familiarità con i suddetti elementi, vi chiedo umilmente di lasciar perdere questo articolo e di dedicarvi ad altre fonti propedeutiche (che indicherò nei prerequisiti), prima di tornare qui.

Prerequisiti

No Fear Closures Part 2: Completion Handlers (Medium)
Intro to Protocol Oriented Programming (Medium)
Protocol Oriented Programming Series (YouTube)

Cosa imparerete in questo articolo

Imparerete ad utilizzare Protocol per animare UI Components come UIButton, UILabel e UIImageView. Vi mostrerò inoltre la differenza tra i metodi tradizionali e il metodo POP.

UI

App demo chiamata Welcome to My House Party: ho realizzato questa applicazione per verificare se vi abbia o meno invitato alla mia festa. Dovrete digitare un invitation code; dietro quest’app non vi è alcuna logica. Se premete il pulsante, gli elementi della pagina si animeranno in ogni caso.

Ci sono quattro componenti che si animano: passcodeTextField, loginButton, errorMessageLabel e rofileImageView. Le animazioni sono invece due: buzzing e popping.

POP vs metodo tradizionale

Per afferrare pienamente il potere del Protocol-Oriented Programming (POP) nelle app reali, mettiamolo a confronto con il metodo tradizionale. Diciamo di voler animare UIButton e UILabel. Dovremmo creare subclass di entrambi e dunque aggiungervi un metodo.

Facciamo in modo che vibri nel momento in cui si fa tap sul pulsante di login:

Vedete che ci ripetiamo? La logica dell’animazione prende almeno 5 righe: c’è un metodo migliore per ottenere lo stesso effetto. Dal momento che UILabel e UIButton appartengono a UIView, possiamo aggiungere

Quindi BuzzableButton e BuzzableLabel contengono il metodo buzz e non siamo responsabili di inutili ripetizioni.

Ok, ma perché POP?

Come avrete notato, l’errorMessageLabel – che dice “Please enter valid code” – ha un’ulteriore animazione. Appare e scompare. Dunque, come ci comportiamo utilizzando il metodo tradizionale?

Ci sono due modi per fare ciò. Prima di tutto, potremmo aggiungere un altro metodo ad UIView.

Tuttavia, se aggiungiamo metodi ad UIView, il metodo pop sarà disponibile ad altri UIComponents oltre che a UILabel. Ereditiamo funzioni non necessari e quei UIComponents si gonfieranno di default.

Il secondo metodo è il subclassing di UILabel

Questo funziona discretamente, ma potremmo cambiare il nome della classe con BuzzablePoppableLabel per suggerire esplicitamente attraverso il solo nome.

Ora, cosa dovremmo fare se volessimo aggiungere un altro metodo a UILabel per indicare chiaramente cosa fa la label? Potremmo cambiare il nome della classe con, ad esempio, BuzzablePoppableFlashableDopeFancyLovelyLabel. No, non è sostenibile e sì, la sto facendo troppo lunga.

Protocol Oriented Programming (POP)

Ok, basta con il subclassing. Realizziamo prima un protocollo per il buzz.

 

Non ho inserito il codice per le animazioni perché alquanto lungo.

 

Qualsiasi UIComponent che sia conforme al protocollo Buzzable avrà associato il metodo buzz. Diversamente dall’estensione, solo quelli che si conformano al protocollo disporranno di quel metodo. Inoltre, where Self: UIView è usato per indicare che il protocollo dovrebbe essere conforme solo a UIView o ai componenti che ereditano da UIView.

Applichiamo Buzzable a loginButton, passcodeTextField, errorMessageLabel e profileImageView. Aspettate… e Poppable? Be’… è la stessa cosa.

Infine, rendiamo tutto più reale!

La cosa più interessante della programmazione protocol oriented è che si può applicare l’effetto pop ad ogni altro UIComponent senza effettuare subclassing.

Ora il nome della classe può essere più flessibile perché conosciamo già i metodi disponibili basati sui protocolli che abbiamo conformato, e il nome di ogni protocollo descrive la classe. Quindi non dovremo più scrivere cose come “MyBuzzablePoppableProfileImage”.

tl;dr

  • Niente più subclassing
  • Nomi delle classi flessibili

Risorse

Source Code
The Resource Page for iOS Developers

***

Bob Lee è l’autore di questo articolo.

Articolo originale:Protocol Oriented Programming View in Swift 3

 

NO COMMENTS

LEAVE A REPLY