netinfluence's blog » best practices

Comment faire grandir son business sur Facebook: le cas de Dein Deal

Daniel — Fri, 25 Mar 2011 09:37:13 +0000

Le dernier intervenant de la conférence Branding & Social Media, Flavio Rump, est co-fondateur de deindeal.ch. Il nous a parlé du meilleur moyen pour faire grandir son business sur Facebook.

Dein Deal est passé de 5 à 50 employés en 5 ans et est présent dans de nombreuses régions suisses. Business à la Groupon, Dein Deal propose une affaire par jour avec un rabais allant de 50 à 70%. 100’000 coupons ont déjà été vendus!

Dein Deal de part sa présence sur internet, se doit d’avoir une stratégie social média.

A chaque offre, un poste de l’offre est laissé sur leurs pages Facebook réparties par zones géographiques. S’en viennent automatiquement des commentaires laissés par les clients. Ceci permet à Dein Deal d’avoir tous types de feed-back et de mieux comprendre ce que désirent leurs clients. Par exemple, si un nombre important de personnes réclament un certain type de Deal, il sera fait selon les possibilités pour leur en proposer un. Dans un second temps, ceci permet de fidéliser une clientèle satisfaite qui sera enclin à partager des offres avec leurs amis.

Afin de mettre au courant des personnes n’ayant pas encore entendu parler de Dein Deal, de la publicité est faite sur Facebook. Cette publicité permet,grâce aux différents critères que propose Facebook, de cibler très précisément les personnes suséptibles d’être intéréssées par une offre.

Pour optimiser ces publicités: 30 différentes seront mises en ligne et leurs performances mesurées et suivient. Celle dont le taux de clic et de conversion marche le mieux sera gardée. Les autres publicités sont supprimées et leur budget reversé dans celui de la publicité qu’on aura décidé de garder.

Pour en savoir plus, voici ses slides.

Comment faire grandir son business sur Facebook?

View more presentations from Olivier Perez Kennedy

XCode: librairies statiques et catégories

macmade — Wed, 23 Jun 2010 14:56:36 +0000

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found at: http://www.gnu.org/copyleft/fdl.html

Il est souvent pratique de scinder un projet XCode en plusieurs parties distinctes: le code permettant de contrôler les différents éléments de l’interface, et le code indépendant de l’interface (outils, librairies, etc).
Une telle découpe présente de nombreux avantage, notamment un meilleur contrôle des options de compilation pour chaque partie ainsi q’un temps de compilation réduit, puisque chaque partie est compilée séparément, et uniquement en cas de besoin.
Cet article explique comment paramétrer un projet XCode pour une telle utilisation.

Création d’un projet

Nous allons tout d’abord créer un nouveau projet XCode pour iPhone (la procédure est exactement similaire dans le cas d’une application Mac OS X).

XCode crée par défaut les fichiers nécessaires au fonctionnement d’une application basique.

La section «Targets» comprend les différents éléments pouvant être produits par notre projet XCode.

Dans ce cas là, il s’agit d’une application. Ce type de cible est composée de la copie des resources (les fichiers XIB – interface utilisateur), de la compilation du code source de l’application, et finalement de la liaison (lainage) du code objet généré avec les librairies et frameworks utilisés par l’application.

Il est possible de définir pour une cible des paramètres de compilation spécifiques, via le menu contextuel,

Cibles

Un projet XCode peut être composé de plusieurs cibles. Cela est nécessaire si l’on intègre des librairies externes, mais cela peut également être pratique pour séparer un projet et ainsi optimiser la compilation de l’application finale.

Nous allons commencer par créer une nouvelle classe, que nous allons nommer «MethodProvider», dont le but est, comme son nom l’indique, de mettre à disposition des méthode génériques pour notre application.

Nous allons y intégrer une méthode statique nommée doSomething.

/* MethodProvider.h */

#import

@interface MethodProvider: NSObject
{}

+ ( void )doSomething;

@end

/* MethodProvider.m */

#import "MethodProvider.h"

@implementation MethodProvider

+ ( void )doSomething
{
NSLog( @"Method 'doSomething' called..." );
}

@end

Nous allons également appeler cette méthode depuis notre application, lorsque celle-ci aura terminé son chargement. Cela se passe dans la méthode «application:didFinishLaunchingWithOptions:» de la classe «MyAppAppDelegate»:

- ( BOOL )application: ( UIApplication * )application didFinishLaunchingWithOptions: ( NSDictionary * )launchOptions
{
[ window addSubview: viewController.view ];
[ window makeKeyAndVisible ];

[ MethodProvider doSomething ];

return YES;
}

Ne pas oublier d’include le fichier .h de la classe «MethodProvider» dans le fichier «MyAppAppController.m»:

#import "MyAppAppDelegate.h"
#import "MyAppViewController.h"
#import "MethodProvider.h"

Dans ce cas là, la classe «MethodProvider» est compilée avec les autres fichiers sources de notre application. Nous allons maintenant faire en sorte qu’elle le soit séparément.

En premier lieu, nous allons ôter cette classe de la cible de notre application. Cela peut être effectué en décochant la case à côté du fichier source.

A partir de ce moment là, la classe ne sera plus compilée en même temps que l’application. La compilation de l’application va donc échouer avec le message suivant:

_OBJC_CLASS_$_MethodProvider", referenced from:
objc-class-ref-to-MethodProvider in MyAppAppDelegate.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Ce message veut tout simplement dire que le linker n’a pas réussi à trouver le symbole correspondant à notre classe, alors qu’il est utilisé depuis la classe MyAppAppDelegate.

Nous allons donc créer une nouvelle cible, qui aura pour but de compiler la classe «MethodProvider».

Librairie statique

Cette cible sera de type «static library»:

Une librairie est un format spécifique de code object (compilé), dont le but est de fournir des fonctions aux applications désirant les utiliser. Une librairie peut être de deux types: statique ou dynamique.

Dans le cas d’une librairie statique, le code objet de la librairie est intégré au binaire de l’application lors de la compilation.
Il en résulte un seul fichier binaire, contenant à la fois le code de l’application et le code de la librairie. Le binaire est donc plus lourd, mais la libraire n’a pas besoin d’être présente sur la machine hôte.

Dans le cas d’une librairie dynamique, seul son adresse est inclue dans le code de l’application, et c’est le kernel (via un linker) qui chargera le code de la libraire en mémoire à chaque fois que l’application est lancée. Le binaire est dans ce cas plus léger, mais la librairie doit impérativement être présente sur la machine hôte. Le temps de lancement de l’application peut en outre être un peu plus long. Le principal avantage d’une librairie dynamique est que plusieurs applications peuvent reposer sur la même librairie.

Dans notre cas, c’est donc bien sûr une libraire statique qu’il nous faut. Qui plus est, sur iOS, il est actuellement impossible de générer une libraire dynamique.

Lorsque plusieurs cibles sont disponibles, XCode permet de passer de l’une à l’autre via un menu déroulant, se trouvant dans la barre d’outils:

