Categories
Non classé

XCode 3.2.4 et documentation Mac

J’ai mis à jour XCode hier et la documentation pour le Mac (Mac Doc Set), n’apparaissait plus dans la liste des docs disponibles. Seule était présente celle du SDK iPhone 4.1. En fait, il faut aller voir dans la rubrique Documentation des Préférences, où on peut demander le rapatriement de la doc. Pour suivre l’avancement du téléchargement, affichez la fenêtre Activity du menu Window.

Categories
Non classé

Désaturation

L’interface utilisateur du nouvel iTunes 10 fait beaucoup parler d’elle. Parmi les points les plus discutables, est le passage de toutes les icônes au noir et blanc: que ce soit dans la colonne de gauche ou même dans les Préférences. Ce n’est pas seulement d’un goût douteux: c’est une erreur de design. Voici mes arguments.

La couleur est un élément de design. On utilise la couleur pour faire ressortir un bouton par rapport au fond d’une page. Un autre exemple commun est le vert pour indiquer la confirmation et le rouge pour indiquer une suppression; c’est même devenu une convention, qu’il faut suivre !

Le daltonisme est une anomalie relativement répandue, aux alentours de 7% des hommes et 0,4% des femmes (je suis moi-même légèrement daltonien). De fait, un design ne peut pas reposer uniquement sur la couleur. Un exemple qui me vient à l’esprit est celui d’un logiciel de téléchargement que j’utilisais autrefois. Les fichiers en cours de téléchargement étaient listés dans un tableau. Lorsqu’un téléchargement était terminé, la ligne contenant le nom du fichier passait du gris au vert. L’erreur de design commise n’était pas tant d’utiliser la couleur, mais que la couleur fusse la ”seule” distinction. La correction de cette erreur reste simple, il suffit d’ajouter une icône ou un texte. À vrai dire, il existe plusieurs formes de daltonisme et plusieurs degrés, si bien que de nombreux daltoniens peuvent tout de même percevoir une différence.

Par ailleurs, 97% des utilisateurs voient correctement les couleurs: elles leurs apportent de l’information. La couleur permet ainsi de distinguer plus facilement les éléments.

Pour revenir à iTunes, j’étais habitué à ce que l’icône de la liste des musique soit bleue, que celles des listes de lecture soient vertes et que celle des podcasts soit violette. Ces couleurs me permettaient de localiser plus rapidement la rubrique. Le passage au noir et blanc rend la localisation plus lente. C’est en cela qu’il s’agit d’une erreur de design.

Categories
Non classé

Adieu PayPal

Commercialiser un logiciel pour Mac est loin d’être aussi simple que sur iOS. Il faut à la fois un système de génération et de vérification de codes de débridage et également un service de paiement qui prévienne notre site web qu’une transaction a été effectuée et qu’il faut délivrer le code. Jusqu’à maintenant, j’utilisais PayPal comme service de paiement. J’ai profité du lancement de PortraiMatic 2.0 pour changer de service, au profit de Kagi. Je vais attendre un peu avant de vous faire un retour sur Kagi, mais j’ai tenté de faire la liste des nombreux défauts de PayPal qui m’ont conduit à l’abandonner.

Problèmes de paiements !

PayPal fait une différence entre les paiements effectués avec un compte PayPal et ceux effectués par carte bancaire. Dans le second cas, l’utilisateur doit cliquer sur un bouton “Retour au site marchand” pour que PayPal signale au site marchand (ceroce.com) qu’une transaction a été effectuée. Si le client ne clique pas le bouton, le script qui effectue la génération du code et le transmet n’est donc pas exécuté; je reçois seulement une copie de la facture. Pour que le client puisse débrider le logiciel, il faut alors que je génère un code à la main et que j’envoie un courriel au client en m’excusant du retard.

Quand on paye avec un compte PayPal, il n’y a pas de bouton à cliquer, le renvoi est automatique. Quand on demande à PayPal pourquoi cette différence, la réponse est “c’est ainsi”.

