Il y a environ 3 ans, j’ai décidé de démarrer CocoaHeads sur Paris.

L’idée : partager, communiquer et donner aux développeurs fans des technos Apple une occasion de se rencontrer, et de refaire le monde à la sauce Apple. Environ 35 sessions plus tard, on peut dire que le pari est réussi.

Le mode opératoire : des présentations techniques, pour se retrouver ensuite autour d’un verre ou d’un bon repas. On aurait pu croire qu’il aurait fallu offrir à boire et à manger pour avoir du monde à des sessions techniques de 2 heures, mais en fait non, c’est bien dans ce sens que cela fonctionne.

Après les premières sessions, quasi-confidentielles, l’audience a vite grandie, aidé par la popularité de l’iPhone et de la ruée sur l’AppStore.

Mathieu Vaidis m’a rapidement rejoint. C’est lui entre autre qui a créé et gère le site web sur lequel vous lisez ce billet.

Puis nous avons eu la joie de voir d’autres villes accueillir des groupes CocoaHeads (7 aujourd’hui).

J’ai déménagé sur Toulouse cet été. Je ne peux plus donc passer autant de temps qu’avant sur l’organisation de Paris.

Je suis très heureux de pouvoir vous annoncer que Mathieu continue à s’impliquer fortement, rejoint par Nicolas Lauquin et Mathieu Godart. Je suis confiant sur leur capacité à faire perdurer et ré-inventer CocoaHeads, pour que vous ayez toujours autant de plaisir à venir y assister.

CocoaHeads m’a pris beaucoup de temps, mais m’a apporté tout autant. Je suis ravi de m’être lancé dans cette aventure avec vous.

N’oubliez pas que la valeur de cette communauté provient exclusivement de ce que chacun d’entre nous y apporte. N’hésitez pas à proposer votre contribution, même modeste aux organisateurs actuels. Ils vous en seront reconnaissants.

Merci à vous tous qui avez donné du temps pour préparer une présentation.

Merci d’être venus chaque mois, de bonne humeur et avec un esprit ouvert et critique sur les différents points de vus exposés.

J’en profite pour remercier l’IESA Multimedia, l’école qui nous accueille chaque mois dans des locaux de grande qualité. Merci Pierre-Edouard.

A bientôt. En attendant, n’oubliez pas : “Stay Hungry, Stay Foolish”.

Pour ceux qui continuent de coder pour iOS dans la torpeur estivale qui a saisi le pays, une petite astuce, permise par le SDK 4, qui pourrait vous économiser quelques gouttes de sueur.

On adore tous le mot-clé @synthesize qui nous évite déjà d’avoir à tartiner des accesseurs sans intérêt. Malheureusement, pour créer une propriété simple, jusqu’à présent il fallait encore définir séparément le stockage (variable d’instance ou ivar pour les intimes et les Scandinaves) et la propriété elle-même, avec le mot-clé @property :

@interface MaClasse: NSObject {
    NSString *truc;
}
@property(retain) NSString *truc;
@end

@implementation MaClasse
@synthesize truc;
@end

Or, dans la documentation des Declared Properties, on trouve la phrase suivante :

For the modern runtimes (see Runtime Versions and Platforms in Objective-C Runtime Programming Guide), instance variables are synthesized as needed.

Et si on suit la référence indiquée on arrive à :

iPhone applications and 64-bit programs on Mac OS X v10.5 and later use the modern version of the runtime.

Tout est donc OK, on devrait pouvoir profiter de cette fonctionnalité dans les projets iPhone !

Toujours à l’affut de l’économie de lignes de code, quand j’avais lu cette documentation je m’étais précipité sur le projet iPhone le plus proche, avais enlevé une définition d’ivar théoriquement inutile et tenté de compiler le code ainsi allégé :

@interface MaClasse: NSObject {
}
@property(retain) NSString *truc;
@end

@implementation MaClasse
@synthesize truc;
@end

Hélas, quelle déception ! Le compilateur ne semblait pas avoir lu le texte sus-cité et s’entêtait à exiger la définition redondante.
Comme d’habitude Google détenait la clé du mystère : si le code incriminé était rejeté, c’est parce que je compilais pour le simulateur ! Quel rapport me direz-vous ? Eh bien comme vous le savez sans doute, le simulateur iPhone est une application OS X 32 bits… qui ne bénéficie donc pas du fameux modern runtime. Effectivement, le code sans ivar se compilait sans problème dès que je choisissais “Device” comme cible.

Je n’étais bien entendu pas le premier à découvrir ce déplorable état de fait (difficile d’abandonner le simulateur pour économiser quelques lignes par classe !), et la conclusion généralement admise était qu’il perdurerait longtemps, Apple ayant choisi de ne pas rendre le modern runtime accessible aux applications OS X 32 bits, et compiler le simulateur en 64 bits étant exclu pour des raisons évidentes.

C’était sans compter… je ne sais quoi au juste, l’ingéniosité d’un développeur Apple ? Un caprice de Steve ? Toujours est-il que, sans tambour ni trompette (ce n’est même pas mentionné dans les release notes, et le bug radar n’est pas fermé !), le simulateur fourni avec le SDK 4, tout en restant une application 32 bits, utilise le modern runtime – et le compilateur associé est naturellement au courant.

Tout ça (oui, ça fait beaucoup de texte pour parler d’économies de lignes de code !) pour dire que dès aujourd’hui, si vous développez pour iOS (quelle que soit la deployment target, du moment que vous compilez avec le SDK 4), vous pouvez tirer parti de l’instance variable synthesis et omettre ces définitions décidément pas DRY.

Pour finir, à ceux qui n’auront de cesse que la dernière source de duplication stérile de code soit éliminée, et continuent de déplorer qu’il faille encore enfoncer le clou de chaque @property par un @synthesize, sachez qu’il existe un espoir : le compilateur LLVM serait capable d’inférer ces déclarations @synthesize, en l’absence bien sûr d’accesseurs explicites (plus de détails ici). Il semble qu’une petite limitation ternisse encore ce tableau presque idyllique, mais le nirvanā de la propriété en une ligne est plus que jamais à portée de main !

Chaque mois, vous êtes un peu plus nombreux à venir à CocoaHeads. Et chaque mois, vous repartez de CocoaHeads avec des nouvelles idées d’appli plein la tête, aussi heureux et déchainés qu’après une keynote présentant un nouveau iDevice.

Alors, nous nous sommes dit : une telle armée de VRP, on ne peut pas la laisser comme ça, sans outil.

Certains d’entre vous les ont déjà vues lors des précédentes sessions de CocoaHeads ou ont eu la chance d’en recevoir quelques unes lors de la WWDC.

Pour les autres, voici en non-avant première exclusive les fameuses cartes de visite CocoaHeads.

Voici donc votre outil le plus efficace pour aller prêcher la bonne parole et ramener les brebis égarées dans les pâturages du code propre qui compile sans warning. Vous n’avez plus aucune excuse de ne pas parler de CocoaHeads à vos collègues et amis.

Spécifications techniques :

• 54 mm par 90mm
• Revêtement plastique avec traitement spécial pour diminuer les tâches de doigts
• Autonomie de la batterie en hausse de +30% – Maintenant jusqu’à 1 an
• Retina Display
• Calcul automatique de la date de la prochaine session CocoaHeads

N’hésitez pas à emporter quelques cartes lors de la prochaine session CocoaHeads pour les partager autour de vous.

Au fait, j’allais oublier : Oui, je sais, ce code a un warning à la compilation : “NDA” redefined. Mais pour une fois, c’est justifié de laisser un warning !