Localizzare la tua app in modo semplice

Localizzare l’app richiede tempo ed è una di quelle scelte che vanno fatte in fase di analisi.

Apple ci da tutti gli strumenti per farlo correttamente. Ho voluto però creare un metodo ancora più semplice per richiamare le stringhe localizzate ed ho messo il codice su GitHub.

Si tratta di una semplice funzione che fa da wrapper a NSLocalizedString.

Prima di questa extension dovevamo scrivere:

NSLocalizableString("chiave da localizzare", comment: "commento")

Lo trovo decisamente lungo da scrivere. Quindi con questa estensione ora possiamo scrivere:

"string.to.localize".localized
//  or
"string.to.localize".localized()

Se vogliamo usare una tabella:

"string.to.localize".localized("TableName")

Se vogliamo aggiungere un commento:

"string.to.localize".localized(comment: "This is the comment")

Se vogliamo passare degli argomenti:

"string.to.localize %@".localized(arguments: [12]) // Print: "string.to.localize 12"

Se vogliamo definire un valore di default:

"string.to.localize %@".localized(value: "No localization found")

Cosa ve ne pare?
Potete scaricare l’extension da GitHub: https://github.com/dimix/Localizable

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!