Certains utilisateurs américains voient les pages de paiement en français

Plusieurs clients américains se sont plaints de ne pas pouvoir payer parce que les pages s’affichent dans une langue qu’ils ne comprennent pas. Quand j’ai demandé à l’assistance de PayPal comment régler le problème, leur réponse fut “les pages s’affichent dans la langue du pays de l’acheteur”. Selon eux, il n’y a donc pas de problème, mes clients sont des menteurs. Je vous laisse seulement imaginer le nombre de clients potentiels qui n’ont pas acheté mais qui ne s’en sont pas plaint.

Le nombres de transactions par carte est limité

Si vous avez payé plusieurs fois avec une même carte bancaire (ce qui est mon cas, car j’ai dû tester le fonctionnement), PayPal finit par vous obliger à ouvrir un compte PayPal, vous ne pouvez plus payer par carte.

Interface d’administration

Le site est d’une lenteur incroyable

Le site est lent, très lent, quelle que soit l’heure. La moindre page met plusieurs secondes à s’afficher. Par exemple, on peut obtenir un historique des paiements: demander un historique sur toute l’année passée est tellement lent que Safari m’annonce que le délai de la requête est dépassé et abandonne. Je suis obligé de demander un historique sur trois mois pour y parvenir (et croyez moi, le nombre de transactions reste très contenu).

Les options sont incompréhensibles

PayPal est passé d’un outil pour faciliter les paiements sur eBay (ce qu’il fait bien), à un site fourre-tout. Si bien qu’on se perd facilement dans les méandres du site et dont l’aide n’est pas toujours à jour. Voici mon exemple préféré: je dois configurer l’adresse du script à exécuter sur mon site web. Dois-je aller dans la rubrique:

  1. Préférences de réception de paiements
  2. Préférences de Notifications instantanée de paiement
  3. Préférences de réception de paiements sur le site ?

Assistance

L’assistance par courriel

J’ai écrit peut-être quatre fois à l’assistance pour exposer mes divers problèmes. Les réponses étaient toujours vaguement en relation avec mes questions, et n’apportaient jamais plus d’information que l’aide du site. Ceci m’amène à penser que les employés passent le message dans une moulinette qui en extrait les mots-clefs les plus significatifs et propose des réponses toutes faites. Je comprends la démarche: la plupart des questions des clients sont bateaux, et donner une réponse standard a du sens. Mais quand on a une question technique précise, on attend une réponse technique précise, surtout après trois allers-retours de messages.

L’assistance par téléphone

Je n’ai jamais eu d’employé de PayPal au téléphone… j’ai laissé tombé avant. Leur serveur vocal oblige à parler pour naviguer dans les menus. Le problème, c’est qu’il ne comprend pas un mot de ce que je dis. J’ai essayé d’articuler, de parler plus lentement, de troquer mon accent parisien contre un accent marseillais, rien n’y a fait (j’imite mal l’accent québécois). Au bout de trois essais infructueux, le serveur propose d’utiliser le clavier du téléphone. Vous n’êtes pas sorti d’affaire pour autant: il faut se balader dans la hiérarchie des menus et sous-menus dont les intitulés sont aussi parlants que ceux du site, avec à chaque niveau l’obligation de faire échouer la reconnaissance vocale pour pouvoir utiliser le pavé numérique. Et bien sûr, c’est payant.

Le forum des développeurs

PayPal a eu l’heureuse idée de créer un forum de discussion pour les développeurs cherchant à intégrer PayPal à leur site. J’y ai trouvé plein d’autres gens partageant le même désarroi et les mêmes soucis techniques insolubles. On y trouve un pauvre employé de PayPal (certainement sous anti-dépresseurs) qui répond à peu près toujours qu’il va voir avec les ingés des états-unis. Exemple:

Le développeur Bonjour, je vends beaucoup d’articles à des clients japonais et il est important que les pages s’affichent en japonais là-bas, sinon je ne ferai pas de ventes. Pour l’instant ça ne marche pas du tout. Même si le site indique que c’est en béta, je m’attendais à ce que ça marche à peu près…

