Accueil > Mobile > Swift ! Have you switched ?

Swift ! Have you switched ?

UnknownIl y a un peu plus d’un an, je sortais de la DotSwift 2015 enthousiaste à l’idée d’essayer Swift et d’en apprendre plus sur ce langage. A l’issue de cette conférence je vous proposais un article décrivant notre journée au théâtre des Variétés et les points sur Swift qui avaient particulièrement attiré notre attention (Switch to Swift).

Aujourd’hui, alors que Swift est disponible en version 2 et qu’il est devenu open-source,
je vous propose un retour sur la 2ieme édition de la DotSwift et surtout un petit bilan de Swift, 1 ans ½ après sa sortie.

Dot… Dot… Dot…

Commençons par la conférence qui nous a réuni le 29 janvier à partir de 14h30. L’organisation était la même que l’année dernière, 3 sessions de présentations entrecoupées de moments d’échanges et de détente. Pendant les pauses, nous pouvions aller rencontrer les orateurs, ainsi que des membres de BlaBlaCar, partenaire de la conférence.

24659867391_49f44af62f_o

Cette année Daniel Steinberg, déjà orateur il y a un an, faisait office de maître de conférence. Il introduisait les intervenants et prenait quelques minutes après chaque présentation pour une petite session de questions/réponses en “tête à tête”.

Lors de la première session, Rob Napier nous a parlé de l’esprit même de Swift et du paradigme de développement qu’il impliquait, le protocol programming. Thomas Visser nous a introduit la librairie Futures afin d’ajouter les promesses pour gérer l’asynchronisme en Swift. Pour conclure cette session, Daniel Haight nous a proposé sa vision du développement Swift XCodeless (développement iOS sans utiliser XCode), aussi surprenante soit-elle.

Au cours de la seconde session, après les traditionnels lightning speech, Roy Marmelstein nous a présenté sa vision de la gestion de l’internationalisation d’une application. Nous avons également assisté à la présentation de Ayaka Nonaka qui nous expliquait en quoi Swift avait changé notre façon de développer et notre responsabilité en tant que première vague de Swifters.

24726682706_dd7d01b9d7_kLa dernière session de la journée a vu TJ Usiyan nous présenter les concepts qui seront introduits en Swift 2.2 et Swift 3.0 et sur lesquels nous reviendrons dans la seconde partie de cet article. Enfin la dernière présentation nous a été proposée par Chris Eidhof qui nous a fait la démonstration d’une optimisation de code en utilisant les “generics”, le tout au cours d’un live coding à 100 à l’heure.

Voilà pour le déroulement de la journée. Il faut avouer que je suis sorti du théâtre des Variétés relativement déçu de cette après-midi. On nous a présenté un nombre impressionnant de librairies tierces ou servi des banalités sur le changement de sphère du développement Swift mais rien de bien épatant. Je retiendrai tout de même la dernière session bien au dessus des autres (notamment le live coding). Et même pas un petit tee-shirt DotSwift pour atténuer cette frustration. Daniel Steinberg a eu beau essayer de porter cette conférence avec ses questions ouvrant le débat, la mayonnaise n’a tout simplement pas pris.

Back to Swift

apple_swift_2_thumb800

Revenons à notre sujet principal, Swift !
Le langage est encore jeune puisqu’il n’existe que depuis 1 an ½. De ce fait il évolue encore rapidement. Il est passé depuis septembre 2015 en version 2.0. Je vous propose de faire un tour des nouveautés de cette version.

Binding

Avec Swift, les optionals sont omniprésentes. Et pour unwrapper un optional la meilleure solution reste la boucle “if let”. Le problème de la version 1.0 était donc une possible imbrication multiple de boucle “if let”, rapidement appelée par les développeurs, la pyramid of doom :

if let head = head {
    if let nose = nose {
        if let mouth = mouth {
            // good stuff here!
        }
    }
}

Dans Swift 2.0, Apple a introduit une nouvelle fonctionnalité qui nous permet d’éviter cette pyramide, le guard. Le principe est simple, on va effectuer le binding des différents optionals et fournir une closure “else” qui sera appelée si l’une des conditions n’est pas remplie. Dans le cas contraire, on continue l’exécution du code sans optionals (puisqu’ils viennent d’être unwrappé).

guard let head = head, nose = nose, mouth = mouth else {
    // sorry, no stuff here :[
    return
}

// at this point, head, nose and mouth are unwrapped and bound!

