Accueil > Mobile > Switch to Swift

Switch to Swift

16299319458_81ffd96e3d_mLa conférence DotSwift 2015 a eu lieu au théâtre des Variétés de Paris le vendredi 6 février. Il s’agissait de la première conférence européenne sur ce nouveau langage qu’est Swift qui n’est apparu qu’en juin 2014. Cette conférence est l’occasion pour nous (Abderrahim, André, et moi-même) de vous faire découvrir Swift ainsi que ce que l’évènement nous a appris.

DotSwift

15864442464_393ec5e01b_mLa conférence nous a rassemblé au théâtre des Variétés de 14h à 18h30. L’après-midi était divisé en 3 sessions de présentations avec des moments d’échanges et de détente entre chaque. Pendant les pauses nous pouvions aller rencontrer les orateurs, ainsi que des membres de Bla Bla Car, partenaire de la conférence.

Lors de la première session, Dimitri Dupuis-Latour, Marius Rackwitz, et Corinne Krych, se sont succédés pour nous faire partager leur vision de Swift. Dimitri et Corinne nous ont expliqué les éléments de Swift qu’ils ont trouvé particulièrement puissants, les optionals et les enums en tête (on en reparlera). Marius a comparé la liaison avec les frameworks Swift et Objective-C (Static vs. Dynamic).

Au cours de la deuxième session, nous avons assisté à des lightning talks, qui sont des présentations techniques très courtes sur des points particuliers (le Bluetooth, les enums, les fonctions, les tests). Ensuite, Romain Huet nous a présenté l’outil fabric.io, qui permet d’inclure des outils Twitter dans son application. La session s’est terminée par une présentation de Jean-Pierre Simard sur l’introspection dans Swift.

La dernière session a vu Kyle Fuller nous parler de functional programming avant que Ash Furrow et Daniel Steinberg clôturent cette journée en abordant leur expérience du passage à Swift. Leur retour était particulièrement intéressant et passionné. Ash Furrow a reconnu que tout n’était pas encore parfait mais qu’il était 15866878073_4212391090_mindispensable de se lancer et de se faire sa propre expérience. Son entreprise a d’ailleurs réalisé un projet Open Source (eidolon) entièrement en Swift. La vision de Daniel Steinberg, dernier intervenant de la conférence, a été particulièrement appréciée pour son humour et surtout cette expérience d’un développeur qui utilisait Objective-C bien avant que l’iPhone existe.

La seconde partie de cet article vous présente les éléments qui sont ressortis durant les conférences et qui nous paraissent incontournables pour aborder Swift.

D’objective-C à Swift

Swift a été présenté par Apple lors de la WWDC 2014, et il est sorti en version finale en septembre de la même année. Mais, si l’on regarde l’évolution qu’a connu Objective-C lors de ces cinq dernières années, on s’aperçoit que Apple a, en quelque sorte, préparé le terrain de son nouveau langage :

  • Les fichiers headers “.h” se sont peu à peu vidés au profit des fichiers d’implémentation “.m”. Swift n’utilise plus qu’un seul fichier.
  • Apple a introduit les blocks dans Objective-C qui sont des fonctions anonymes. Dans Swift on utilise très souvent les closures.
  • Le boxing a été introduit dans les tableaux et les dictionnaires (initialisation avec la notation []) à partir de Objective-C 2.0.

Alors que Objective-C est sorti en 1984, il a connu ses principales évolutions à partir de la sortie de l’iPhone en 2006, et plus encore à partir de 2010 où les nouvelles fonctionnalités l’ont rapprochés de Swift. C’était il y a 4 ans et on peut aisément imaginer qu’Apple travaillait déjà sur son futur langage.

Swift is awesome

Lorsque Apple a présenté Swift, ils ont dit que c’était Objective-C sans le C. En réalité quand on découvre Swift on s’aperçoit qu’il s’agit plutôt d’Objective-C sans le C mais avec plein de choses à la place. Pour tracer la feuille de route de Swift, Apple semble avoir pioché les forces de Apple_Swift_Logoplusieurs langages comme Javascript, Ruby, Objective-C (liste non exhaustive) et inclus le tout pour former leur nouveau langage. Tout ces ajouts ont pour but de rendre Swift plus simple syntaxiquement, plus puissant et plus sûr. A partir de quelques exemples nous allons vous montrer les points du langage qui ont particulièrement attiré notre attention.