L’employé de PayPal j’ai demandé à PayPal US et ils m’indiquent que la version finale arrive très bientôt.

Le développeur Mon site n’est pas tout à fait prêt, je peux bien attendre encore quelques semaines.

Deux mois plus tard…

Le développeur Avez-vous des nouvelles ? J’en ai un besoin urgent.

L’employé de PayPal Je vais relancer les ingés aux US.

Une semaine plus tard…

Le développeur Alors qu’est ce que ça donne ?

Cette question restera à jamais sans réponse. Nous ne saurons pas si le développeur a réussi à monter son affaire d’export de disques de Richard Clayderman ou s’il a mis la clef sous la porte.

Travail avec les sociétés

PayPal est conçu pour eBay, et même s’il y a aujourd’hui des professionnels qui travaillent sur eBay, PayPal ne sait pas travailler avec les sociétés, ce qui me donne beaucoup de travail au quotidien.

La TVA n’est pas calculée

PayPal n’est pas fichu de déterminer le montant de la TVA d’un achat. C’est à moi de faire le calcul en fonction du pays de l’acheteur, avec tous les cas particuliers que cela comporte. Il existe bien une option qui permet d’entrer soi-même un taux de TVA selon le pays, mais je n’ai pas osé l’activer, craignant d’avantage de problèmes. Est-ce trop demander, à un service de paiement qui se dit international, qu’il sache appliquer le bon taux de TVA ?

La comptabilité est un véritable casse-tête

PayPal ne produit jamais de facture, si bien qu’il est impossible d’avoir une compta claire. J’ai besoin de connaître le chiffre d’affaire, le total des commissions (pour calculer les charges). La seule solution que j’ai trouvé est d’intégrer mon compte PayPal à ma compta, en important la liste des transactions.

Ils demandent régulièrement des justificatifs de domicile

Ce qui peut se comprendre pour un particulier ne l’est pas pour une société: PayPal dispose du Kbis de ma société (extrait du registre de commerce et des sociétés) et peut même aller le vérifier sur InfoGreffe. Ils continuent pourtant à me demander régulièrement un justificatif de domicile ”personnel” indiquant mes noms et prénoms.

Je suis passé à Kagi

J’en ai terminé avec PayPal. Pour être juste, PayPal a quand même deux avantages sur Kagi: il est bon marché (les commissions sont peu élevées) et bien connu du grand public. Payer plus cher est sans doute le prix de la tranquillité.

Categories
Non classé

L’indépendance de la résolution

Lancez votre traitement de texte habituel, et ouvrez un document vierge au format A4. Maintenant, prenez une feuille au format A4 et superposez-la à la page affichée à l’écran: cela ne vous surprend peut-être plus, mais la feuille est plus grande que sa représentation à l’écran. Ne trouvez-vous pas troublant qu’en 2010, les ordinateurs ne sachent pas afficher les documents en taille réelle à l’écran ?

Une histoire de résolution

Revenons d’abord sur cette histoire de résolution. La résolution est une mesure du nombre de points (en l’occurrence pour un écran, des pixels) alignés sur une longueur d’un pouce (2,54 cm). On utilise souvent l’abréviation anglaise dpi («Dots Per Inch»), même si l’abréviation française ppp («Points Par Pouce») est courante.

Faisons un rapide calcul: l’écran de mon iMac G5 présente des dimensions physiques de 14,4 x 9 pouces (soit 36,58 x 22,86 cm). Il affiche 1440 x 900 pixels. Sa résolution horizontale est donc de 1440 / 14,4 = 100 ppp. Et sa résolution verticale est de 900 / 9 = 100 ppp.
 Le fait que la résolution soit la même horizontalement et verticalement indique que les pixels de l’écran sont carrés (il existe des écrans avec des pixels rectangulaires).

Les logiciels ne dessinent pas à l’échelle