Nous pouvons donc passer sur notre cible «Methods», et y ajouter le(s) fichiers devant être compilés:

Nous pouvons également voir, au passage, notre librairie dans la section «Products»:

Il nous reste à lier notre application principale avec cette librairie. Cela est effectué depuis la phase «Link Binary With Libraries» de la cible de l’application.

Nous pouvons maintenant y ajouter notre librairie.

La dernière étape consiste à indiquer à XCode que notre application dépend de la librairie, pour que cette dernière soit compilée avant l’application, en cas de besoin. Cette opération est effectuée en ajoutant une dépendance, dans la section «General», dans les informations de la cible de l’application:

Nous pouvons maintenant compiler notre application sans problème.

Cette procédure peut être utilisée, comme dans cet exemple, pour séparer différentes parties de notre code.
C’est également la procédure à utiliser lors de l’utilisation de sources et librairies externes, comme par exemple OpenCV (C++), JSON-Framework (Obj-C), etc.
Il est bien sûr possible d’inclure les fichiers sources dans la même cible que l’application, mais un tel scénario nous prive de la possibilité de spécifier des paramètres de compilation spécifiques et risque de rallonger inutilement le temps de compilation de la cible principale.

Catégories

Il faut encore noter que, dans le cas de l’utilisation de catégories, l’utilisation d’une librairie statique peut se révéler problématique.
Pour rappel, en Objective-C, une catégorie permet d’ajouter des méthodes dans une classe existante.

Ajoutons donc une catégorie sur UIApplication, dans la cible de notre librairie:

/* MyUIApp.h */

#import

@interface UIApplication( MyUIApp )

- ( void )sayHello;

@end

/* MyUIApp.m */

#import "MyUIApp.h"

@implementation UIApplication( MyUIApp )

- ( void )sayHello
{
NSLog( @"Hello" );
}

@end

Et utilisons cette méthode dans notre application:

/* MyAppAppDelegate.m */

- ( BOOL )application: ( UIApplication * )application didFinishLaunchingWithOptions: ( NSDictionary * )launchOptions
{
[ window addSubview: viewController.view ];
[ window makeKeyAndVisible ];

[ MethodProvider doSomething ];
[ application sayHello ];

return YES;
}

Sans oublier d’inclure le fichier header:

#import "MyUIApp.h"

La compilation se déroulera sans aucun problème, mais l’application plantera, avec le message suivant (affiché dans la console):

- [ UIApplication sayHello ]: unrecognized selector sent to instance 0x5911700

Ce cas particulier est dû au côté dynamique d’Objective-C (la résolution des méthodes est faite par la couche run-time), est au spécificités du linker, qui ne génère par défaut pas de symboles pour les catégories.

Pour régler ce problème, il suffit de modifier les paramètres du linker, dans les informations de la cible de l’application, et y ajouter, dans la section «Other Linker Flags»:

-ObjC -all_load

Second Day of Marketing 2 Conference

sandrine — Fri, 26 Mar 2010 10:42:06 +0000

The second day of the conference offered quite a few tracks on media and poor sales pitch of speaking sponsors. To me, most of the presentations, unlike day1, were useless. I however met up with some really interesting people, had a long talk about 2011 version of the event with Emmanuel Vivier (which was really interesting, looking forward) and discussed with Jean François Ruiz about his upcoming (and quite interesting) new product (much ado about social media profiling). So my day, although poor in inspiration, was really rich networking wise!

But, 1 presentation struck me and actually made my day. Oke Müller, from TBWA did a superb and well handled keynote. I filmed it and you must see the videos : Oke Muller part 1- Oke Muller part 2 – Oke Muller part 3.

Also worth mentioning the EA presentation, Fererro, innocentive and of course our national Matthias Luefkens. I am just sad my battery went of due the (never ending) presentation of Marc Davis, so the last presentation were either shortened (that of matthias) or taken from my mac

Next year I will not forget my charger…promise

So, to wrap up with all this, yes this year edition, thanks to Nils, to Emmanuel and their teams was great. I will and you should come next year!

I hope that next year we get more of the Crispin and bogulsky or TBWA type of presentations and no more media boring stuff. Maybe we too get the chance for prior the event animation (contest? agencies involved in the buzzing the conference, list of attendees and a feed of their tweets or blogs) and no more of the web 0 type of stuff like flyers distributed or crapy sponsor presentations. Boy, this is not because you pay for the conference, you have to give boring sales pitch! Maybe danone could create a product discovery and arrange a nice lounge area for people to experience a nice time during the breaks, so could Evian or Lego too. Maybe the organizer should show the backchannel via visibletweets so that presenters get to be challenged and people in the room get to read what is said.
Please, Nils, limit speakers to 10 minutes. I did only take the last 10 minutes (to be allowed to download on youtube) of each presentations and believe me, the interesting bits fit in that, rest is boring! Keep the schedule (you can’t be 2 hours late already at lunch time!)
Food was nice, Wifi slow (but existing) and you did very well because, amonsgt the conference I attended, this one is one that brings me most value from a marketing standpoint. So thank you and keep up the good (very good!) work.

You can access all the other video via our netinfluenceChannel on youtube.

Brand engagement via social networks – Business Cases from the M2C

sandrine — Tue, 23 Mar 2010 06:00:34 +0000

Marketing2Conference, I attended last year for the first time, happened to be a great discovery. Full of business cases and testimonial of humble brands explaining how they were trying their way out on social media, we were offered a very valuable content.

What happens when you liked it one year, is that you expect the content to keep the good pace but often get disapointed. Definetly, the M2C conference is really an exception to this rule.

The content this year is even more interesting. Probably because a lot of brands did some trial and learnings over the past year, but most obviously because of the good combination of Nils Andres powerful network and of the vanksen team relentless efforts to keep up with good buzz.

So, this year, to get prepared for the good, I came up with my brand new video to keep track of the best bits.

And what I did was quite special. I decided to only film the last 10 minutes. Most of the presenters only start to get in the really good stuff at the end. And believe it or not, apart from one presentation (dunkin donut) I indeed captured the best extracts.

So here is my contribution to sharing the best of best of reknown brands best practices in terms of brand advocacy using web 2.0 strategies.

I really advise my favorites, namely dunkin donut for the clever online strategy, P&G for the cognitive approach, Emmanuel Vivier for the “get real” message to customers, Evian for the master presentation of their latest incredible viral campaign and wallmart for their ability to catch the train – late – but successfully.

Hope you will like the videos. And if you do, please leave me comments and ranks the videos accordingly so that I get a feedback of how you like them too

Here is the evian video:

You can access all the other video via our netinfluenceChannel on youtube.

Méthodes privées en Objective-C

macmade — Thu, 04 Mar 2010 12:44:02 +0000

Introduction

En Objective-C, contrairement à de nombreux autres langages orientés objet, le concept de méthode privée n’existe pas en tant que tel.

Dans la déclaration de l’interface d’une classe, il est possible de définir une visibilité pour les variables d’instances.

Par exemple:

@interface Foo: NSObject
{
@public

id somePublicObject;

@protected

id someProtectedObject;

@private

id somePrivateObject;
}

+ ( void )someStaticMethod;
- ( void )someMemberMethod;

@end

Les variables d’instances peuvent être regroupées en fonction de leur visibilité: publique (accessible depuis l’extérieur), protégée (accessible depuis la classe et les classes filles), et privée (accessible depuis la classe uniquement).

Il n’existe rien de tel pour les méthodes, au niveau de la déclaration de l’interface. Cependant, il est parfaitement possible d’implémenter le concept de méthodes privées, et ce de plusieurs façons.

Solution 1 – Implémentation

La première solution, et sans doute la plus évidente, consiste simplement à déclarer des méthodes dans l’implémentation.
Dans un tel cas, ces méthodes ne seront pas visibles depuis l’extérieur, étant donné qu’elles ne sont pas présentes dans l’interface.

Par exemple:

@interface Foo: NSObject
{}

- ( void )somePublicMethod;

@end

@implementation Foo

- ( void )somePrivateMethod
{}

- ( void )somePublicMethod
{
[ self somePrivateMethod ];
}

@end

Le principal problème avec cette approche est que les méthodes “privées” doivent impérativement être déclarées avant le code y faisant référence, sous peine d’une erreur lors de la compilation.
Dans l’exemple précédent, nous n’aurions pas pu déclarer “somePublicMethod” avant “somePrivateMethod”.
Dans certains cas, lors d’appels cycliques par exemple, il est tout simplement impossible d’utiliser cette solution.

Solution 2 – Fonctions statiques

Une deuxième solution consiste à l’utilisation de fonctions statiques.
En langage C, une fonction statique n’est visible que pour les fonctions se trouvant dans le même fichier.
Il est à noter que, bien que l’on utilise également dans ce cas le mot clé ‘static’, celui-ci à un tout autre sens que si on l’utilise pour une variable, à l’intérieur d’une fonction.

Autrement dit:

@implementation Foo

static void somePrivateFunction( void );
static void somePrivateFunction( void )
{}

- ( void )somePublicMethod
{
somePrivateFunction();
}

@end

Il s’agit d’une fonction, et non d’une méthode. Il est par contre possible, depuis cette fonction, d’accéder aux autres méthodes, et même aux variables d’instances.
Pour réaliser cela, il suffit de passer l’instance en paramètre de la fonction:

@implementation Foo

static void somePrivateFunction( Foo * obj );
static void somePrivateFunction( Foo * obj )
{
/* Appel d'une méthode de la classe */
[ obj someOtherMethod ];

/* Accès à une variable d'instance de la classe */
obj->someInstanceVariable = NULL;
}

- ( void )somePublicMethod
{
somePrivateFunction( self );
}

@end

Une instance d’une classe est tout simplement (ou presque) un pointeur vers une structure C. L’opérateur ‘->’ peut donc parfaitement être utilisé pour accéder à une variable d’instance, qui n’est autre qu’un membre de cette structure.

Solution 3 – Catégories

Une dernière solution, sans doute la plus propre, consiste à utiliser des catégories. Ces dernières sont utilisées pour ajouter des méthodes dans une classe existante.

Par exemple:

@interface Foo: NSObject
{}

- ( void )somePublicMethod;

@end

@interface Foo( private )

- ( void )somePrivateMethod;

@end

@implementation Foo

- ( void ) somePublicMethod
{
[ self somePrivateMethod ];
}

@end

@implementation Foo( private )

- ( void ) somePrivateMethod
{}

@end

Ici, nous définissons l’interface de la classe Foo, ainsi qu’une catégorie nommée “private” (ce nom peut être n’importe lequel).
Nous avons donc ensuite deux implémentations. Une pour les méthodes publiques, et l’autre pour les privées.
Au niveau des headers, seule l’interface de base doit être présente, bien évidemment. La déclaration de la catégorie doit se faire dans le fichier contenant l’implémentation.

Il est à noter qu’il est également possible avec ce système d’utiliser une seule et unique implémentation. Pour ce faire, il suffit de déclarer une catégorie sans nom:

@interface Foo: NSObject
{}

- ( void )somePublicMethod;

@end

@interface Foo()

- ( void )somePrivateMethod;

@end

@implementation Foo

- ( void ) somePublicMethod
{
[ self somePrivateMethod ];
}

- ( void ) somePrivateMethod
{}

@end

Dès lors, puisque les méthodes privées sont définies dans la catégorie, leur ordre de déclaration dans l’implémentation n’a plus aucune importance, contrairement à la première solution présentée ici.

Quelle solution choisir?

Ces trois solutions fonctionnent très bien. Personnellement, j’ai tendance à éviter la première, principalement en raison de l’ordre de déclaration, et aussi parce que les méthodes privées sont difficilement repérables dans le code.
L’utilisation de catégories permet au code de rester clair et lisible, l’implémentation des méthodes privées pouvant se faire dans un autre fichier que l’implémentation des méthodes publiques. Cela permet du coup d’identifier immédiatement la visibilité d’une méthode.

C’est donc cette troisième solution que je préconise, est qui certainement la plus adaptée au langage Objective-C.

Réseaux sociaux et bonnes pratiques

sandrine — Tue, 19 Jan 2010 11:05:07 +0000

Comment faire pour être présent sans ruiner sa réputation, ne pas y perdre trop de temps, suivre ses amis et développer de chaleureuses et constructives relations online ? C’est un savant mélange de naturel et de discipline et de beaucoup de bon sens selon moi. Voici les conseils que j’ai pu donner lors de mon interview par le Migros Magazine.

Closure et fonctions lambda en Objective-C

macmade — Wed, 11 Nov 2009 22:02:00 +0000

Définitions

De nombreux langages de scripts permettent l’utilisation de «fonctions lambdas», ou encore «fonctions anonymes», concept généralement lié au phénomène appelé «closure».
Il s’agit de concepts bien connus notamment en JavaScript, ActionScript, ou encore en PHP depuis sa version 5.3.
Le langage Objective-C offre depuis peu une implémentation de ces deux concepts, appelée «blocks».
Les blocks sont disponibles depuis Mac OS X 10.6 et l’adoption de Clang.

Fonctions anonymes

Comme son nom l’indique, une fonction anonyme est une fonction ne possédant pas de nom, ou d’identifiant. Elle ne contient que son contenu (body), et peut être associée à une variable, pour être ré-utilisée, ou passée en argument d’une autre fonction.

Ce phénomène est très souvent utilisé dans des langages de scripts, notamment pour des callbacks.

En JavaScript par exemple, imaginons une fonction standard nommée «foo», prenant en paramètre un callback, et l’exécutant dans son body:

function foo( callback )
{
callback();
}

Il est parfaitement possible de définir une autre fonction standard, et de la passer en paramètre de notre première fonction:

function bar()
{
alert( 'Hello World!' );
}

foo( bar );

