netinfluence's blog » Développement

Gordon Brown et Tim Berners-Lee: concilier web et développement

Daniel — Fri, 08 Apr 2011 12:58:01 +0000

netinfluence a assisté à la conférence exceptionnelle de Tim Berners-Lee, inventeur du World Wide Web, et Gordon Brown, ancien premier ministre britannique, qui s’est tenue à l’université de Genève le 6 avril.

Sous un format de discussion ouverte, modéré par Alberto Ibargüen, directeur de la Fondation Knight, les deux hommes ont abordés des thèmes liés aux possibilités offertes par le web “ouvert” pour favoriser le développement et la démocratisation.

Que retenons nous de cette conférence?

Dans certaines régions du monde, notamment les pays en voie de développement, la majorité de la population n’a pas encore accès au web.

Ce n’est pas tellement le manque d’infrastructures et de connexions à Internet qui est en cause (en effet le taux de pénétration des technologies mobiles se situe aux alentrous de 40% en Afrique), mais le manque de représentativité des langues locales sur la toile et l’illettrisme qui touche plus d’un milliard d’adultes dans le monde.

Le net ne peut-il quand même aider les populations défavorisées? Pour Gordon Brown, Internet reste l’un des meilleurs moyen de développement: il amène du savoir, il ouvre des opportunités incroyables et de ce fait dynamise l’économie d’un pays et crée des emplois.

Pour illustrer son point de vue, l’ancien premier ministre britannique, a donné l’exemple d’un village dont les habitants, producteurs de tomates, avaient du mal à fixer le prix des denrées, maîtriser la distribution et les marges. Grâce à l’arrivée d’Internet à la bibliothèque du village, ils ont pu accéder à des informations cruciales et résoudre leurs problèmes.

Similairement, une personne de l’auditoire a donné l’exemple étonnant d’un village indien, ou une borne Internet a été placée. Au bout de 6 mois, les enfants du village savaient maîtriser l’ordinateur et lire les textes en anglais.

Tim Berners-Lee y voit l’importance de faire confiance aux gens en leur offrant une connexion à Internet. Son adoption est probablement plus facile que prévu et le problème de la langue, même si important, n’est pas un problème insurmontable: il faut faire d’Internet un média multi-langues et ne pas se limiter à l’anglais.

Les deux membres de la World Wide Web Foundation, un organisme qui lutte pour maintenir la liberté d’accès au Web, ont donc clairement argumenté dans ce sens. Mais ils n’ont pas forcément partagé une vision ou des propositions concrètes sur les réflexions des gouvernements, organisations internationales ou même entreprises.

Rien n’a été dit non plus sur les bouleversements en profondeur du web, sur sa commercialisation ou sa transformation en «prison dorée».

Retrouvez la vidéo de la conférence ici.

Lancement d’alcooquizz

sandrine — Thu, 15 Jul 2010 07:11:24 +0000

Homepage d'alcooquizz

Nous avons été mandaté par le CHUV et son département d’alcoologie pour réaliser un site de prévention et d’information sur les risques liés à l’alcool nommé alcooquizz.ch. Le site fonctionne comme un questionnaire qui permet à chaque personne d’évaluer sa situation par rapport à l’alcool. Le diagnostique, à la fois personnalisé et anonyme, fournit des informations précises ainsi que des recommandations adaptées précisément à la situation de chacun.

Annoncé aujourd’hui par une conférence de presse, le site va faire l’objet d’une plus vaste campagne de communication, relayée notamment durant les divers festivals de l’été afin de sensibiliser sans stigmatiser ni culpabiliser.

La particularité de ce projet a été pour nous de bâtir tout un concept qui permette une certaine neutralité. Il fallait pouvoir parler d’alcool sans culpabiliser, être agréable avec un style un peu ludique mais pas trop non plus et sensibiliser et informer sans non plus provoquer de malaise. Bref, créer une prise de conscience et permettre peut être de nouveaux réflexes par rapport à l’alcool car on se rend compte que beaucoup d’idées reçues existent sur le sujet mais que finalement les gens savent très peu.

Alcoopedia - Base de connaissance du site

La base de connaissance, alcoopedia, s’enrichira au fur et à mesure des interactions et des questions avec le site. Bâtie avec un nuage de tags, elle permet de remonter les articles les plus demandés ainsi que les mots les plus recherchés.