Nous en verrons la raison plus loin, mais sur recommandation d’Apple, les logiciels considèrent que l’écran présente une résolution de 72 ppp. Ce choix de 72 ppp s’explique pour des raisons historiques; cela permet une correspondance exacte entre une mesure en pixels et une mesure en points d’imprimerie (il y a 72 points d’imprimerie par pouce). Il me semble que sous Windows, on considère que la résolution est de 96 ppp, ce qui est plus proche de la réalité actuelle.

En pratique cela signifie que pour représenter une page A4 verticale, le logiciel dessine un rectangle de 21 cm/2,54 x 72 ppp = 595 pixels par 29,7 cm/2,54 x 72 ppp = 841 pixels. Aussi, quand le zoom de la page est réglé à 100 %, le logiciel dessine à 72 ppp. Pour le faire dessiner à 100 ppp, il faut donc mettre le zoom à 100/72 = 139 %. Je peux alors superposer la feuille sur mon écran avec une correspondance parfaite.

Pourquoi ce problème n’est-il toujours pas résolu en 2010 ?

Apple propose des API pour connaître la définition (en pixels) de l’écran. On peut sans doute également demander au système d’exploitation les dimensions physiques de l’écran et calculer sa résolution comme ci-dessus, et enfin dessiner à l’échelle. Cependant, un problème va apparaître dès lors que vous brancherez un deuxième écran sur votre Mac qui présente une résolution différente du premier: une fenêtre à cheval sur les deux écrans n’aura son contenu à l’échelle que sur l’un des écrans. En y réfléchissant, la seule manière simple de résoudre le problème est que ce soit le Window Server qui fassent l’adaptation.

Les réflexions d’Apple sur le sujet

L’indépendance de la résolution était annoncée pour Mac OS 10.5 et ne fut finalement pas présente. Il existe pourtant déjà quelques API: Resolution Independence Guidelines.

Je vous fait un petit résumé:

  • Les ingés d’Apple ont l’air de s’embrouiller avec tout ça.
  • Il faudra dessiner à 72 ppp. Quartz effectuera ensuite les conversions pour avoir les coordonnées en pixels.
  • Il est pour l’instant possible de changer le facteur d’agrandissement à l’aide de l’application Quartz Debug, dans le menu Tools > Show User Interface Resolution. Essayez, c’est marrant. Ce petit essai devrait vous faire comprendre la complexité de la chose: c’est moche, on voit plein de gros pixels.

Il va donc falloir rendre l’interface utilisateur entièrement vectorielle. C’est un énorme travail, et il est donc compréhensible qu’Apple ne l’ait pas encore complètement implémenté.

Categories
Non classé

Dialogue d’impression

Voilà un bogue marrant que j’ai trouvé en travaillant sur PortraiMatic 2.0:

PrintDialoguePortrait

Une image appelée Portrait.png se trouve dans les ressources de l’application: on constate qu’elle a remplacé l’image qui désigne l’orientation ”portrait” dans la boîte de dialogue ”Format d’impression”. Au moins, résoudre le problème est simple, il suffit de renommer le fichier.

Note pour plus tard: essayer d’utiliser une image Landscape.png.

Categories
Non classé

La télé 3D et l’impression de relief

Dans le cadre de son excellent podcast consacré à la photographie, Benoît Marchal a interviewé Michel-Patrick Lauret, spécialiste de la stéréophotographie. Je ne vais pas revenir sur le principe, vous conseillant plutôt l’écoute de l’émission.Ce qui m’a particulièrement intéressé est le point de vue du photographe sur la télévision 3D.

Comme il l’explique fort justement, la distinction des reliefs étant donnée par l’écart des yeux, elle ne fonctionne bien que lorsque le sujet observé est proche. D’où l’utilisation de focales standard pour révéler la profondeur. Dans son exemple d’un mannequin marchant sur un podium, alors que les autres photographes utiliseront des télé-objectifs pour photographier le mannequin de loin, lui attendra qu’il arrive au bout du podium pour être le plus près possible et donner la meilleure sensation de relief.

