Swift – Usare i constraint creati da Storyboard via codice

Se anche voi, come me, fate uso intenso di Interface Builder, Xib e Storyboard vi sarete accorti che su xCode manca un metodo per poter riferirsi ad un constraint specifico a meno di non utilizzare @IBOutlet per ogni singolo elemento.

La cosa che più mi disturba è il non poter avere dei riferimenti a quelle proprietà molto utili come la dimensione o la posizione di una View. Mi spiego.
Prima di Autolayout potevamo semplicemente scrivere una cosa del genere (ipotetica):

view.height = 100
view.width = 200

Adesso invece se dobbiamo modificare la dimensione di una View dobbiamo prima creare i constraint, poi connetterli con @IBOutlet e infine possiamo modificarli. Proprio per il concetto di Autolayout è giusto che sia così ma tutti questi passaggi li ritengo troppo lunghi e quindi ho cercato una soluzione più comoda.

Ogni NSLayoutContraint ha un Identifier, quindi è possibile cercare e trovare il contraint assegnando un semplice identificativo da Interface Builder.

UIView ha un proprietà: .constraint che include tutti quelli assegnati, quindi possiamo ciclare e cercarne uno specifico.
Però non basta, perché specifici constraint non stanno all’interno della View al quale sono assegnati ma alla View genitore.

Prendiamo come esempio una UIView chiamata “container”. Se agganciamo un constraint Top, quest’ultimo sarà inserito nella superview.

Quindi è necessario ricercare i constraint in modo più intelligente, andando a interrogare sia le view che le subviews.

Ho creato una extension di UIView che ci permette di fare tutto questo in modo semplice, ma non solo, ho creato un sistema predefinito di chiavi da utilizzare nel nostro progetto: top, bottom, leading, trailing, height, width, xAlign, yAlign. Ed è possibile accedere direttamente a tutti questi constraint tramite delle semplici proprietà.

Il progetto è su GitHub e si chiama StroryboardConstraint. Sono benvenute tutte le critiche e i suggerimenti.

Utilizzarlo è molto semplice, basta includere la extension nel progetto, assegnare gli identificativi tramite Interface Builder e poi accedere alle proprietà:

customView.heightConstraint?.constant = 200
customView.topConstraint?.constant = 20

Si può anche accedere ad un constraint con un identificativo specifico:

view.constraint(withIdentifier: "customWidth", searchInSubviews: true)?.constant = 50

[EDIT]

Ho appena aggiornato la libreria. Adesso non c’è più bisogno di configurare alcun identifier. L’estensione è in grado di riconoscere automaticamente il constraint richiesto.

Inoltre ho aggiunto un nuovo metodo per avere tutti i constraint di un certo tipo ordinati per priorità:

view.constraints(withAttribute: .height)

Spero apprezziate e non esitate a inviarmi i vostri commenti!

Nuove risorse per gli sviluppatori iOS

Apple ha rilasciato nella giornata di oggi nuove risorse molto utili per tutti gli sviluppatori iOS, in particolare per i designer e i grafici.

Si possono trovare nella sezione Resources della guida all’interfaccia grafica di iOS.

Apple ha reso disponibile per il download gratuito un file in formato PSD (Photoshop) e Sketch dove al suo interno si possono trovare tutti gli elementi dell’interfaccia grafica di iOS, da iPhone a iPad. Questa risorsa è davvero molto utile perché permette di poter creare il design di una UI/UX a partire proprio dall’esperienza che Apple ha creato.

Molto utili anche tutti i simboli e le icone di sistema, finalmente ufficiali e in formato vettoriale.

C’è da notare che Apple ha anche rilasciato la stessa interfaccia grafica in una veste “dark”, con sfondo nero e colore primario arancione.
Questa in realtà non è una colorazione di sistema, anche se presente nella UI dell’applicazione Watch.
Infatti gli sviluppatori non possono “attivare” alcuna versione “dark”, per questo è interessante vedere queste risorse perché si potrebbe assumere che Apple possa attivare questa nuova modalità come comportamento di sistema ed aprire pure le API agli sviluppatori.

Insomma, ottime notizie per tutti noi sviluppatori!

 

ImageSlideShow Swift su CocoaPods

Ieri ho pubblicato il mio primo Pod. Si tratta di ImageSlideShow per iOS scritto completamente in Swift che potete trovare sia in versione 2.3 (non-pod) che in versione 3.0.

Come installarlo

Dovete installare CocoaPods tramite linea di comando:

$ gem install cocoapods

È richiesto CocoaPods 1.0.1+, Swift 3 e Xcode 8.