Nous avons conçu le branding (alcooquizz et alcoopedia) ainsi que toute l’identité visuelle du logo et du site. Nous avons également développé le site web (en flex & typo3) qui sera prochainement décliné sous forme d’une application iPhone. Le CHUV et son équipe ont quant à eux fait un énorme travail de préparation et de rédaction pour que le site s’inscrive aussi dans la lignée des travaux de l’OMS et serve à terme, de base statistique sur les comportements liés à l’alcool.

Nous sommes ravis d’avoir contribué à ce beau projet et préparons actuellement la suite.

C’est une manière inédite de communiquer sur un sujet aussi sensible et nous sommes curieux de voir comment le projet sera reçu par les citoyens et les médias.

Update :

Les premières retombées sont plutôt positives avec pour la première journée d’introduction du site avec 6’700 visiteurs et déjà quelques articles.

http://www.20min.ch/ro/news/vaud/story/Evaluez-votre-consommation-d-alcool-19430396

http://www.tdg.ch/evaluez-consommation-alcool-site-web-2010-07-15

http://www.lematin.ch/actu/suisse/evaluez-consommation-alcool-site-web-299738

http://www.24heures.ch/evaluez-consommation-alcool-site-web-2010-07-15

http://www.tsr.ch/info/suisse/2275848-un-site-web-pour-evaluer-son-rapport-a-l-alcool.html

Ar-PHP : boite à outils pour gérer les spécificités de la langue arabe

netinfluence — Mon, 12 Jul 2010 08:52:01 +0000

Ar-PHP est une librairie PHP qui apporte un certain nombre d’outils pratiques pour les utilisateurs arabophones. De part sa spécificité, la langue arabe n’est pas toujours très bien gérée dans les logiciels actuels. Lorsqu’on désire mettre en place un site web en arabe, et plus particulièrement destiné au monde arabe, il est nécessaire de disposer d’un certains nombres d’outils afin de rendre le site le plus agréable possible pour les utilisateurs. Voici une liste non exhaustive des principales fonctionnalités offertes par Ar-PHP :

Conversion de dates entre le calendrier grégorien et hégirien ;
Conversion de dates hégiriennes en timestamp Unix ;
Translitération de mots anglais en arabe et vice versa ;
Détection et application d’un character set ;
Détection de texte en arabe dans un document multilingue ;
Calcul des horaires de prière en fonction des coordonnées GPS ;
Clavier arabe virtuel en javascript ;
Normalisation du texte arabe.

Certaines des fonctionnalités offertes par cette librairie s’avèrent rapidement indispensables si on souhaite gérer au mieux les spécificités de la langue arabe.

Ce projet est développé par Khaled Al-Sham’aa en opensource. L’installation se fait soit par PEAR, soit en téléchargeant directement le code source. Pour découvrir plus en détail cette librairie, rendez-vous sur le site web du projet : http://www.ar-php.org

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

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.

Le marché des applications iPhone en Suisse c’est de la dynamique!

sandrine — Thu, 18 Feb 2010 20:01:27 +0000

Plus une marque ne peut se passer de son application mobile. Résultat des courses, la demande pour la création d’applications iPhone a explosé en 2009. C’est d’ailleurs pour en parler que Bilan a réuni les développeurs romands pour un article intitulé : les suisses les rois des applications.

Principalement composé de développeurs indépendants, le marché suisse n’est pas en reste dans la production d’applications iPhone. Ayant organisé la premières iPhone conférence en 2008, Bilan nous a interrogé sur ce qui avait évolué en 2009.

De notre point de vue les demandes ont évolué en nombre mais surtout en qualité.
Plus habitués et mieux informés, les demandeurs ont compris le besoin de faire une application “qui sert” ou “attire l’attention” sous peine de tomber dans l’abime d’itunes. Donc fini les briefs un peu folkloriques et les “me too”.
Les demandes sont également beaucoup plus raisonnables en terme de budget. On ne développe pas une application iPhone en deux jours! Les coûts sont ceux d’un site web, voire largement plus dès que l’on rentre dans des applications complexes comme le jeu.
Enfin, la maturité du marché a soulevé un véritable enthousiasme créatif. Les demandes que nous recevons ces derniers temps sont vraiment plus réfléchies et créatives. On ressent une vrai réflexion stratégique donnant une vrai place aux applications mobile dans la stratégie de présence online des entreprises.