Or, les conventions du cinéma sont plutôt d’utiliser des plans serrés, qui nécessitent l’utilisation de longue focales. Pareil pour filmer un match de foot: les caméramen se trouvent sur le bord du terrain et utilisent de longs télé-objectifs. L’impression de relief est donc minimale.

Tout le propos est que pour généraliser la stéréovision, il faudra aussi repenser la manière de filmer.

Categories
Non classé

BeMyApp juin 2010

Voilà une semaine qu’avait commencé la première rencontre ByMyApp, et je n’ai pas encore pris le temps de vous raconter son déroulement et vous donner mes impressions. Commençons par rappeler les principes: les organisateurs avaient réuni des développeurs logiciel, des concepteurs web et des graphistes pour qu’une trentaine de personnes viennent leur exposer leurs idées d’applications pour iPhone ou iPad. À l’issue du week-end, un jury récompensait l’équipe gagnante par un prix de 5000 €.

John Karp et Cyril Attia nous donnaient rendez-vous au Dune, un bar situé aux alentours de l’hôpital Saint Louis. J’arrivai en ce vendredi soir, chargé de quinze kilos de bagages entre mes vêtements, mon MacBook et les quelques livres que j’avais emporté: l’un portant sur le développement iPhone, un autre sur la gestion de version avec Git, et le dernier pavé sur OpenGL (on ne sait jamais). Ayant marché depuis la gare du Nord, j’étais en sueur ! John emportait mes bagages dans le fond du Dune et m’invita à coller sur la poitrine une étiquette à mon nom, qu’il avait dotée d’une pastille verte indiquant mon rôle de développeur logiciel.

Je profitai de l’heure qui restait avant la présentation des projets pour lier connaissance avec les gens présents. D’emblée, l’ambiance me parut très sympathique. Si certains étaient réservés, tout le monde était de bonne humeur et impatient d’exposer ses idées ou de commencer à travailler. Lorsqu’arrivèrent les vingt heures, chaque porteur de projet disposa d’une minute pour exposer son idée. J’essayai de rester attentif, tâtant dans ma poche les trois jetons que je placerai sur mes projets favoris. Parmi la trentaine de projets présentés, la moitié était des projets qui auraient plus intérêt à naître sous la forme d’un site web que d’une appli iPhone; je vais y revenir. Parmi les projets restants, certains me parurent peu novateurs.

À la suite de ces présentations, les porteurs disposaient de trois-quart d’heure pour venir «draguer» ceux qui allaient réaliser les applications. J’étais là, posté comme une jolie fille, à attendre que chaque prétendant me fasse la cour en me soufflant à l’oreille ses arguments les plus persuasifs (voilà un renversement de situation bien agréable, d’autant plus lorsque ce furent de jolies demoiselles qui vinrent m’accoster). Voici une leçon à retenir pour les porteurs de projets des prochaines éditions: venez à deux. Certains n’ont pas eu le temps de venir me causer, alors que par moment, personne ne me faisait la conversation. Si vous êtes seuls, faites court lorsque vous comprenez que vous n’avez pas convaincu; il est inutile d’insister, il vaut mieux apporter vos arguments à quelqu’un d’autre.

Une minute pour présenter un projet peut sembler court, mais c’est suffisant. Très honnêtement, j’avais déjà choisi mes trois projets à l’issue des présentations, et les arguments apportés par la suite ne m’ont pas fait changer d’avis… Mais notez bien que j’aurais éventuellement pu pour le dernier projet de mon tiercé. Si je peux encore donner un conseil, c’est d’éviter d’être trop technique dans votre présentation. Essayez plutôt de raconter une histoire pour que votre auditoire puisse se projeter. Soyez concrets, même si vous n’êtes pas sûr que la solution technique à laquelle vous pensez est réalisable: ceci est du ressort des développeurs, qui s’attendent à ce que vos propos soient naïfs.

