Cours Objective-C

Cours Objective-C Gestion des notifications et des événements


Télécharger Cours Objective-C Gestion des notifications et des événements

★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :


4

Gestion des notifi cations et des événements

Dans ce chapitre, nous abordons le système de notifi cations utilisé en Objective-C. Dans le jargon Cocoa, les termes événement (event) et notifi cation (notifi cation) désignent deux concepts très proches, mais distincts, qui sont en général confondus dans par les autres langages de programmation sous le terme événement (par exemple, par Java ou C#).

Pour nous, le terme événement désigne une action provenant du matériel (souris, clavier, etc.), tandis que notifi cation désigne le moyen par lequel un objet notifi e les autres objets de l’occurrence d’un événement logiciel. Ce système ce base sur le modèle de conception (design pattern ) appelé publication/abonnement (publish/subscribe) qui fera l’objet de la première section.

Principe du modèle de conception publication/abonnement

Les développeurs C# et Java sont habitués à l’utilisation d’objets de type événement pour la gestion des événements : C# possède le mot-clé event permettant d’introduire un membre de type événement parmi les différentes variables d’instance de votre classe. Java permet d’obtenir le même résultat, mais en dérivant une nouvelle classe depuis java. util.EventObject. Le modèle de conception implémenté ici au niveau langage est le modèle observateur/observable.

Ce modèle consiste donc à mettre en relation directe les objets intéressés par les changements d’états d’un autre objet. On dit alors que les objets observateurs s’abonnent à certains événements de l’objet tiers (observable ) qui prend alors à sa charge le rôle de les notifi er lorsqu’une certaine propriété est modifi ée ou lorsqu’un certain événement se produit.

Objective-C propose une généralisation de cette approche, appelée le modèle de conception publication/abonnement : ce ne sont pas les ici les observables

Principe du modèle de conception publication/abonnement 

(objets observés) qui prennent à leur charge d’informer les observateurs, mais un intermédiaire appelé centre de notifi cations qui, dans le cas de Cocoa est une instance de la classe NSNotifi cation Center .

Un centre de notifi cations est donc tout simplement un objet qui prend à sa charge la transmission des notifi cations depuis l’objet émetteur vers l’objet observateur. Une analogie serait par exemple Tweeter : vous (objet observé) envoyez un tweet (notifi cation) à qui occupe le rôle du centre de notifi cations qui va l’acheminer vers le destinataire (observateur) en leur envoyant, par exemple, un SMS.

Cette implémentation est plus générique et découple totalement les différents objets : un objet éditeur envoie ses événements au centre de notifi cations et n’a donc besoin de rien savoir a propos de ses abonnés, et les abonnés ne communiquent qu’avec le centre de notifi cations.



Les principaux avantages résultant de ce découplage sont qu’un objet envoyant une notifi cation n’est pas en charge de savoir si des observateurs sont abonnés, et de plus le centre de notifi cations faisant offi ce d’intermédiaire, l’objet n’a pas non plus besoin de savoir si les objets sont locaux ou pas. Il est ainsi possible d’abstraire les communications distantes et de créer des systèmes distribués très facilement.

Obtenir le centre de notifi cations par défaut

 

Chaque processus dispose d’un centre de notifi cations par défaut, et vous n’avez pas à créer d’instance de cette classe. Vous obtenez l’instance par défaut en envoyant le message defaultCenter  à l’objet-classe NSNotifi cationCenter .

Comme nous l’avons vu dans la section précédente, il est possible de créer de manière transparente un centre de notifi cations distribué.

NSNotifi cationCenter n’envoie les notifi cations que dans le processus en cours d’exécution. Mais il existe également NSDistributedNotifi cationCenter  qui permet d’envoyer les notifi cations vers différents processus (uniquement en local dans l’implémentation actuelle). Les notifi cations distribuées sont beaucoup plus lourdes, il ne faut donc pas de les utiliser par défaut.

Les notifi cations distribuées sont très importantes pour le développement d’applications distribuées.

Toutefois, NSDistributedNotifi cationCenter et les sujets relatifs sortent du cadre de cet ouvrage et nous vous recommandons de vous reporter à la documentation d’Apple pour les découvrir.

Poster une notifi cation synchrone

Poster une notifi cation synchrone

    [[NSNotifi cationCenter defaultCenter]

? postNotifi cation:[NSNotifi cation

? notifi cationWithName:@“maNotifi cation”

? object:instance]]; //équivalent à :

NSNotifi cation * notif = [NSNotifi cation

? notifi cationWithName:@“maNotifi cation”

? object:instance]

[[NSNotifi cationCenter defaultCenter]

? postNotifi cation:notif]; //équivalent à :

[[NSNotifi cationCenter defaultCenter]

? postNotifi cation:@“maNotifi cation”

? object:instance]];