Il reste encore beaucoup à découvrir et je me réjoui notamment de développer notre première application iPad

Si vous souhaitez en savoir plus ou rejoindre ce microcosme, je vous encourage à aller voir les initiatives suivantes.
De nombreux groupes se sont créés comme “iphone group for developers & decision makers” ou “les développeurs de Suisse romande” sans oublier les “mobile mondays“.

TYPO3 et Campaign Monitor

macmade — Mon, 04 Jan 2010 15:01:23 +0000

Pour les utilisateurs du CMS TYPO3 et du service Campaign Monitor, netinfluence vient de publier une extension TYPO3 permettant l’enregistrement d’une adresse email dans une liste gérée par Campaign Monitor depuis le frontend TYPO3.

Cette extension peut-être téléchargée depuis le site officiel de TYPO3.

La documentation est également disponible directement en ligne.

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;
}

Comprendre les nombres à virgule flottante

macmade — Thu, 24 Sep 2009 08:55:00 +0000

Représentation binaire des nombres à virgule flottante à précision simple

Les nombres à virgule flottante à précision simple sont le plus souvent appelés ‘float’ ou ‘real’. Ils sont longs de 4 bytes, et sont formés de la manière suivante, de gauche à droite:

Signe: 1 bit
Exposant: 8 bits
Mantisse: 23 bits

Signe 1 bit	Exposant 8 bits	Mantisse 23 bits
X	XXXX XXXX	XXX XXXX XXXX XXXX XXXX XXXXX

Le signe indique si le nombre est positif ou négatif (zéro pour les nombres positifs et un pour les négatifs).

L’exposant réel est calculé en soustrayant 127 à la valeur du champ exposant. Il s’agit de l’exposant du nombre, tel qu’exprimé en notation scientifique.

La mantisse complète, parfois aussi appelée significande, doit être considérée comme une valeur sur 24 bits. En effet, comme nous utilisons la notation scientifique, il y a un premier bit implicite (appelé parfois le bit caché) dont la valeur est fixée à 1, étant donné qu’il n’y a jamais de 0 en tout premier, en notation scientifique.
Par exemple, on ne dira jamais 0.123 · 105 mais bien 1.23 · 104.

La conversion est effectuée de la manière suivante:

-1S · 1.M · 2( E - 127 )

Où S est le signe, M la mantisse, et E l’exposant.

2. Exemple

Prenons par exemple 0100 0000 1011 1000 0000 0000 0000 0000, ou 0x40B80000 en notation hexadécimale.

Hexadécimal	4	0	B	8	0	0	0	0
Binaire	0100	0000	1011	1000	0000	0000	0000	0000

Signe	Exposant	Mantisse
0	1000 0001	(1) 011 1000 0000 0000 0000 0000

Le signe est 0, le nombre est donc positif.
Le champ exposant est 1000 0001, autrement dit 129 en décimal. La valeur réelle de l’exposant est donc 129 – 127, ce qui nous donne 2.
La mantisse, avec le premier bit implicite, est 1011 1000 0000 0000 0000 0000.

La représentation finale du nombre en notation scientifique binaire est donc:

-10 · 1.0111 · 22

Mathématiquement, cela veut dire:

1 · ( 1 · 20 + 0 · 2-1 + 1 · 2-2 + 1 · 2-3 + 1 · 2-4 ) · 22
( 20 + 2-2 + 2-3 + 2-4 ) · 22
22 + 20 + 2-1 + 2-2
4 + 1 + 0.5 + 0.25

La valeur du nombre à virgule flottante est donc 5.75.

3. Nombres spéciaux

En fonction de la valeur du champ exposant, certain nombres peuvent avoir une valeur spéciale. Ils peuvent être:

Des nombres dénormalisés
Zéro
Infini
NaN (not a number, pas un nombre)

3.1. Nombres dénormalisés

Si la valeur du champ exposant est 0, et que la valeur de la mantisse est plus grande que 0, le nombre doit alors être traité comme un nombre dénormalisé.
Dans un tel cas, l’exposant n’est pas -127, mais -126. Le premier bit implicite, quand à lui, n’est pas 1 mais 0.
Cela permet la représentation de nombres plus petits.