Après que les votes furent dépouillés, le verdict tomba: sept projets étaient retenus. Parmi mes poulains, un seul était retenu, aussi je me dépêchai de me rapprocher de Brigitte, la porteuse, pour travailler sur son projet, qui consiste en une application d’apprentissage des caractères Hiragana (l’un des trois alphabets du Japonais). Je finis par convaincre un autre développeur, Mathieu, de se joindre à nous. Nous nous étions déjà rencontré lors d’une réunion CocoaHeads, mais il fut hésitant, à raison: le projet exigeait la mise au point d’algorithmes complexes, un risque important étant donné le peu de temps pour la réalisation. Finalement, nous somme rejoints par un graphiste, Roger.

Je ne vous raconterai pas ici le déroulement du développement, qui n’est guère intéressant: Mathieu et moi travaillions dans notre coin sur l’algorithme et l’interface utilisateur et Brigitte s’occupai d’envoyer nos demandes à Roger et de rendre son concept un peu plus ludique, en travaillant ses listes de vocabulaire.

Dimanche, l’heure du verdict approchait, et l’algorithme n’était toujours pas au point. Je su pertinemment que nous n’arriverions pas à le faire fonctionner, aussi je décidai d’aller voir Brigitte et de nous préparer à la présentation du prototype final. Aussi parce que je regrettai de ne pas avoir travaillé davantage en groupe, et que je voulais donc profiter des derniers instants. À ce moment, beaucoup avaient déjà une idée des vainqueurs, parce que leur projet était déjà bien avancé la veille; le doute portait sur l’avancement des autres projets.

Et il n’y eu pas de surprise: le projet choisi fut iDact, une appli sur iPad qui affiche des plans sonorisés pour guider des mal-voyants dans les lieux publics tels que gares, aéroport, musées et dont le porteur de projet avait les plans. Ce verdict est juste: l’application était sans doute l’une des plus facile à réaliser, mais la réalisation était impeccable. Aucun concurrent n’a présenté un logiciel aussi proche d’un projet fini. Bravo aux gagnants !

Et merci aux organisateurs Cyril et John. J’essayerai d’être présent à la BeMyApp du 15 octobre.

Categories
Non classé

Conception itérative d’une IHM

Lors de la session de CocoaHeads de jeudi soir, nous avons eu droit à une présentation de Jonathan Perret, qui en bon adepte de la méthodologie XP, crée ses applications de façon itérative. C’est à dire, qu’il fait en sorte qu’elle reste fonctionnelle tout le temps, mais ajoute les nouvelles fonctionnalités, et améliore l’existant au fur et à mesure.

L’un des auditeurs, lui alors demandé s’il faisait de même pour l’IHM (Interface Homme-Machine), ce à quoi Jonathan a répondu par l’affirmative, ce qui ne manqua pas d’étonner l’auditeur qui fit remarquer, à raison, que de nombreuses sociétés ne travaillent pas ainsi. Beaucoup conçoivent les IHM à l’avance sur papier, ou sous Photoshop, et en discutent en comité, avant de demander aux programmeurs d’implémenter le produit de leurs réflexions.

Preuve en est l’existence de nombreux outils pour créer des maquettes graphiques, ou les différents articles d’équipes expliquant comment elles ont conçu leur IHM sur papier avec des gabarits d’écran. Ces maquettes sont bien jolies, mais ce ne sont que des maquettes; non-seulement, les réaliser prend du temps, mais souvent la mise en œuvre réelle révèle que les concepts qui paraissaient si séduisants dans l’imaginaire fonctionnent mal en réalité.

Leur démarche me semble être le produit de dérives visant à occuper les graphistes et créer des plans et autres réunion; bref, des occupations habituelles des grosses boites. Pour ma part, j’utilise donc une approche itérative qui, à mon sens, se justifie par le fait qu’il est relativement peu coûteux (en termes de temps et de ressources) de se tromper. Quel que soit le programme que l’on conçoit, on commet des erreurs de conceptions: ces erreurs font partie intégrante du travail de design. Souvent, il est nécessaire de se tromper pour comprendre quelle est la bonne solution.

