iPhone 8 – come sarà realmente?

Nessuno lo sa, ma i rumors iniziano ad essere molti.
Negli ultimi giorni girano voci sulla sua forma fisica e sulla nuova interfaccia grafica adattata appunto a questo nuovo form-factor.

In particolare hanno trovato un’icona (qui sopra) che mostra la nuova forma con schermo al 100%, bordi sottili e una piccola porzione in alto che fa pensare alla posizione della fotocamera frontale e ai sensori.

Poi sono stati trovati porzioni di codice che parlano di una UIStatusBar “divisa” (split).

Tutto sembra tornare. Quindi tutti si sono buttati a creare mockup e cercare di indovinare come iOS si adatterà.
Alcuni hanno ipotizzato lo spostamento della navigation bar in basso e il pulsante Home virtuale.

In questo esempio la status bar è proprio divisa a metà. Personalmente però penso che questa soluzione abbia dei problemi:

  1. Nella status bar non c’è spazio per il nome della rete, né per le icone.
  2. Nella status bar non c’è l’orario.
  3. La navigazione in basso, pur quanto possa funzionare, comporta dei cambiamenti enormi nelle logiche delle applicazioni.

Non mi sembra la soluzione ideale.
Qualcun’altro ha ipotizzato una soluzione più semplice:

Qui la status bar è ancora divisa in due, dove ci sono solo le icone. L’orologio è riapparso in alto. Inoltre il pulsante Home è tornato fisico in basso dentro la cornice.
Questa è la soluzione che più mi piace, ma ancora non mi convince del tutto, ecco perché:

  1. L’orologio in quella posizione è posto in solitario e sembra solo sprecare spazio.
  2. Il pulsante fisico non mi convince molto in una soluzione dove si vuol dare risalto allo schermo.

Quindi?

Ho pensato anche io a come potrebbero sfruttare gli spazi in modo intelligente ed ecco cosa è venuto fuori:

  1. La StatusBar spezzata in due potrebbe servire a mostrare icone di supporto (segnale, batteria, location e molto altro)
  2. La StatusBar vera e propria come la conosciamo adesso rimane in alto. Qui può stare l’orologio ed altre icone, compresa la segnalazione dell’app che usa la location come su iPad.
  3. La NavigationBar rimane in alto come su tutti gli iPhone.
  4. Il pulsante Home è virtualizzato e ci si accede premendo con il force-touch sulla parte in basso dello schermo.

Ecco un’immagine di esempio:

Adesso non rimane altro che attendere!

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!