Le problème dans un tel cas est que nous déclarons une fonction nommée «bar» dans le scope global. Il en découle un risque de collision avec une éventuelle autre fonction qui porterait le même nom.

Le langage JavaScript nous permet donc de déclarer la fonction utilisée comme callback lors de l’appel:

foo(
function()
{
alert( 'Hello World!' );
}
);

Notre callback n’a ici pas d’identifiant. Il n’existera pas dans le scope global, et donc ne risquera pas d’entrer en conflit avec une fonction existante.

Il est également possible de définir le callback comme variable. Il n’existera toujours pas dans le scope global, mais pourra ainsi être ré-utilisé à volonté via cette variable:

myCallback = function()
{
alert( 'Hello World!' );
};

foo( myCallback );

Closure

Le phénomène appelé «closure» consiste en la possibilité, pour une fonction, d’accéder aux variables disponibles dans son contexte de déclaration, ceci même dans le cas où son contexte d’exécution est différent.

Toujours en JavaScript, imaginons le code suivant:

function foo( callback )
{
alert( callback() );
}

function bar()
{
var str = 'Hello World';

foo(
function()
{
return str;
}
);
}

bar();

Notre callback, passé à la fonction «foo» depuis le contexte d’exécution de le fonction «bar» retourne une variable nommée «str».
Or, cette variable, déclarée dans le contexte de la fonction «bar», est une variable locale à cette dernière. Autrement dit, elle n’existe qu’à l’intérieur de ce contexte.
Comme notre callback est exécuté depuis un contexte différent du contexte de la déclaration de cette variable, on pourrait penser que le code-ci dessus n’affiche rien.
Mais c’est ici que le phénomène de closure intervient.
Quel que soit son contexte d’exécution, une fonction conserve un accès aux variables disponibles lors de sa déclaration.

Notre callback aura donc bien accès à la variable «str», même s’il est effectivement appelé depuis la fonction «foo», et que cette dernière n’y a pas accès.

Implémentation en Objective-C

Objective-C implémente ce genre de concepts, même s’il existe un certain nombre de subtilités, venant du fait qu’il s’agit d’un langage compilé dérivé du C, en restant très proche, donc très différent d’un langage de script interprété.

Il est à noter que le support des blocks est aussi disponible en C pur, ou en C++ (et donc en Objective-C++).

De même qu’une fonction standard en C, la déclaration d’un block (fonction anonyme) se doit d’être précédée par la déclaration de son prototype.

La syntaxe de déclaration d’un block n’est pas la plus évidente, mais on s’y fait relativement vite.
Voici par exemple le prototype d’un block:

NSString * ( ^myBlock )( int );

Nous déclarons ici le prototype d’un block («^»), destiné à être nommé «myBlock», prenant un argument unique de type «int», et retournant un pointeur sur un objet de type «NSString».

Nous pouvons maintenant déclarer le block:

myBlock = ^( int number )
{
return [ NSString stringWithFormat: @"Passed number: %i", number ];
};

Nous assignons donc à la variable «myBlock» le body d’une fonction, prenant comme argument «number» un entier. Cette fonction retourne un objet «NSString», dans lequel sera affiché cet entier.

Attention, ne pas oublier le point virgule à la fin de la déclaration du block!

Si cela est facultatif dans des langages de scripts, c’est absolument nécessaire pour un langage compilé comme Objective-C.
L’oublier résulterait en une erreur du compilateur, qui refuserait de générer l’exécutable final.

Le block peut désormais être utilisé, comme une fonction standard:

myBlock();

Voici le code complet d’un programme Objective-C, reprenant l’exemple précédent:

#import

int main( void )
{
NSAutoreleasePool * pool;
NSString * ( ^myBlock )( int );

pool = [ [ NSAutoreleasePool alloc ] init ];
myBlock = ^( int number )
{
return [ NSString stringWithFormat: @"Passed number: %i", number ];
};

NSLog( @"%@", myBlock() );

[ pool release ];

return EXIT_SUCCESS;
}

Un tel programme peut être compilé à l’aide de la commande suivante (Terminal):

gcc -Wall -framework Cocoa -o test test.m

Cela générera un fichier exécutable nommé «test», à partir du fichier source «test.m».
Pour lancer l’exécutable:

./test

La déclaration du prototype d’un block peut être omise dans le cas où le block n’est pas assigné à une variable, comme par exemple s’il est transmis directement comme argument.

Par exemple:

someFunction( ^ NSString * ( void ) { return @"Hello World!" } );

Il est à noter que dans un tel cas, le type de retour doit être déclaré. Ici, il s’agit d’un objet de type «NSString».

Passage d’un block comme argument

Un block peut bien sûr être passé comme argument d’une fonction C.
Là aussi, la syntaxe peut être quelque peu déroutante à première vue:

void logBlock( NSString * ( ^theBlock )( int ) )
{
NSLog( @"Block returned: %@", theBlock() );
}

Evidemment, comme Objective-C est un langage fortement typé, une fonction recevant un block en argument doit également déclarer son type de retour et le type de ses éventuels arguments.

Il en va de même dans le cas d’une méthode d’une classe Objective-C:

- ( void )logBlock: ( NSString * ( ^ )( int ) )theBlock;

Closure

Le phénomène de closure est également présent en Objective-C, même si son comportement est évidemment différent de celui des langages interprétés.

Imaginons le programme suivant:

#import

void logBlock( int ( ^theBlock )( void ) )
{
NSLog( @"Closure var X: %i", theBlock() );
}

int main( void )
{
NSAutoreleasePool * pool;
int ( ^myBlock )( void );
int x;

pool = [ [ NSAutoreleasePool alloc ] init ];
x = 27;

myBlock = ^( void )
{
return x;
};

logBlock( myBlock );

[ pool release ];

return EXIT_SUCCESS;
}

La fonction «main» déclare un entier, de valeur 27, ainsi qu’un block, retournant cette même variable.
Le block set ensuite passé à la fonction «logBlock», qui affiche sa valeur de retour.

Même dans le contexte d’exécution de la fonction «logBlock», le block déclaré dans la fonction «main» continue d’avoir accès à l’entier «x», et peut donc sans aucun problème en retourner la valeur.

Il est à noter que les blocks ont également accès aux variable globales, même statiques si elles sont disponibles dans le contexte du block.

Il existe ici une première subtilité. En effet, les variables disponibles depuis un block par le phénomène de closure sont de type «const». Autrement dit, elle ne peuvent être modifiées depuis l’intérieur du block.

Par exemple, imaginons que notre block incrémente la valeur de x avant de la retourner:

myBlock = ^( void )
{
x++

return x;
};

Le compilateur refusera ici de compiler le programme, puisque la variable «x» n’est disponible qu’en lecture pour notre block.

Pour qu’une variable puisse être modifiée depuis un block, il faut la déclarer avec le mot clé «__block».
Ainsi, le codé précédent est valide si l’on déclare la variable x ainsi:

__block int x;

Gestion de la mémoire