Categories
Non classé

Interfaces gestuelles et découvrabilité

Un article intéressant sur Ignore the code. Les interfaces gestuelles posent, entre autres, des questions quant à la ”découvrabilité” des actions possibles. Par exemple, secouer l’iPad pour annuler la dernière commande n’est pas évident, il faut le savoir, car il est peu probable de le découvrir par accident.

Les adaptations d’iWork à l’iPad font également usage de nouveaux gestes pour contraindre les dimensions des objets: de fait, ceux-ci sont documentés dans le logiciel. Ces actions sont moins naturelles que faire défiler la page en glissant le doigt, ou agrandir une image en écartant deux doigts.

Comprenons que ces interfaces sont encore immatures, et que beaucoup de concepts sont encore à inventer ou parfaire. Ma réflexion personnelle est que sur nos Mac, nous sommes aussi habitués à certaines conventions: par exemple maintenir la touche ”Majuscule” appuyée pour contraindre les dimensions, ou la touche ”Contrôle” pour dupliquer la sélection. Ces actions-ci non plus ne sont pas évidentes: nous l’avons découvert au détour d’une page de manuel, ou parce que quelqu’un nous l’a expliqué.

Categories
Non classé

Singleton

Le Singleton est sans doute la Design Pattern la plus connue, ne serait-ce parce qu’elle est simple à comprendre. L’idée est que certains objets n’existent qu’à un seul exemplaire dans une application. Considérez par exemple ces méthodes de classes Cocoa:

  • +[NSFileManager defaultManager]
  • +[NSFontPanel sharedFontPanel]
  • +[NSApplication sharedApplication]

Chacune renvoie un objet partagé — une instance unique pour toute l’application. Il faut appeler cette méthode de classe pour accéder à cet objet, et ne pas instancier un objet comme on le fait d’habitude, avec le couple [[alloc] init].

Le Singleton: Version simple

Créer un objet singleton en Objective-C n’est pas compliqué:

Pour le .h:

@interface MonSingleton: NSObject { } 

+ (MonSingleton *) sharedSingleton; 

@end

Pour le .m:

@implementation
static MonSingleton *sharedSingletonInstance = nil; 

- (id) init 
{ 
 if(self = [super init]) 
 {
 // Initialisations classiques 
 } 
 return self; 
} 

+ (MonSingleton *) sharedSingleton
{ 
 if(sharedSingletonInstance == nil) // Pas encore instancié
 sharedSingletonInstance = [[MonSingleton alloc] init]; 

 return sharedSingleton; 
} 

@end

 

Le Singleton: Version Apple

Voici l’implémentation proposée par Apple :

static MyGizmoClass *sharedGizmoManager = nil;

+ (MyGizmoClass*)sharedManager
{ 
 if (sharedGizmoManager == nil)
 {
 sharedGizmoManager = [[super allocWithZone:NULL] init]; 
 }
 return sharedGizmoManager;
} 

+ (id)allocWithZone:(NSZone *)zone
{
 return [[self sharedManager] retain];
}

- (id)copyWithZone:(NSZone *)zone
{
 return self;
}

- (id)retain {
 return self;
}

- (NSUInteger)retainCount
{
 return NSUIntegerMax; //denotes an object that cannot be released
}

- (void)release
{
 //do nothing
}

- (id)autorelease
{
 return self;
}

La différence est que les méthodes en rapport avec la création, la copie et la destructions des instances sont supplantées pour vous empêcher de créer une instance supplémentaire , ou de détruire l’instance partagée. Il s’agit d’une approche plus paranoïaque que celle que je vous proposais plus haut. Je dirais qu’elle convient mieux si vous travaillez en équipe ou que vous rendez publique votre bibliothèque de classes. La première version possède l’avantage de la simplicité, et convient pour un petit projet, par exemple sur iPhone.