The UITableView is a class we all have used at least once in our apps.
Sometimes we need a UITableView with cells all equal in height, but sometimes we need dynamic height cells, each one having a different height, typically dependent on its own content.
The old way
Before iOS8, this was not trivial since the system needed to know in advance the overall height of the table in order to set the content size of the scrolling area (UITableView inherits from UIScrollView).
Currying is a generic “technique of translating the evaluation of a function that takes multiple arguments into evaluating a sequence of functions, each with a single argument” (wikipedia). Swift supports currying as we see in the following example.
In the spirit of the new iOS adaptive philosophy, the SDK itself is giving us a new (or an old modified) View Controller that is really adaptive: the UISplitViewController.
“UISplitViewController is really a workhorse to be used in iOS 8” (from WWDC 2014 session “What’s New in Cocoa Touch”).
Nelle nostre app utilizziamo abitualmente l’UINavigationController, cioè un container che ci permette di mostrare tutte le nostre sotto-interfacce (UIViewController, o subclass di questa, di seguito VC) come se fossero idealmente disposte in uno stack tramite il quale possiamo navigare fra di esse avanti e indietro (push e pop).
Access control: li aspettavamo, e in effetti ora possiamo aggiungere alle nostre definizioni gli attributi di visibilità: private (visibile solo nel file corrente), internal (il default, visibile in tutto il target corrente), public (visibile anche in altri target/framework). Interessante anche l’uso di attributi come: private(set) che vuol dire “in lettura (get) per tutto il target ma modificabile (set) solo dal corrente file”.
Indubbiamente, rispetto ad altri grandi cambiamenti come un linguaggio di programmazione completamente nuovo, alcune novità del nuovo SDK introdotte nell’ultima WWDC (2014) hanno avuto minore risonanza.
Una di queste è sicuramente l’entrata in scena nella piattaforma iOS delle Size Classes: di cosa si tratta?
La Beta3 di iOS8 e Yosemite ha portato alcuni cambiamenti in Swift abbastanza rilevanti. Forse dovremo abituarci a queste modifiche da qui alla uscita ufficiale, ancora molte cose mancano o sono da completare (per esempio le publicprivateprotected sui membri delle classi ancora non si vedono).
Le modifiche sono:
Gli array ora hanno un comportamento nelle copie identico a dictionary e string, cioè per valore (non reference). Prima di questa modifica gli array in alcuni casi non venivano copiati ma condivisi fra più variabili (shared, per motivi di performance). Il metodo unshare per gli array non esiste più.
L’operatore range non inclusivo (half closed) è diventato ..< (prima era solo ..)
Nuova sintassi breve per array: [String] (quella di prima “String[]” continua ad essere valida ma si preferisce la nuova)
Aggiunta una seconda notazione shorthand per i dictionary: [KeyType: ValueType], esempio: var myDict : [String, Int]
Il nuovo linguaggio Swift introdotto da Apple alla WWDC 2014 sarà il linguaggio ufficiale con cui sviluppare App per iOS (e per MacOSX).
Già si discute molto se (o quando) l’Objective-C sarà completamente rimpiazzato. Io credo presto, anche se al momento ne abbiamo ancora bisogno per alcune funzionalità non ancora pronte in Swift (provate a trasformare una stringa in float).
Una delle caratteristiche per me più innovative in Swift sono gli optionals. Per quanto ne so non esiste analogo in altri linguaggi (attendo smentite).