Adesso create il Podfile

Per integrare ImageSlideShow dovete specificare nel Podfile:

source "https://github.com/CocoaPods/Specs.git"

platform :ios, '9.0'

target 'TargetName' do
	use_frameworks!
	pod 'ImageSlideShowSwift'
end

Quindi potete avviare il comando:

$ pod install

Come usarlo

1. Importa il modulo ImageSlideShowSwift

2. Instanzia il controller

ImageSlideShowViewController.presentFrom(self){ [weak self] controller in

	controller.dismissOnPanGesture = true
	controller.slides = self?.images
	controller.enableZoom = true
	controller.controllerDidDismiss = {
		print("Controller Dismissed")
	}

}

Ogni oggetto immagine deve rispondere al protocollo [ImageSlideShowProtocol].
Puoi guardare il progetto Demo per avere un riferimento più chiaro.

Per maggiori informazioni potete sempre andare sul sito GitHub.

Sentitevi liberi di dare feedback e consigli!

La programmazione e l’opensource

Ultimamente mi sono ritrovato a lavorare a vari progetti iOS sviluppati da terzi e di cui non detenevo i diritti del codice sorgente, cioè la maggior parte del lavoro era stato fatto da altri.

La cosa che mi è saltata subito all’occhio è stato il numero elevato di codice opensource utilizzato, potrei ipotizzare il 90% del codice totale.

Ad una prima analisi viene da esclamare “bello! ci sono già un sacco di cose pronte!” ma in realtà questa situazione mi mette a disagio. Stiamo programmando un software o stiamo assemblando i pezzetti fatti da altri cercando di farli coesistere?

Sono pienamente convinto che ci sia una grande differenza tra programmare e utilizzare codice opensource in modo massiccio e l’avvento di soluzioni come CocoaPods e affini forse sta incentivando questa mania.
Sono a favore dell’opensource e sono a favore dell’utilizzo del codice open nei progetti ma con parsimonia.

Nei miei progetti, quelli che creo per i miei clienti, il codice è al 90% mio e solo un 10% è codice opensource.

Qual’è il motivo? Semplice, si tratta di avere il massimo controllo del progetto. Ovviamente c’è del lavoro in più da fare ma questo mi permette di poter operare all’interno del codice del mio software in ogni maniera.

Ci sono alcuni punti durante la vita di un progetto che vanno presi in considerazione:

  1. Bugs. I software contengono sempre dei bugs e se il codice non è nostro, una volta scovato, è un problema risolverlo. Se utilizziamo codice opensource la procedura di fix è decisamente più lunga e talvolta controproducente.
  2. Aggiornamenti. Apple ci sta abituando a lavorare con un linguaggio di programmazione in continua evoluzione: Swift. Cosa accade quando toglierà il supporto a Swift 3 e dovremo passare a Swift 4? Se utilizziamo codice di qualcun altro è possibile che saremo costretti ad attendere. Ma il nostro cliente,  il nostro business e peggio ancora, il business del nostro cliente avrà tutto questo tempo?
  3. Manutenzione. Se il codice open che abbiamo utilizzato smette di essere mantenuto cosa accade? Passiamo ad altro!, potremmo dire, ma questo comporta del lavoro in più, chi lo paga? Altri potrebbero dire “ci facciamo nostro il codice e continuiamo a mantenerlo”, ma mantenere codice non nostro significa doverlo analizzare in profondità per conoscere ogni riga. Chi lo paga questo tempo?

Solo questi 3 punti mi bastano per capire che utilizzare codice opensource in modo massiccio all’interno dei progetti per i miei clienti non è una scelta saggia, né per me né per i clienti stessi che si aspettano alta professionalità e si affidano a questa per portare avanti il proprio business.

Altra nota negativa è che in questo modo stiamo crescendo programmatori con l’idea che la realizzazione di un software sia l’assemblaggio di pezzi di codice altrui.
A mio avviso è un grande danno, perché il mondo della programmazione, quello reale, quello dove si sta ore su ore davanti al codice per creare un software, è molto differente rispetto allo studiarsi le API di un framework su cui baseremo un software non sapendo minimamente cosa quel codice farà.

Mi ripeto, non sono contro l’opensource né contro l’utilizzo di quest’ultimo all’interno dei progetti. Va usato con parsimonia.

Buona programmazione!

Come diventare un programmatore iOS Swift

In molti mi chiedono come poter diventare programmatori iOS e quali sono i passi da fare.
Il mio consiglio ad oggi è quello di concentrarsi sul linguaggio di programmazione Swift al fine di averne la piena conoscenza.