Comme vous pouvez le voir, il est assez simple d’envoyer une notifi cation synchrone : il suffi t de créer une nouvelle instance de NSNotifi cation et de l’envoyer au centre de notifi cations par défaut.

Il est également possible d’envoyer directement le message postNotifi cation  au centre par défaut avec les arguments nécessaires à la création de l’instance de NSNotifi cation, et le centre de notifi cations gérera le reste.



Il existe trois versions de la méthode postNotifi cation, deux d’entre-elles étant des versions simplifi ées de la principale :

–  postNotifi cation:  //version principale

                  //NSNotifi cation comme argument

–  postNotifi cationName:object: //userInfo est null– postNotifi cationName:object:userInfo:

Voici un autre exemple montrant l’utilisation de postNotifi cationName:object:userInfo: et donc également comment il est possible de passer des informations supplémentaires sous la forme du dictionnaire userInfo :

NSDictionary* dic = [NSDictionary

? dictionaryWithObjectsAndKeys: @“clef1”,

? [NSNumber numberWithInt:1], @“clef2”, ? [NSNumber numberWithInt:2], @“clef3”,

? [NSNumber numberWithInt:3], nil];

[[NSNotifi cationCenter defaultCenter]

? addObserver:instance

? selector:@selector(affi cherNotifi cation:)

? name:@”maNotifi cation” object:instance];

[[NSNotifi cationCenter defaultCenter]

? postNotifi cationName:@“maNotifi cation”

? object:instance userInfo:dic];

Les notifi cations envoyées ainsi au centre de notifi cations sont synchrones : la méthode postNotifi cation: ne rend la main qu’une fois toutes

Poster une notifi cation asynchrone

les notifi cations envoyées et que les observateurs ont traité la notifi cation. C’est donc une manière de procéder peu performante.

Poster une notifi cation asynchrone

NSNotifi cation * notifi cation =  [NSNotifi cation

? notifi cationWithName:@“maNotifi cation”

? object:instance userInfo:dic];

[[NSNotifi cationQueue defaultQueue]

? enqueueNotifi cation:notifi cation 

? postingStyle:NSPostASAP];

Comme nous l’avons vu à la section précédente, les envois de notifi cations au centre par défaut via les différentes méthodes postNotifi cation: sont synchrones. Il est possible d’envoyer les notifi cations de manière asynchrone, via l’utilisation des fi les d’attente de notifi cations, instances de la classe

NSNotifi cationQueue. Nous verrons dans la section suivante que ces fi les fournissent une seconde fonctionnalité très importante.

La méthode de classe defaultQueue  retourne la fi le d’ attente par défaut du centre de notifi cations par défaut.

Info

 

Dans l’exemple précédent, nous avons créé une instance de NSNotifi cation que nous passons à la fi le d’attente par défaut via la fonction enqueueNotifi cation:postingStyle:. Nous avons dissocié l’appel en deux étapes afi n d’améliorer la lisibilité du code dans l’ouvrage. En général, les développeurs Objective-C préfèrent les appels imbriqués.



 

Il existe trois différentes manières d’envoyer la notifi  cation, qui sont défi nies dans le fi chier NSNotifi cation.h  sous la forme d’une énumération :

 

•    Comme son nom l’indique NSPostNow  signifi e que la notifi cation doit être envoyée immédiatement. La notifi cation ne sera donc pas asynchrone, mais bénéfi ciera toutefois de la fonction de regroupement (coalescing) des notifi cations de la fi le d’attente. Vous la découvrirez à la section suivante.

•    Lorsque vous avez besoin d’accéder à une ressource rare ou chère, et que vous souhaitez toutefois que votre notifi cation soit envoyée dès que

Poster une notifi cation asynchrone

possible, vous utiliserez le style NSPostASAP  (As Soon As Possible, dès que possible). Cette méthode est asynchrone et retourne immédiatement.

•    Enfi n, NSPostWhenIdle  propose d’envoyer la notifi cation lorsque la fi le d’attente est en attente de nouvelles notifi cations. Cela signifi e que

NSPostWhenIdle est une manière d’envoyer les notifi cations avec une priorité minimale. Cette méthode est asynchrone et retourne immédiatement.

Info

 

Chaque thread dispose d’une fi le d’attente par défaut, mais il est possible de créer vos propres fi les d’attente et les associer au centre de notifi cations et à vos thread. Ceci est une utilisation avancée qui ne sera pas traitée dans ici, et nous vous renvoyons donc à la documentation d’Apple.

 

Il est possible de retirer une notification d’une fi le d’attente grâce à la méthode dequeueNotifi cations-

Matching:coalesceMask: de NSNotifi cationQueue. Son fonctionnement est similaire à celui de la méthode removeObserver:name:object: de NSNotifi cationCenter, mais contrairement à celle-ci, son utilisation reste très rare.



470