La notation scientifique d’un nombre dénormalisé est:

-1S · 0.M · 2-126

3.2. Zéro

Si le champ exposant et la mantisse ont tous deux pour valeur 0, le nombre final est 0. Le bit du signe est autorisé, permettant un zéro positif ou négatif, même si cela n’a pas un grand sens mathématiquement.
Il est à noter que zéro peut être considéré comme un nombre dénormalisé. Dans ce cas, cela veut dire 0 · 2-126, ce que nous donne bien zéro.

3.3. Infini

Si la valeur du champ exposant est 255 (les 8 bits définis à 1) et si la valeur de la mantisse est 0, le nombre correspont à l’infinité, soit posistive ou négative, en fonction du signe.

3.4. NaN

Si la valeur du champ exposant est 255 (les 8 bits définis à 1) et si la valeur de la mantisse n’est pas 0, la valeur ne doit pas être considérée comme un nombre. Dans un tel cas, le signe n’a aucune signification.

3. Portée

La portée est différente pour les nombres normalisés et dénormalisés. La portée pour ces deux cas est indiquée ci-dessous:

3.1 Nombres normalisés

Minimum: ±1.1754944909521E-38 / ±1.00000000000000000000001-126
Maximum: ±3.4028234663853E+38 / ±1.11111111111111111111111128

3.2 Nombres dénormalisés

Minimum: ±1.4012984643248E-45 / ±0.00000000000000000000001-126
Maximum: ±1.1754942106924E-38 / ±0.11111111111111111111111-126

4. Exemple de code C

Voici un exemple de programme C qui converti un nombre binaire en sa représentation en nombre à virgule flottante:

/* System includes */
#include
#include
#include

/* Definition of the boolean data type */
typedef enum { FALSE, TRUE } boolean;

/**
* Converts a integer to its float representation
*
* This function converts a 32 bits integer to a single precision floating point
* number, as specified by the IEEE Standard for Floating-Point Arithmetic
* (IEEE 754). This standard can be found at the folowing address:
* {@link http://ieeexplore.ieee.org/servlet/opac?punumber=4610933}
*
* @param unsigned long The integer to convert to a floating point value
* @return float The floating point number
* @author Jean-David Gadina
*/
float binaryToFloat( unsigned long binary )
{
/* Gets the sign field */
/* Bit 0, left to right */
boolean sign = binary >> 31;

/* Gets the exponent field */
/* Bits 1 to 8, left to right */
unsigned char exp = ( ( binary >> 23 ) & 0xFF );

/* Gets the mantissa field */
/* Bits 9 to 32, left to right */
unsigned long mantissa = ( binary & 0x7FFFFF );

/* Storage for the return value */
float floatValue = 0;

/* Counter */
signed int i = 0;

/* Checks the values of the exponent and the mantissa fields to handle special numbers */
if( exp == 0 && mantissa == 0 ) {

/* Zero - No need for a computation even if it can be considered as a denormalized number */
return 0;

} else if( exp == 255 && mantissa == 0 ) {

/* Infinity */
return 0;

} else if( exp == 255 && mantissa != 0 ) {

/* Not a number */
return 0;

} else if( exp == 0 && mantissa != 0 ) {

/* Denormalized number - Exponent is fixed to -126 */
exp = -126;

} else {

/* Computes the real exponent */
exp = exp - 127;

/* Adds the implicit bit to the mantissa */
mantissa = mantissa | 0x800000;
}

/* Process the 24 bits of the mantissa */
for( i = 0; i > -24; i-- ) {

/* Checks if the current bit is set */
if( mantissa & ( 1 << ( i + 23 ) ) ) {

/* Adds the value for the current bit */
/* This is done by computing two raised to the power of the exponent plus the bit position */
/* (negative if it's after the implicit bit, as we are using scientific notation) */
floatValue += ( float )pow( 2, i + exp );
}
}

/* Returns the final float value */
return ( sign == FALSE ) ? floatValue : -floatValue;
}