Sono convinto che questo linguaggio si espanderà molto fino ad arrivare anche su altre piattaforme in modo produttivo e quindi conoscerlo ed averne la maestria sarà un grande vantaggio.

Ma perché proprio Swift?

Il nuovo linguaggio ideato da Apple sta riscuotendo un grandissimo successo ma alla base c’è una scelta ponderata. Ad oggi Swift è il linguaggio di programmazione di default per i sistemi Apple, non obbligatorio ma con il tempo il supporto ad Objective-C sarà sempre meno frequente.

Questo non significa che non dobbiate conoscere almeno i principi di programmazione Objective-C. Anzi, sarà fondamentale per comprendere alcuni framework e per poter essere in grado di lavorare anche su codice più datato.

Se il vostro obiettivo è quello di lavorare nel mondo delle applicazioni iOS dovrete essere preparati nel caso in cui vi sarà richiesto di mettere le mani su applicazioni già esistenti che nel 90% dei casi saranno scritte in Objective-C.

I primi passi da fare

Questo articolo è scritto per chi ha già una base di conoscenza della programmazione ad Oggetti e dei pattern più usati come MVC (Model-View-Controller).

A questo punto potete addentrarvi nel magico mondo Apple e la prima cosa da fare è studiare la documentazione sull’architettura di iOS.
Una volta appresa potete passare alle linee guida di design di iOS e come ultima parte le linee guida del Review Team che per renderla più interessante e alla portata di tutti, Apple ne ha anche creato una versione a fumetto.

A questo punto potete passare allo studio dei linguaggi di programmazione, Swift e Objective-C.

Libri

Il primo libro da leggere è sicuramente la Guida di Apple su Swift che è possibile anche avere in versione iBook, totalmente gratuito.

Una volta presa dimestichezza con il linguaggio potete iniziare e leggere il libro Advanced Swift: Version 2 di objc.io che personalmente lo reputo una piccola perla insieme a Functional Swift: Updated for Swift 3  sempre di objc.io. Questi due libri hanno un prezzo di $ 39,00 l’uno.

Da tenere presente anche i libri di Ray Wenderlich che spaziano dallo sviluppo di applicazioni fino a quello di videogiochi.

Video

Ogni anno Apple organizza la WWDC (World Wide Developer Conference) che è un evento molto importante per ogni sviluppatore. All’interno di questo evento vengono solitamente presentati i nuovi sistemi operativi e le ultime tecnologie. Durante i 5 giorni vengono fatti degli speech su argomenti ben precisi riguardanti le novità appena introdotte. Potete vedere quindi tutti i loro video sul portale Apple Developer.

Alla Stanford University ogni anno organizzano un corso di sviluppo iOS che poi mettono a disposizione a chiunque, lo trovate a vostra disposizione su iTunes.

Anche l’Università di Pisa ha organizzato un corso di sviluppo iOS, non è aggiornato all’ultima versione ma è comunque molto utile. Potete trovarlo anch’esso su iTunes.

Anche Ray Wenderlich nel suo ottimo archivio ha molti video corsi interessanti e che dovete assolutamente vedere.

Corsi

Ci sono moltissimi corsi di formazione per il mondo iOS sia online che offline. Non ho mai avuto l’opportunità di conoscere le persone che li organizzano quindi non so dirmi qual’è il migliore. Vi faccio un elenco di quelli più famosi.

Un progetto molto interessante e che personalmente seguo è Talks.io sempre dei ragazzi di objc.io dove trattano argomenti specifici in Swift cercando di insegnare e discutere sulle soluzioni migliori da adottare durante lo sviluppo.

Se invece siete di Pisa, Lucca, Livorno o d’intorni, nel corso del 2017 ci saranno novità riguardanti lo sviluppo di applicazioni iOS al Talent Garden di Pisa. Se siete interessati a corsi, workshop e seminari potete iscrivervi alla newsletter e riceverete le novità al riguardo.

Blog

Anche di blog che parlano di sviluppo iOS e Swift ce ne sono tantissimi. Personalmente seguo gli issues di objc.io (anche se ad oggi non stanno portando avanti il progetto) e il blog di Ray Wenderlich.

Da tenere sempre a portata di mano è il blog di Apple su Swift così come il blog We ♥ Swift.

Come ultima risorsa ma non meno importante vi consiglio di tenere a portata di mano il link delle Risorse per gli sviluppatori di Apple dove potete trovare sempre le ultime novità.

Se avete domande o ogni altra necessità potete sempre contattarmi.