Au niveau C, un block est une structure, pouvant être copiée et détruite.
Deux fonctions C sont à disposition pour cet usage: «Block_copy()» et «Block_destroy».
En Objective-C, un block peut également recevoir les messages «retain», «release» et «copie», comme un objet.

C’est aspect peut-être extrêmement important dans le cas où un block doit être conservé pour une utilisation ultérieure (et par exemple stocké dans une propriété d’une classe).

Ne pas copier le block, ou ne pas effectuer de «retain» dans un tel cas peut en effet induire une erreur de segmentation.

Exemple d’utilisation

Les blocks peuvent être utilisés dans de très nombreux contextes, afin de simplifier le code, et réduire le nombre de fonctions déclarées.

Voici un exemple simple illustrant l’utilisation des blocks.

Nous allons ajouter à la classe «NSArray» une méthode statique permettant de générer un tableau en filtrant les éléments d’un autre tableau, à l’aide d’un callback.

Pour les amateurs de PHP, il s’agit ici d’un équivalent de la fonction «array_filter()».

Nous allons commencer par la déclaration d’une catégorie de la classe «NSArray». Pour rappel, une catégorie permet l’ajout de méthodes dans une classe existante, évitant ainsi le besoin de créer une sous-classe.

@interface NSArray( BlockExample )

+ ( NSArray * )arrayByFilteringArray: ( NSArray * )source withCallback: ( BOOL ( ^ )( id ) )callback;

@end

Nous déclarons ici une méthode retournant un objet de type «NSArray», et prenant en argument un autre objet «NSArray», ainsi qu’un callback, sous forme de block.

Ce callback sera exécuté pour chaque élément du tableau passé en argument. Il doit retourner une valeur booléenne, afin de savoir si l’élément courant du tableau source doit être conservé dans le tableau retourné. Le block prend donc comme unique argument l’objet courant du tableau source.

Voyons maintenant l’implémentation de cette méthode:

@implementation NSArray( BlockExample )

+ ( NSArray * )arrayByFilteringArray: ( NSArray * )source withCallback: ( BOOL ( ^ )( id ) )callback
{
NSMutableArray * result;
id element;

result = [ NSMutableArray arrayWithCapacity: [ source count ] ];

for( element in source ) {

if( callback( element ) == YES ) {

[ result addObject: element ];
}
}

return result;
}

@end

Nous créons en premier lieu un tableau de taille dynamique («NSMutableArray»), en lui allouant une capacité initiale correspondant au nombre d’entrées du tableau source.

Ensuite, nous itérons chaque élément du tableau source, et nous ajoutons l’élément courant dans le cas où le résultat du callback retourne la valeur booléenne «YES».

Voici un exemple de programme utilisant une telle méthode.
Ici, nous nous servons du callback pour créer un tableau ne contenant que les objets de type «NSString» du tableau source:

#import

@interface NSArray( BlockExample )

+ ( NSArray * )arrayByFilteringArray: ( NSArray * )source withCallback: ( BOOL ( ^ )( id ) )callback;

@end

@implementation NSArray( BlockExample )

+ ( NSArray * )arrayByFilteringArray: ( NSArray * )source withCallback: ( BOOL ( ^ )( id ) )callback
{
NSMutableArray * result;
id element;

result = [ NSMutableArray arrayWithCapacity: [ source count ] ];

for( element in source ) {

if( callback( element ) == YES ) {

[ result addObject: element ];
}
}

return result;
}

@end

int main( void )
{
NSAutoreleasePool * pool;
NSArray * array1;
NSArray * array2;

pool = [ [ NSAutoreleasePool alloc ] init ];
array1 = [ NSArray arrayWithObjects: @"Hello World!", [ NSDate date ], @"Hello Universe!", nil ];
array2 = [ NSArray
arrayByFilteringArray: array1
withCallback: ^ BOOL ( id element )
{
return [ element isKindOfClass: [ NSString class ] ];
}
];

NSLog( @"%@", array2 );

[ pool release ];

return EXIT_SUCCESS;
}

Implémentation d’un système de délégation multiple en Objective-C

macmade — Mon, 24 Aug 2009 17:24:00 +0000

1. Qu’est-ce que la délégation?

La délégation est un système présent dans plusieurs classes du framework Cocoa, sous Mac OS X (et donc également sur iPhone OS).
Ce système permet aux dévelopeurs d’applications Cocoa d’interagir en fonction d’événement précis liés aux fonctionnements intrinsèques des objets Cocoa.

Prenons par exemple l’objet NSWindow, qui comme son nom l’indique permet d’afficher et de contrôler une fenêtre.

Cet objet fenêtre possède un certain nombre de méthode, comme par exemple ‘close’, ou ‘open’, permettant respectivement d’ouvrir et de fermer le fenêtre en question.

Lors de la programmation d’une application Cocoa, il peut être fort utile d’être informé lors de l’ouverture ou de la fermeture d’une fenêtre, pour allouer ou libérer des ressources, terminer des tâches ou des threads, etc.

Le système de délégation du framework Cocoa permet ainsi d’attacher une instance d’un objet à un autre objet, le premier ayant la possibilité d’agir sur le second en fonction de ses différentes phases d’exécution.

La définition d’un objet délégué sur un autre objet se passe par convention par la méthode ‘setDelegate’, prenant en argument unique l’instance du délégué.

Par exemple, pour définir un objet de type ‘Foo’ comme délégué d’un objet NSWindow:

Foo      * foo    = [ [ Foo alloc ] init ];

NSWindow * window = [ [ NSWindow alloc ] initWithContentRect: NSMakeRect( 0, 0, 100, 100 ) styleMask: NSTitledWindowMask backing: NSBackingStoreBuffered defer: NO ];

[ window setDelegate: foo ];

Les deux premières lignes créent respectivement un objet de type ‘Foo’ (défini dans notre application), et un objet de type ‘NSWindow’ (du framework Cocoa).

La troisième ligne défini l’objet de type ‘Foo’ comme délégué de notre objet ‘NSWindow’.

A partir de ce moment, à supposer que l’on ferme notre objet fenêtre:

[ window close ];

L’objet délégué pourra être averti de cette opération, en implémentant tout simplement une méthode spécifique. Dans le cas précis, ‘windowWillClose’, dont voici le prototype:

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

Celle-ci permettra au délégué, juste avant la fermeture de la fenêtre, d’effectuer un certain nombre d’opérations, liées au bon fonctionnement de l’application.

2. Comment fonctionne la délégation?

Voyons maintenant comment l’objet ‘NSWIndow’ implémente et utilise son objet délégué.

L’objet ‘NSWindow’ contient bien sûr une variable d’instance de type ‘id’, représentant l’objet délégué, généralement nommée delegate, ainsi qu’une méthode permettant d’obtenir l’objet délégué, et une seconde permettant de le définir.

Autrement dit:

@interface NSWindow: NSObject

@protected

 id delegate;

- ( id )delegate;

- ( void )setDelegate: ( id )object;

@end

@implementation NSWindow

- ( id )delegate

 return delegate;