Les optionals

16485253501_4308afa886_mErwin Schrödinger est un physicien et théoricien scientifique autrichien notamment connu pour son expérience appelé le chat de Schrödinger. Cette expérience place un chat dans une boîte totalement opaque en présence d’un poison qui peut être relaché à tout moment. Il est alors admis qu’à un instant t, il est impossible de savoir si le chat est mort ou vivant. Il est alors considéré qu’il peut être les deux. Les optionals fonctionnent sur le même principe. Une variable peut, à tout moment, avoir une valeur ou ne pas en avoir (et donc être nil) :

var alive = cat?.name ?? “RIP”
//La variable cat existe-t-elle ? Si oui alors la variable alive prendra 
//la valeur de cat.name sinon elle prendra la valeur “RIP”

Les optionals permettent d’avoir un code compilable qui, en plus d’être compact et expressif, reste robuste quelle que soit la valeur de la variable. En revanche, une variable optional ne peut pas être utilisée telle quelle. Par exemple, une optional String (String?) est de type optional et non String. Elle n’a accès à aucune méthode de String. Pour devenir une String il faut unwrapper l’optional en utilisant l’opérateur !. Pour cette opération il faut veiller à ce que l’optional ne soit pas n”. Dans le cas contraire cela provoquera un crash de l’application.

var alive = cat!.state
// Ici la variable “cat” est forcée au yeux du compilateur. 
// Elle ne peut plus être nil sous peine de provoquer un crash au runtime

Il faut également noter qu’une variable non-optional ne peut jamais être nil sous peine de provoquer une erreur de compilation.

var toto = “Swift”
toto = nil
// Ici on déclare toto comme étant une String, elle ne peut donc
// pas être nil et la ligne suivante provoque une erreur de compilation

 Les enums

Dans Swift la force des énumérations vient du fait que chaque cas d’une énumeration peut avoir des valeurs associées qui lui sont propres.

enum Barcode {
   case UPCA(Int, Int, Int, Int)
   case QRCode(String)
}

Cette énumération peut prendre 2 valeurs, UPCA ou QRCode.

Dans le cas où elle prendrait la valeur UPCA elle doit être associés à 4 Int :

var productBarcode = Barcode.UPCA(8, 85909, 51226, 3)

Dans le cas où elle prendrait la valeur QRCode elle doit être associés à une string :

productBarcode = .QRCode(“ABCDEFGHIJKLMNOP”)

A noter que lors du 2ième appel, productBarcode est connu comme étant de type Barcode, il peut donc être appelé sans rappeler le type de l’enum.
En Objective-C, il était uniquement possible d’avoir des énumerations d’integer. Désormais, avec Swift, il est possible d’avoir des énumérations d’integer, de String, de Class, de range… Ce qui permet d’être bien plus exhaustif et de recourir plus souvent à une énumération. De plus il est possible de déclarer des méthodes au sein d’une énumération.

 Les generics

Dans les langages typés, si vous voulez faire la même opération sur des variables de types différents, vous devez avoir autant de fonctions que de types. Par exemple pour inverser les valeurs de 2 variables a et b, vous devez avoir une fonction pour inverser des Int, une pour inverser des String et ainsi de suite. Les generics répondent à cette problématique puisqu’ils permettent une abstraction des types pour un fonctionnel commun.

func swapTwoStrings(inout a: String, inout b: String) {
   let temporaryA = a
   a = b
   b = temporaryA
}
func swapTwoDoubles(inout a: Double, inout b: Double) {
   let temporaryA = a
   a = b
   b = temporaryA
}

Ici nous avons 2 fonctions qui partagent exactement le même fonctionnel mais pour des types de variables différents.

En utilisant des generics on obtient :