/**
* C main() function
*
* @return int The exit status
*/
int main( void )
{
printf( "%f\n", binaryToFloat( 0x40B80000 ) );
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.

Découvrez l’équipe de netinfluence

sandrine — Mon, 17 Aug 2009 08:58:00 +0000

Nous sommes heureux d’accueillir un nouveau membre dans notre équipe. Et à cette occasion, il m’a semblé nécessaire de présenter la totalité des membres qui composent netinfluence. Il est vrai que l’on voit 3 têtes sur le site web – celle de Jean, Marc et moi – mais ce sont juste les responsables des 3 unités : Développement, Design et Marketing. Ces 3 pôles regroupent désormais 7 personnes.

Nous devons notre excellence et notre réputation à chacun d’entre eux et bien que leurs rôle soient différents, ils comptent tous énormément et contribuent, chacun à leur façon à ce que nous sommes aujourd’hui.

Emilien dit “padawan” – Expert iPhone & Zend PHP
Emilien est notre premier collaborateur, il a donc une place spéciale dans notre équipe.
C’est un peu notre”apprenti jedi”. Bien qu’il ait clairement un niveau d’expertise “senior”, il ne sait pas encore que la force est en lui
Il programme comme un poète et met tellement de coeur et de talent dans son code que c’en est beau. PHP master, il a appris Zend en quelques mois seulement, passé ses deux certifications sans sourciller, haut la main. Object oriented, javascript poet, il s’est pris de passion pour l’iPhone dont il maîtrise la programmation.
Depuis ses formations à Paris, son voyage à la WWDC d’Apple et son nouvel écran 24″, il ne jure plus que par Mac.
Rejoindre son réseau ou le contacter :

Julien dit “obiwan” – Expert Zend PHP, Magento & Typo3
Il ne se laissera impressionner par aucune difficulté. Son sang froid et sa maîtrise ainsi que sa curiosité font qu’il absorbe tout, lit tout, test tout et apprend en continue.
Il s’est certifié en ZEND PHP et Zend Framwork en deux coups de cuillère à pot, une simple formalité, ce qui a confirmé ce que nous avions déjà repéré, son excellence.
Structuré, vif, il sait s’atteler a de très gros développements avec une vitesse incroyable. Doté d’un très bon sens du contact il sait également gérer des projets avec talent et organisation. Il est précis, performant et dispose de réels talents d’écoute. PHP master bien entendu, il a également une longue expérience en CMS et en ecommerce ce qui lui a rapidement permis d’accroître son expertise autour de Typo3 et de MAGENTO pour lequel il écrit des extensions et dont il est l’expert chez nous.
Gadgetophile, comme nous tous, il s’essaie maintenant au développement iPhone;-)
Rejoindre son réseau ou le contacter :

Jean-David dit “Macmade” – Expert Typo3, PHP
Macmade est un développeur très reconnu et apprécié par la communauté Typo3. Il est à l’origine de plus de 30 extensions, dont certaines sont la base de nombreux développements de la communauté. Fan d’Apple dont il tire son pseudo, développeur cocoa, il est également expert PHP (se prépare à quelques certifications d’ailleurs dans le domaine) et se lance désormais dans l’iPhone.
Réservé et très humble, il a une conscience exacerbée de l’Open source et du partage. Créateur discret et efficace, il a su au fil du temps se créer un réseau et une réputation incroyable. Ce sont du reste ces valeurs que nous avons en commun – la passion, l’excellence, le partage – qui nous ont permis de nous rapprocher et de lui donner envie de rejoindre notre équipe.
Rejoindre son réseau ou le contacter :

Jean, “Maître Yoda” – Expert Zend PHP & Typo3 > responsable du pôle Développement
Jean est au centre de cette équipe technique. Il lui insufle la direction et la cadence. Soucieux de l’expérience utilisateur, sa priorité a toujours été de rendre les clients satisfaits. Il dispose d’une écoute et d’une capacité de compréhension et d’empathie incroyable.
Il est le pivot des mondes techniques, design et marketing car il a la capacité a comprendre le meilleur de tous ces mondes et à les mettre en relation les uns avec les autres.
Simple et très accessible, il donne de son temps pour développer cette équipe et mener à bien les projets.
Respecté pour son expertise PHP et Typo3, il co-dirige netinfluence avec moi et en est incontestablement le ciment.
Rejoindre son réseau ou le contacter :

