Démarrer sur Swift ou Objective-C ?

Le nouveau langage SWIFT mis en avant par Apple il y a quelques mois a pour objectif (dans un délai plus au moins long) de remplacer le langage actuel des applications OS X / IOS à savoir Objective-C.

Apple a dans le passé déjà effectué ce type de "migration" technique avec un certain succès.

Les applications "publiées" (entre 1 à 2 millions) écrites en Objective-C ne seront pas toutes réécrites en SWIFT, c'est un fait.

Réécriture partielle en SWIFT ? réécriture totale en SWIFT ? ajout de nouvelles fonctionnalités en SWIFT ?

Nous aurons probablement tous les cas de figures.

Ce qui est sûr c'est qu'il va falloir maintenir toutes ces applications - encore de beaux jours en perspective pour le code en Objective-C.

Pour finir ce constat, SWIFT est un langage plus moderne et plus "robuste" (d'après Apple) que Objective-C.

SWIFT est donc en droit de prendre la suite et de s'imposer "naturellement" chez les développeurs.

Mais de l'aveu de certains développeurs, SWIFT restera quand même lié à Objective-C.

Mais les choses sont un peu plus compliquées lorsque nous devons faire réellement le choix entre ces deux langages ?

Apprendre un langage, le maîtriser est un investissement important et assez long.

Il n'y a pas une réponse simple à la question posée par cet article.

Nous allons examiner quelques aspects qui vous aideront à prendre une décision.


Le premier aspect à prendre en considération est la nature de votre activité : exercez-vous le développement dans un contexte particulier ou professionel ?

Nous sommes d'accord que les conséquences ne sont pas les mêmes.

• Pour un particulier, apprendre SWIFT peut être très intéressant, sans réel impact économique, financier et professionnel.

Peut-être maîtrise t-il déjà Objective-C ?

Que du "bonus" !

Etant "dégagé" de la "pression" professionnelle, il peut acquérir des compétences dans un délai que lui seul fixe; compétences qui pourront au demeurant lui être utiles.

• Pour un professionnel, ses compétences sont liées à son Curriculum Vitae, à sa "carte de visite"

Une compétence est "validée" au bout d'un certain temps (validation par applications publiées, expertise technique reconnue).

Lorsqu'elle est "validée", il a plutôt intérêt à asseoir son expertise et à la maintenir à niveau.

Acquérir une autre compétence est évidemment un plus très intéressant, nécessaire à tout développeur professionnel moderne mais doit être bien réfléchie.

Si le développeur débute dans l'environnement Apple, l'apprentissage de SWIFT est judicieux.

Il investit au moins sur les 5 prochaines années.

Ce qui ne l'empêchera pas (et c'est fortement conseillé) d'apprendre Objective-C dans un deuxième temps.

Si le développeur est déjà un développeur Objective-C, qu'il a publié des applications pour le compte de ses clients ou pour le compte des clients de son entreprise alors l'apprentissage de SWIFT peut se faire en "tâche de fond".

Il pourra ainsi progressivement acquérir des compétences en SWIFT, les appliquer à ces projets actuels, voire futurs.

Une double compétence est très appréciée.

En "tâche de fond" implique à la fois de se fixer une période "butoire" (délai raisonnable) pour l'apprentissage et de consacrer une partie réelle de notre activité à cet apprentissage.


Un deuxième aspect est le degré de facilité d'apprentissage entre Objective-C et SWIFT.

Pour beaucoup de développeurs Objective-C est plus "rapide" à apprendre que SWIFT.

D'autre part, la communauté mondiale Objective-C est importante offrant ainsi un support technique riche de plusieurs années de maîtrise et d'expériences.

Avoir accès à un support technique d'un langage qui existe depuis plusieurs années peut rassurer le développeur.

SWIFT étant plus moderne, il "embarque" des concepts certes plus concis et plus faciles à lire (code plus allégé) mais qui peuvent nécessiter un apprentissage plus approfondi et donc plus long.


Un dernier aspect est la possibilité qu'offre Apple de "mixer" ces deux langages.

Nous pouvons "aisément" faire cohabiter du code SWIFT avec du code Objective-C au sein d'une même application.

Objective-C / Notification manager : un couple fort utile !

La Notification en Objective-C a été conçue dans l'esprit des Design Patterns ("patron de fabrication").

Nous parlons d'ailleurs en Objective-C du pattern <Notification>.

Le principal avantage des patterns est de minimiser le "couplage" ou liens entre les objets manipulés.

Ce qui permet d'obtenir un modèle objets / données plus allégé et de faciliter le travail des développeurs.

Revenons à notre pattern <Notification>.

Un objet peut ainsi diffuser des informations à d'autres objets sans tout connaître de ceux-ci.

Les objets qui souhaitent recevoir les informations "s'abonnent" (Les Obversateurs).

Chaque notification est gérée par le Notification Manager (ou centre de notification).

Son objectif est de distribuer les notifications.

Comment déclarer le Notification Manager ?

Prenons la classe MaClasse.m :

- (void) awakeFromNib {  
... 

    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];     

}

Comment "s'abonner" à une notification ?

- (void) awakeFromNib { 
...

  [nc addObserver:self selector:@selector(windowWillClose:) name:NSWindowWillCloseNotification         object:self.window];

}

- (void) windowWillClose: (NSNotification *)notification {    

...

}

Dans cet exemple nous nous "abonnons" à l'événement <NSWindowWillCloseNotification> (événement système qui est généré lors de la fermeture d'une fenêtre).

Nous pouvons aussi nous "abonner" à une notification applicative.

static NSString * const Notification1 = @"MaNotification";

- (void) awakeFromNib { 
...

  [nc addObserver:self selector:@selector(ma_fonction:) name:Notification1 object: nil];

}

- (void) ma_fonction: (NSNotification *)notification {    

...

}

Dans cet exemple nous nous "abonnons" à la notification <Notification1> - notification définie par l'application.

A noter que dans la méthode <ma_fonction>, nous pouvons gérer les informations propres à la notification (paramètre <notification>).

Exemple de la gestion des informations d'une notification :

- (void) ma_fonction : (NSNotification *) information
{
    NSString *valeur = [[information userInfo] objectForKey: @"cle1"];

...

}

Dans cet exemple, nous récupérons la valeur de la clé "cle1".

Les informations sont gérées sous forme de "dictionnaire" (clé / valeur).

Comment "publier" ou poster une notification ?

Prenons la classe MaClasse2.m.

static NSString * const Notification1 = @"MaNotification";

- (void) awakeFromNib {  
... 

    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];     

}

- (void) ma_fonction {

   NSMutableArray *key = [[NSMutableArray alloc] init];

    

   [key addObject: @"cle1"];
   [key addObject: @"cle2"];

    

   NSMutableArray *value = [[NSMutableArray alloc] init];

   [value addObject: @"valeur1"];
   [value addObject: @"valeur2"];

   NSDictionary *dict = [NSDictionary dictionaryWithObjects: value forKeys: key];

    

   [nc postNotificationName: Notification1 object:self userInfo: dict];  

    

   [key release];
   key = nil;

    

   [value release];
   value = nil;

}

Nous "publions" une notification avec un dictionnaire des données composé de 2 couples clé / valeur.

La gestion des notifications sous Objective-C est puissante mais trop de notifications peuvent nuire à la lisibilité de votre application.

La création d'une notification doit donc se réfléchir.

Ma notification sera t-elle utilisée amplement par les objets de mon application ?