func swapTwoValues<T>(inout a: T, inout b: T) {
   let temporaryA = a
   a = b
   b = temporaryA
}

En appelant cette fonction, Swift adaptera le type de fonction selon les paramètres d’appel. On a ainsi un code plus léger et facilement maintenable.

Swift est immature ?

 

16460839806_7bf559d692_m

Swift est un langage qui n’a que quelques mois, on ne peut donc pas s’attendre à la même maturité que l’Objective-C qui existe depuis 30 ans. Vous avez des outils qui peuvent se montrer instables avec des crashs d’Xcode au cours du développement.

Une autre faiblesse, qui vient du jeune âge de ce langage, est le manque de retours et d’expérience sur le sujet. Vous pouvez donc vous retrouver devant un bogue que personne n’aura eu auparavant. Peut-être pourrez vous alors trouver la solution, ou peut être qu’il n’en existe tout simplement pas encore et qu’il faudra attendre une mise à jour d’Apple.

Malgré ces inconvénients, Swift a atteint le statut de GM en septembre 2014 et il est possible de soumettre des applications sur le store. Des projets n’utilisant que Swift ont déjà été lancé : une version beta de CocoaPods est même disponible depuis fin 2014, intégrant de nouvelles librairies telles que SwiftyJSON ou Alamofire.

Parier sur Swift c’est aussi utiliser un langage qui n’en est qu’à ses débuts. Même si les bases sont posées, le langage va être amené à évoluer de manière importante au cours des prochaines années. Il s’agira alors de bien rester informé et de suivre les évolutions à venir.

Mais là où Swift fait la différence, c’est qu’il est parfaitement compatible avec Objective-C. Rien n’empêche les développeurs de faire se côtoyer du code Swift et du code Objective-C. On peut ainsi se familiariser petit à petit à ce nouveau langage. Commencer par des fonctionnalités simples et faire petit à petit des fonctionnalités plus avancées. De plus une grande partie des APIs Objective-C sont reprises dans Swift. Et si ce n’est pas le cas vous avez accès aux APIs Objective-C en Swift (Rien ne vous empêche d’utiliser une NSString par exemple). Ainsi vous ne partirez pas de zéro si vous avez déjà développé des applications iOS.

Switch to Swift

15864302364_a49f5f1eee_m

Malgré tous les avantages potentiels que représente Swift par rapport à Objective-C il est important de se poser les bonnes questions au moment de choisir son langage de développement pour son application iOS / MacOS X.

Nous avons vu que Swift offre de nombreuses possibilités que n’a pas Objective-C mais, en contrepartie, vous avez des outils parfois instables et un risque de vous retrouver devant des problèmes que personne n’a encore rencontré et qui peuvent donc être potentiellement insolubles. Dans ce cas il ne faut pas hésiter à revenir aux fondamentaux et à Objective-C.

Avant de prendre sa décision il convient donc d’être bien informé. Et pour ça il faut connaître et avoir essayé Swift pour faire un choix éclairé et justifié. Le jeu en vaut la chandelle alors n’hésitez pas, switchez pour Swift.

Dot Dot Dot

Nous sommes ressortis de cette conférence avec une envie folle de découvrir et d’expérimenter Swift. Même si tout n’est pas encore parfait dans ce nouveau langage, la puissance qu’il apporte en comparaison d’Objective-C en fera très rapidement LE langage de développement pour iOS et MacOS X.

La conférence a été très plaisante, bien organisée et bien maitrisée. Certains talks étaient plus techniques que d’autres, permettant de satisfaire aussi bien les nouveaux développeurs que les expérimentés. On a senti les intervenants vraiment enthousiastes et convaincus de leur choix de passer à Swift.

Nous terminerons cet article par une citation de Dimitri Dupuis-Latour qui fait bien ressortir l’esprit de la conférence avec un soupçon d’Apple addiction :

Swift is not a revolution, it’s a revelation

15864288384_f533e51e14_z

CC: Abderrahim Benmakhlouf, André Huyghues-Beaufond

Categories: Mobile Tags: , ,
  1. Pas encore de commentaire
  1. Pas encore de trackbacks


− cinq = 3