Il faut noter que l’utilisation du guard est bien plus large que la vérification de multiples « if let », il permet de tester des préconditions et de sortir d’une méthode si celles-ci ne sont pas validées. On peut donc vérifier des conditions « if let » comme ci-dessus mais également toutes autres conditions nécessaires à la poursuite de l’exécution de la méthode.

Error Handling

Swift 2 ajoute des sécurités supplémentaires lors de la remontée d’erreurs. On peut désormais utiliser le mot clé throws pour vérifier quelles fonctions ou méthodes peuvent lever une exception. Une fois cette déclaration faite, on utilisera les mots clés do, try, et catch lorsque l’on appellera un élément qui peut lever une exception. Puisque quelques lignes de code valent mieux qu’un long discours :

// 1
enum DrinkError: ErrorType {
    case NoBeerRemainingError
}

// 2
func drinkWithError() throws {
    if beer.isAvailable() {
        // party!
    } else {
// 3
        throw DrinkError.NoBeerRemainingError
    }
}

func tryToDrink() {
// 4
    do {
        try drinkWithError()
    } catch {
        print("Could not drink beer! :[")
        return
    }
}

Analysons un peu ce code :

  • Dans la partie 1, on crée un enum de type ErrorType qui va nous permettre de répertorier nos différentes erreurs
  • Dans la partie 2, on utilise le mot clé “throws” pour spécifier que la fonction “drinkWithError” peut potentiellement lever une erreur
  • Dans la partie 3, on déclenche une exception avec le mot clé “throw”. Elle sera alors traitée par la closure “catch”
  • Dans la partie 4, on regroupe tout le code qui peut lever une exception dans un block “do”, on ajoute ensuite le mot clé “try” avant chaque instruction qui est susceptible de lever une exception.

Les APIs qui utilisent NSError utilisent désormais ce système. Il faut donc s’attendre à souvent utiliser ce genre de code.

pokemon-exception-handling

Et bien d’autres choses

Il serait long de référencer toutes les nouveautés de Swift 2.0, je vous propose donc une petite liste non exhaustive

  • Les extensions de protocoles : on pouvait étendre les classes et les structures en leur ajoutant des méthodes, c’est désormais également le cas avec les protocoles
  • Changement de syntaxe : la liste n’est pas exhaustive mais swift 2.0 modifie la syntaxe de certaines méthodes et classes. Ainsi “println” devient tout simplement “print”, le protocole “Printable” devient quand à lui “CustomStringConvertible”…
  • Open Source : c’est sûrement la plus grosse nouveauté de Swift 2.0. Apple a rendu son langage open source depuis le 3 novembre 2015.

Swift everywhere (or not)

Dans Swift 2, Apple s’est appliqué à rendre son langage plus sûr et plus performant. Malgré tout le langage évolue encore rapidement et il y aura encore quelques dépréciations lors du passage à Swift 3.0

opensourceCette nouvelle version est attendue pour le printemps 2016 et sera axée sur la stabilité et la portabilité de Swift. Cet objectif découle naturellement du passage de Swift en open source. L’intérêt d’avoir passé Swift open source est de voir son utilisation s’étendre au delà du développement dans un environnement Apple. Demain on pourrait imaginer un serveur back-office en Swift, un site web avec un framework Swift (une première version existe déjà avec Vapor). Pour rendre cette portabilité possible Apple a besoin d’apporter de la stabilité à son langage. On imagine donc très bien que les versions qui succéderont à la 3.0 apporteront de nouvelles fonctionnalités en évitant les dépréciations.

L’horizon semble donc plutôt dégagé pour Swift, qui est ressorti comme le langage le plus aimé en 2015, d’après un sondage de Stack Overflow. Toutefois la route sera encore longue avant que Swift soit présent partout puisqu’à ce jour, son taux d’utilisation reste relativement faible. Par exemple, si l’on prend le top 100 des applications gratuites de l’AppStore, seules 11 d’entre elles contiennent du code Swift. Malgré ces chiffres il ne fait aucun doute que Swift a réussi son entrée et qu’il sera rapidement incontournable dans l’univers Apple et pourquoi pas au delà.

Pour ma part je ne sais pas si j’assisterai à la DotSwift 2017 tant l’édition de cette année m’a déçu, mais je sais que je continuerai à développer en Swift et à suivre de près son écosystème naissant pour ne pas rater “The Next Big Thing”.

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


+ 9 = onze