- ( void )setDelegate: ( id )object

 delegate = object;

@end

Ici, il est extrêmement important de préciser qu’un objet ne doit en aucun cas effectuer un ‘retain’ sur son objet délégué, car cela aurait comme effet un ‘memory leak’, autrement dit une zone de mémoire allouée à notre application qui ne serait jamais libérée.

Il est également à noter qu’en Objective-C 2.0, l’utilisation d’une propriété peut être utilisée dans l’interface, pour permettre un accès aisé à l’objet délégué:

@property( nonatomic, assign, readwrite ) delegate;

A partir de là, les getter/setter peuvent également être automatiquement délcarés dans l’implémentation:

@synthesize delegate;

Si l’on reprend maintenant l’exemple de la méthode ‘close’ de l’objet ‘NSWindow’:

- ( void )close

 // Do something...

 if( [ delegate respondsToSelector: @selector( windowWillClose ) ] ) {

 [ delegate windowWillClose ];

 // Do something...

}

A un instant précis dans l’exécution de la méthode ‘close’, l’objet ‘NSWindow’ se demande si son objet délégué possède une méthode nommée ‘windowWillClose’.
Si c’est le cas, elle l’exécute, et poursuit sa propre exécution.

La méthode ‘close’ n’a nullement besoin de vérifier si un objet délégué a été défini auparavant, étant donné qu’en Objective-C, envoyer un message (appeler une méthode) sur ‘nil’ (un pointeur NULL sur un objet) est parfaitement valide.

L’objet délégué sera donc averti, à supposer qu’il implémente la méthode ‘windowWillClose’, de la fermeture de l’objet ‘NSWindow’.

3. Délégation et notification

Le framework Cocoa inclut également un système de notification, permettant là aussi à des objets d’être informé des stades d’exécution d’autres objets.

Dans notre exemple précédent, nous aurions donc aussi pu, pour être averti lors de la fermeture de la fenêtre, écrire le code suivant.

[ [ NSNotificationCenter defaultCenter ] addObserver: foo selector: @selector( myObserverMethod: ) name: NSWindowWillCloseNotification object: window ]:

Autrement dit, on déclare que la méthode ‘myObserverMethod’ de l’objet de type ‘Foo’ doit être lancée lors de l’événement ‘NSWindowWillCloseNotification’ de la fenêtre. Dans ce cas, voici le prototype de la méthode ‘myObserverMethod’:

- ( void )myObserverMethod: ( NSNotification * )notification;

On peut donc ici se demander pourquoi ces deux systèmes cohexistent.
Ce qu’il faut bien comprendre, c’est que le système de notification permet uniquement d’être averti de certains événements, alors que le système de délégation permet en plus de modifier le comportement de l’objet concerné.

Prenons le cas de la méthode ‘windowShouldClose’, pouvant être implémentée dans le délégué d’un objet ‘NSWindow’, et dont voici le prototype:

- ( BOOL )windowShouldClose: ( NSWindow * )window;

On remarque que cette méthode retourne une valeur booléenne.

Si notre objet délégué implémente cette méthode, et qu’on lance la méthode ‘close’ sur notre fenêtre, cette dernière ne se fermera effectivement que dans le cas où la méthode du délégué retourne la valeur ‘YES’. Dans le cas contraire, elle restera affichée sur l’écran.

Cela peut par exemple permettre de bloquer le processus de fermeture de la fenêtre, pour afficher un message d’alerte demandant à l’utilisateur s’il veut sauvegarder ses changements éventuels.

A ce moment là, c’est le délégué qui prend la responsabilité de savoir si et quand la fenêtre doit être fermée, ce qui serait évidemment impossible via le système de notification.

On voit donc ici bien la différence de logique entre la délégation et la notification, le premier pouvant agir sur l’objet concerné, au contraire du second.

Certains objets du framework Cocoa utilisent également leur délégué pour obtenir d’autre types d’informations, comme par exemple l’objet ‘NSBrowser’ (la vue en colonne du Finder) qui utilise son délégué pour connaître les éléments à afficher.

4. Chaîne de délégation

A ce niveau là, on peut remarquer une certaine limitation dans le système de délégation. Un objet ne peut avoir qu’un seul et unique délégué.

Prenons le code suivant:

[ window setDelegate: foo ];

[ window setDelegate: bar ];

Le délégué de l’objet ‘window’ sera donc ‘bar’, qui remplacera ‘foo’ à ce poste. L’objet ‘foo’, quand à lui, ne sera plus du tout en mesure de contrôler les différents aspects de la fenêtre.

Or il pourrait être fort utile, dans certains cas, de pouvoir placer plusieurs délégués sur un même objet. Nous allons donc implémenter un système permettant de chaîner les objet délégués.

5. Implémentation – MultipleDelegateObject

Nous allons tout d’abord créer un classe, qui servira de base aux classes voulant implémenter une chaîne de délégués:

/* MultipleDelegateObject.h */

@interface MultipleDelegateObject: NSObject

@protected

 DelegateChain * delegate;

- ( void )addDelegate: ( id )object;

- ( void )removeDelegate: ( id )object;

- ( NSArray * )delegates;

@end;

Nous n’allons pas gérer la chaîne de délégué dans cette objet, mais plutôt créer une seconde classe, nommée ‘DelegateChain’, que nous étudierons après.

Notre classe contient donc une méthode permettant d’ajouter un délégué, une méthode permettant d’en enlever un, et une méthode permettant d’obtenir sous forme de tableau tous les objets délégués.

L’implémentation est la suivante:

/* MultipleDelegateObject.m */

@implementation