Marc “Design Master” – Design Director : responsable du pôle UI et Design
Marc est apparu sur notre route il y a 3 ans. Il nous a impressionné immédiatement, non pas par les questions bizarre qu’il posait (et si vous étiez un animal?) mais par son pragmatisme et ses connaissances du web. Il ne fait pas du design pour du design. Il donne vie à une identité élégante et représentative dans laquelle les clients se reconnaissent si bien qu’ils ont du mal à se souvenir comment c’était avant.
C’est un designer exceptionnel, un créatif incroyable et surtout un homme profond. Il s’intéresse à comprendre. Il est curieux, ouvert, très bizarre aussi, il vous posera des questions destabilisantes et se murera dans un silence créatif (enfin on suppose :D) avant de vous suggérer exactement ce que vous cherchiez, l’idée qu’il vous faut, en toute simplicité.
Son talent créatif ne se fait jamais aux détriments des contraintes techniques. Les solutions imaginées sont agréables, toujours disruptives.
Sa force ? Être capable de voir ce que l’on ne montre pas, d’entendre ce que l’on ne dit pas, et de se projeter loin, très loin.
Rejoindre son réseau ou le contacter :

Marie “Madawan” – Traffic Manager
Comme padawan était déjà pris, Marie est Madawan. C’est un petit surnom qui lui a été donné parce que, comme émilien, elle a beaucoup de potentiel, qu’elle apprend à découvrir chaque jour.
Marie gère les campagnes Adwords ou Facebook, les campagnes d’emailing ainsi que tout ce qui concerne analytics et le référencement. Son rôle consiste à nous aider et à aider nos clients à amener du traffic de qualité vers nos sites internet.
Certifiée Analytics, elle s’est prise de passion pour le SEO / SEM (search engine optimization / search engine marketing) et prépare actuellement d’autres certifications comme celle d’adwords.
Rejoindre son réseau ou la contacter :

Me, myself and I – Marketing Master : CEO et responsable du pôle marketing communication
Se décrire est la chose la plus narcissique et la plus difficile à faire. J’en ferais probablement trop ou pas assez, alors j’espère que vous me pardonnerez.
Fille d’entrepreneur, j’avais juré que l’on ne m’y prendrais jamais. Je n’ai peur ni des efforts, ni des sacrifices, mais je voyais la direction d’entreprise comme un travail de solitaire dont je ne voulais pas. Je me suis toujours impliquée corps et âmes dans mon job à tel point que j’avais presque un sentiment fusionnel avec mes employeurs, mais n’ai pas toujours obtenu un juste retour de reconnaissance. Le déclic pour moi c’est une série de choses difficile dont des managers minables.
Manager des gens ne doit pas signifier écraser des gens. Avoir des clients ne doit pas signifier profiter de ses clients, les essorer.
Je voulais faire du web, du marketing et voyant que personne ne me donnait ma chance, je me suis dit que la chance cela se provoquait. Le marketing est un domaine passionnant et qui plus est en complète révolution, grâce au net. Je sentais qu’une nouvelle génération de marketeurs émergeait, et je voulais en être.
Le web 2.0 a permis de faire jaillir un rapport équitable entre les clients et les corporations, les collaborateurs et les employeurs. C’est un nouvel univers, basé sur la conversation qui s’ouvre à nous. Il est riche de relations humaines. Il nécessite une nouvelle race d’experts cross-expertises. Fini les marketeurs dans leurs tours d’ivoire. Fini les développeurs devant des écrans. Il faut une nouvelle générations d’experts ouverts, passionnés, curieux et surtout humbles dans leur capacité à écouter tout ce qu’ils ne savent pas encore. Car internet évolue tous les jours, donc nous devons aussi nous remettre en question chaque jour. Je me sens parfaitement à l’aise dans mon rôle de marketeur et de connecteur. Au sein de netinfluence j’aide les entreprises à accroître leur influence online et à comprendre les enjeux de cette révolution.
Rejoindre son réseau ou la contacter :

netinfluence est donc une entreprise nouvelle génération qui reflète un peu de chacun d’entre nous. Notre ADN se compose de curiosité, de passion, d’anticonformisme et d’audace. Si ce que nous sommes et ce que nous faisons – Aider les entreprises à améliorer leur influence online – vous intéresse, nous serons ravis de faire votre connaissance et de voir comment nous pouvons vous aider.
Nous publions régulièrement du contenu dans ce blog mais aussi sur le twitter de netinfluence et dans delicious, alors n’hésitez pas à nous suivre aussi ici :