- ( id )init

 if( ( self = [ super init ] ) ) {

 delegate = [ [ DelegateChain alloc ] init ];

 return self;

- ( void )dealloc

 [ delegate release ];

 [ super dealloc ];

- ( void )addDelegate: ( id )object

 [ delegate addDelegate: object ];

- ( void )removeDelegate: ( id )object

 [ delegate removeDelegate: object ];

- ( NSArray * )delegates

 return [ delegate delegates ];

@end

La méthode ‘init’ crée une nouvelle instance de la classe ‘DelegateChain’, et la stocke dans la variable d’instance ‘delegate’. La méthode ‘dealloc’ libère cette resource lors de la destruction de l’objet.

Les trois autres méthodes ne font que re-router les appels sur l’objet de type ‘DelegateChain’, qui gérera elle les délégués multiples.

6. Implémentation – DelegateChain

Regardons maintenant l’interface de la classe ‘DelegateChain’:

/* DelegateChain.h */

@interface DelegateChain: NSObject

@protected

 id * delegates;

 NSUInteger numberOfDelegates;

 NSUInteger sizeOfDelegatesArray;

 NSMutableDictionary * hashs;

- ( void )addDelegate: ( id )object;

- ( void )removeDelegate: ( id )object;

- ( NSArray * )delegates;

@end

Comme précisé auparavant, il ne faut pas effectuer de ‘retain’ sur les objets délégués. Il nous est donc impossible d’utiliser un objet de type ‘NSMutableArray’ ou ‘NSMutableDictionary’ pour stocker les délégués, car ceci aurait pour effet un ‘retain’ automatique lors de l’ajout.

Un tableau de pointeur sur les délégués (le type ‘id’ est en fait un pointeur), alloué et ré-alloué si nécessaire avec les fonctions d’allocation de mémoire de la bibliothèque standard C, fera par contre très bien l’affaire. Il s’agit dans notre cas de la variable d’instance ‘delegates’.

Nous avons également une variable contenant le nombre de délégués actuellement affectés (‘numberOfDelegates’), et une autre (‘sizeOfDelegatesArray’) contenant la taille du tableau de pointeur précédemment cité, et dont nous verrons l’utilité plus tard.

La variable ‘hash’, quand à elle, servira à stocker les adresses mémoire des délégués, afin de trouver facilement leur position dans le tableau de pointeur.

Regardons maintenant, méthode par méthode, l’implémentation de la classe ‘DelegateChain’. En tout premier lieu, son initialisation:

- ( id )init

 if( ( self = [ super init ] ) ) {

 hash = [ [ NSMutableDictionary dictionaryWithCapacity: 10 ] retain ];

 if( NULL = ( delegates = ( id * )calloc( 10, sizeof( id ) ) ) ) {

 // Error management...

 return self;

}

Nous créons le dictionnaire qui nous permettra de stocker les adresses mémoire, et nous réservons une zone dans la mémoire pour stocker les pointeurs vers nos objets délégués. Nous réservons une zone pouvant contenir 10 objets, afin d’éviter d’avoir à appeler les fonctions d’allocation à chaque fois qu’un délégué est ajouté, ce qui nuirait aux performances. En cas de dépassement, nous ré-allouerons cette zone par 10.

Comme nous avons réservé de la mémoire, il ne faut pas oublier de la libérer lors de la destruction de l’objet:

- ( void )dealloc

 free( delegates );

 [ hashs release ];

 [ super dealloc ];

}

Regardons maintenant la méthode utilisée pour ajouter un délégué:

- ( void )addDelegate: ( id )object

 NSString * hash;

 if( object == nil ) {

 return;

 if( numberOfDelegates == sizeOfDelegatesArray ) {

 if( NULL == ( delegates = ( id * )realloc( delegates, ( sizeOfDelegatesArray + 10 ) * sizeof( id ) ) ) ) {

 // Error management...

 sizeOfDelegatesArray += 10;

 hash = [ [ NSNumber numberWithUnsignedInteger: ( NSUInteger )object ] stringValue ];

 if( [ hashs objectForKey: hash ] != nil ) {

 return;

 delegates[ numberOfDelegates ] = object;

 [ hashs setObject: [ NSNumber numberWithUnsignedInteger: numberOfDelegates ] forKey: hash ];

 numberOfDelegates++;

}

Nous avons précédemment alloué un emplacement pour 10 délégués. A supposer qu’il y en ait 10, et que nous ajoutons un onzième, nous augmentons la zone mémoire de 10, grâce à la fonction ‘realloc’.

Nous prenons ensuite l’adresse mémoire de l’objet, sous forme de chaîne de charactère, et nous contrôlons que l’objet n’a pas déjà ajouté comme délégué. De cette façon, il est impossible d’ajouter plusieurs fois le même objet comme délégué.

Il ne nous reste plus qu’à stocker le pointeur vers notre objet, son adresse mémoire avec sa position dans le tableau de pointeur, et augmenter de 1 la variable contenant le nombre de délégués.

Sur le même principe, voici la fonction permettant d’enlever un délégué.

- ( void )removeDelegate: ( id )object

 NSString * hash;

 NSUInteger index;

 NSUInteger i;

 if( object == nil || numberOfDelegates == 0 ) {

 return;

 hash = [ [ NSNumber numberWithUnsignedInteger: ( NSUInteger )object ] stringValue ];

 if( [ hashs objectForKey: hash ] == nil ) {

 return;

 index = [ [ hashs objectForKey: hash ] unsignedIntegerValue ];

 for( i = index; i < numberOfDelegates - 1; i++ ) {

 delegates[ i ] = delegates[ i + 1 ];

 [ hash removeObjectForKey: hash ];

 numberOfDelegates--;

}

Le fonctionnement de cette méthode repose sur le même principe que la précédente, avec une petite subtilité.

A supposer que l’on aie 5 délégués, et que l’on enlève l’objet se trouvant en position 3 dans notre tableau de pointeur, nous aurons un trou. Pour éviter cela, nous décalons donc également tous les pointeurs se trouvant après celui que nous avons ôté.

Et en dernier lieu, la méthode permettant d’obtenir un tableau contenant tous les objets délégués.

- ( NSArray * )delegates

 NSUInteger i;

 NSMutableArray * delegatesArray;

 if( numberOfDelegates == 0 ) {

 return [ NSArray array ];

 delegatesArray = [ NSMutableArray arrayWithCapacity: numberOfDelegates ];

 for( i = 0; i < numberOfDelegates; i++ ) {

 [ delegatesArray addObject: delegates[ i ] ];

 return [ NSArray arrayWithArray: delegatesArray ];

Il s’agit d’une simple boucle sur notre tableau de pointeur, qui ajoute les objets pointés dans un objet de type ‘NSArray’.

7. Runtime et re-routage des méthodes

Nous avons vu plus haut que, pour déterminer si le délégué possède une certaine méthode, il fallait utiliser la méthode ‘respondsToSelector’ sur l’objet délégué.

if( [ delegate respondsToSelector: @selector( someMethod ) ] ) {}

Pour éviter de changer les habitudes de programmation des dévelopeurs Cocoa, nous allons rendre ceci possible sur notre objet ‘DelegateChain’.

Actuellement. le code ci-dessus n’a aucune chance de fonctionner, vu que notre objet ‘DelegateChain’, qui contient les délégués, ne possède bien sûr pas leurs méthodes à son étage.

Nous pouvons par contre parfaitement surcharger (re-déclarer) dans notre classe la méthode ‘respondToSelector’ (à l’origine, elle est déclarée dans la classe ‘NSObject’), pour lui affecter un comportement autre que celui par défaut.

- ( BOOL )respondsToSelector: ( SEL )selector

 NSUInteger i;

 for( i = 0; i < numberOfDelegates; i++ ) {

 if( [ delegates[ i ] respondsToSelector: selector ] == YES ) {

 return YES;

 return NO;

Nous effectuons donc une boucle sur notre tableau de pointeur, et contrôlons si l’un des délégué possède la méthode demandée. De cette manière, nous pouvons utiliser notre objet ‘DelegateChain’ comme s’il s’agissait d’un délégué normal et unique.

Pour que cela fonctionne, il nous faut également surcharger la méthode ‘methodSignatureForSelector’ (NSObject). Celle-ci permet à l’environnement runtime d’Objective-C d’obtenir les infos nécessaires sur une méthode particulière, comme son type de retour, ses arguments, etc.

- ( NSMethodSignature * )methodSignatureForSelector: ( SEL )selector

 NSUInteger i;

 for( i = 0; i < numberOfDelegates; i++ ) {

 if( [ delegates[ i ] respondsToSelector: selector ] == YES ) {

 return [ [ delegates[ i ] class ] instanceMethodSignatureForSelector: selector ];

 return nil;

}

Désormais, nous pouvons savoir si au moins un délégué possède une méthode spécifique. Mais comment appeler le ou les délégués contenant cette méthode?

Ici aussi, nous allons garder le même système d’appel que pour un délégué unique, à savoir que la méthode désirée sera appelée directement sur notre objet ‘DelegateChain’, qui devra se charger de re-router cet appel vers le ou les délégués concernés.

Pour ce faire, nous allons implémenter la méthode ‘forwardInvocation’ dans notre classe.

Cette dernière est automatiquement appelée par l’environnement runtime d’Objective-C lorsqu’une méthode est appelée sur un objet ne la possédant pas. Ceci afin de donner une dernière chance à l’objet en question de gérer l’erreur.

Le même genre de concept est utilisé dans de nombreux langages de programmation objet. On peut par exemple citer les méthodes virtuelles de C++ ou encore la méthode ‘__call’ en PHP5.

- ( void )forwardInvocation: ( NSInvocation * )invocation

 NSUInteger i;

 for( i = 0; i < numberOfDelegates; i++ ) {

 if( [ delegates[ i ] respondsToSelector: [ invocation selector ] ] == YES ) {

 [ invocation invokeWithTarget: delegates[ i ] ];

}

Le système de délégation multiple est ici complétement opérationnel. Pour en bénéficier dans une classe, il suffit désormais que cette dernière soit une sous-classe de ‘MultipleDelegateObject’. Aucune autre implémentation n’est nécessaire.

8. Conclusion

Un tel système permet de définir des classes ayant un nombre infini de délégués. Par contre, les objets intrinsèques du framework Cocoa, tels ‘NSWindow’, ne pourront pas bénéficier de ce système.

Il est par contre parfaitement envisageable d’implémenter ce système de délégation multiple sur des objets comme ‘NSWindow’.

Le language Objective-C permet en effet la définition de catégories, permettant d’ajouter des méthodes dans n’importe quel objet disponible, que celui-ci soit défini dans notre projet, ou qu’il fasse partie d’un framework du système. Par exemple:

@interface NSObject( MyCategory )

- ( void )sayHello;

@end

@implementation NSObject( MyCategory )

- ( void )sayHello

 NSLog( @"Hello world!" );

@end

Le code ci-dessus ajoute une méthode ‘sayHello’ dans la classe ‘NSObject’, faisant partie du framework Cocoa. Comme ‘NSObject’ est la classe de base pour toutes les classes Objective-C, toutes les classes disponibles possèdent maintenant une méthode ‘sayHello’.

Nous pourrions donc parfaitement ajouter les méthodes ‘addDelegate’, ‘removeDelegate’ et ‘delegates’ à l’objet ‘NSWindow’.

La seule limitation des catégories est qu’il est impossible d’ajouter des variables d’instance à une classe. Par contre, l’objet ‘NSWindow’ possède déjà une variable d’instance prévue pour le délégué. Il faudra simplement ne pas oublier de redéfinir la méthode ‘setDelegate’ de ‘NSWindow’ dans notre catégorie. L’utilisation d’une variable globale statique (donc dont l’accès est limité au fichier qui l’a déclarée) est également une possibilité envisageable pour stocker les chaînes de délégués.

HOWTO : Get the best out of twitter

sandrine — Mon, 15 Jun 2009 21:01:00 +0000

You will find lots of best practices and advices to handle your twitter account. I think the basis you should set up, to start with is the following.

Encourage your visitors to publicize your content
ShareThis is a small plugin to add to your site / blog allowing each of your visitors, who liked the post, to publish it in their favorite social network; like facebook profile, twitter, delicious… The easier you make it for people to share what they like, the more they tend to do this little additional click to share. I use this one but their are other tools including, for those using wordpres, native plugins. I found this one smart and easy to configure. Since we added this plugin (last week), we already got 10 sharings. Make life simpler is key for your visitors comfort.

Automatically publish a link to your content
Twitterfeed is a smart tool which crawls your blog feed for updates and publishes it according to your preferences on your twitter account. Easy to use, it allows you to automatically get visibility for your content on twitter, without having to think about it. You can also add a prefix to your post so that people see it comes from your blog : see following screenshot.
You create content, sharing it is important for your followers.

Show you have a twitter account they can follow
By adding a logo mentioning your twitter account, you will encourage those using it and liking it to add themselves to your followers. You will gain instant followers just by mentioning your presence. Opt in based, twitter allows people to follow those they like. But many of us have various accounts and read many sources and don’t necessary have time to spend to look for if the blog / company has a twitter.
Of course, if you have a linkedin, facebook profile or a corporate website, make a mention of this twitter address too! Make it fast for people to see you have a twitter account.

Follow your conversations, replies, comments
Twitter main interest is to generate conversations. Tracking it is therefore essential. For this item you can use several solutions :

Configure the notifications within your twitter account > This solution can become quite invasive. If you receive many followers and replies, it can happen you end up spammed by notifications, and miss out replies. RT (retweets) are not sent via this notification system which may also make you forget some important RT for you.
Use an air application for your desktop tp follow your conversations. My preference goes out to twhirl. This application handles multi account (you can open as many windows as you get accounts, alerts you for replies (sound) and gives you a quick access to RT, DM, @s (retweets, direct messages and replies).
Last but not least, you may use Co-tweet. This applications, still under beta, allows you to track all this conversation flow for you not to forget any. I am just testing it and haven’t found yet how to configure alerts and set a local app, but it is nice and easy to use.

“Make sure you do not miss replies, messages or retweets to take advantage of conversations.”

Add / find interesting people to follow You will find many directories which will be more or less useful and more or less usable. My favourite is the wefollow directory. Simple, based on tages it allows you to add your twitter according to your 3 best tags and also find similar twitter. Very useful for instance to follow tweets in the tech, social media or in regions. The other one I tries is twellow. More or less working like the yellow pages it allows you to find twitter accounts you might be interested in.

Analyze / follow your stats Here I found two useful tools :

Twitterholic crawls your site to provide you with daily / main changes stats and follow your progression trend. It provides with an historic view of how / when your account gained followers and friends.
Tweeteffect is probably the best tip of this list. It will not draw any attention nor publicize anything for you, but will help you understanding how your tweets work. By indicating the number of followers you gained after each of your twitter posts, you will be able to understand what works and what doesn’t work for your users (what they like).. When planning a “marketing” and active content / value driven twitter account, this can be quite important and useful for you to understand what works for you.

There are plenty of tools around you may add to this list but I reckon you should concentrate and take advantage of this quick and not really demanding optimization. I hope you enjoyed this post and feel free to add your favorites to this list too, and of course, follow us on twitter