netinfluence's blog » iPhone

Lomography vs. Faux-Lomography

darja — Thu, 29 Sep 2011 10:00:51 +0000

Lomography‘s roots go back into late 90s when two Austrian students discover a small russian camera called Lomo LC-A . The camera was cheap, conveniently small, had a great wide angle lens and could take stunning pics in low-light conditions. So there was no hesitation. The fellas took it for a ride and their only guideline was “Don’t Think, Just Shoot”.
Today, Lomography stands for an experimental analog film photography and lives through a large international community.

Lomography is not a clever idea thought up by a marketing strategist, inventor or artist. Lomography emerged as a consequence of an accidental meeting concerning the technical, economic, social and artistic conditions. And as such had to be developed.
…

The art of “junk”, the desire to publish, the joy in consumption and in alleged mass numbers (no motif is unworthy of being lomographed), the destruction of traditional practices (seriousness of art, privacy, classical aesthetics of photography etc) are the salt of Lomography, supermarkets are the butter and the LOMO LC-A is the bread.

- a quote from Lomographic Manifesto

Lomo pics can be round, squarish, panoramic, captured in a sequence or in 360°, cross processed, tilt-shifted, bleached by accident, polarized … And as long as you keep in mind these 10 Golden Rules:

Take your camera everywhere you go.
Use it any time – day and night.
Lomography is not an interference in your life, but part of it.
Try the shot from the hip.
Approach the objects of your Lomographic desire as close as possible.
Don’t think (William Firebrace).
Be fast.
You don’t have to know beforehand what you captured on film.
Afterwards either.
Don’t worry about any rules.

… you are a Lomographer.

The only inconvenience with lomography is a bunch of different cameras, films, filters you have to carry around.
And if you want to avoid it – yes, there are Apps for that.

Here is how you can fake your stylish Lomo pics:

get your smartphone
install of one of the photo apps as Hipstamatic, Instagram, Lomo Pro…
and shoot, shoot, shoot.

Recommended faux-Lomo apps:

Now it’s up to you if you wanna fake it or keep it true.
Nevertheless… your drive should rather be “don’t think, just shoot”.

Image used under Creative Commons from Laura Thorne

Color: l’application sociale mobile de partage de photos

Daniel — Fri, 25 Mar 2011 16:40:14 +0000

Avez-vous entendu parler de Color? C’est l’application mobile qui buzz en ce moment sur la toile. L’aspiration de cette application n’est autre que de devenir l’application ultime de découverte localisée. Alors, de quoi s’agit-il?

On pourrait décrire Color comme une application de partage de photos et de vidéos pour un groupe de personnes, de manière publique et géolocalisée. Contrairement à tous les autres réseaux sociaux comme Facebook ou Twitter, Color n’a pas la même notion d’amitié. Le partage de photos se fait selon vos habitudes de partage et selon la place où vous vous trouvez. Les vidéos et photos sont publiques, non seulement pour les personnes que vous considérez comme vos amis, mais aussi pour celles, inconnues, qui se trouvent à moins de 35 mètres.

Avec Color, vous ne choisissez pas votre réseau d’amis, c’est l’application elle même qui s’en charge. Comment? Tout simplement en définissant les personnes avec qui vous passez le plus de temps. A chaque fois que vous vous trouvez près de l’un de vos amis qui utilise Color, l’application le détecte et classe ainsi vos amitiés. Cependant, si vous ne voyez plus cette personnes pendant quelques temps, elle sera automatiquement déclassée dans vos amitiés Color. Vous pourrez bien entendu gérer ces amitiés, en demandant par exemple d’en voir plus et plus souvent sur une amitié ou encore de commenter et liker des photos.

Le coté sympathique de l’application réside surtout dans le fait de pouvoir voir les photos qui sont prises sur le moment autour de vous, ainsi que celles de vos “amis” où qu’ils soient. Encore plus cool, vous pourrez voir les photos de vos amis, même quelques année plus tard à condition d’être à l’endroit précis ou ses photos ont été prises.

Disponible sur iPhone sur Androide, cette application n’est pas vraiment faite pour les adeptes de la vie privée. Mais qu’on l’aime ou pas, Color a déjà réussi à avoir plus de 41 millions $ de financement. Affaire à suivre!

Color Demo from Color Labs, Inc. on Vimeo.

De la typographie sur l’iPhone

mgdh — Sun, 15 Aug 2010 18:26:21 +0000

En tant que designer visuel, je suis passionné de typographie. Et comme beaucoup de mes semblables, j’ai aussi craqué pour un iPhone… Résultat: je suis parti à la recherche d’applications traitant de près ou de loin du sujet de la typo!

Voici ci-après 7 iPhone apps que je vous recommande d’essayer:

The typography manual

Petit manuel bien ficelé et toujours sous la main sur le sujet: histoire de la typo, les bases, le typesetting, la typo et le web, anatomie des polices, … Vous trouverez également sous l’onglet “Ressources” quelques outils bien pratique: un calculateur de “em”, un tableau des différentes tailles de papier, des sites web, magazines et “type foundries” de références, … (Voir le site – CHF 4.40)

Font size calculator

Qui ne s’est jamais demandé si le titre ou texte d’un poster sera lisible depuis l’autre côté de la rue? Bien sûre, on peut faire des tests grandeur nature… compulser ses notes de cours ou entrer quelques valeurs dans l’interface et voilà… Pour info, le résultat n’est qu’indicatif et l’oeil du pro tranchera. (Voir le site – Gratuit)

What the font

La version de “What the font” sur l’internet est déjà une référence et a pu à de nombreuses reprises identifier des polices mystérieuses… Mais voilà la version mobile! Les posters dans la rue n’aurons plus de secret! Cette application vous permet d’identifier des polices utilisées sur tout supports (journaux, magazines, affiches, …) Mieux vaut un iPhone 3Gs ou supérieur pour la qualité de la prise de vue. (Voir le site – Gratuit)

Font shuffle

FontShop nous propose avec FontShuffle plus de 650 choix de police: de quoi booster notre inspiration, nous faire découvrir de nouvelles polices, ou redécouvrir de plus anciennes… Secouez votre iPhone et FontShuffle vous présentera une sélection aléatoire! (Voir le site – Gratuit)

KERN

Les expert du “kerning” vont apprécier: qui a l’oeil absolu? Essayez de placer une lettre de 5pt le plus précisément dans un mot en mouvement et dans un temps limité. Dommage que l’on ne puisse pas partager nos meilleures scores avec d’autres participants. (Voir le site – CHF 1.10)

The Font Game

Encore un autre jeu qui mettra votre acuité visuelle et votre expertise en matière de reconnaissance typographique à rude épreuve… Essayez de reconnaître 657 polices différentes et le plus vite possible, puis publiez vos résultats sur le web! (Voir le site – CHF 1.10)

Typography kick ass

Un petit clin d’oeil pour cette dernière application: écrivez et envoyez un message composé uniquement de “lettres photographiques” provenant de la communauté Flickr. Vous voici l’auteur d’un message “anonyme personnalisé”. (Voir le site - CHF 1.10)

En attendant de tester des applications pour l’iPad (père Noël?), partagez avec moi vos découvertes…

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

Stickybits: Interactive experience @ netinfluence

nicolas — Wed, 19 May 2010 20:28:22 +0000

Have you heard about stickybits? We got totally hooked on this new start-up since it launched in March during SXSW.

What is it and how does it work? After downloading the free StickyBits application on your iPhone or Android, you can start scanning a barcode and upload any kind of digital content or view what others have already uploaded on it. You can scan either barcodes on stickers purchased from StickyBits, or those found on any product out there!

To have fun, we sticked StickyBits all over the office. What’s pretty cool about this is that it creates a unique interactive experience for our visitors! There’s a StickyBit on your nameplate in the building’s front entrance so that people who pass-by can discover who we are and what we do, there is one on our office’s door with a nice video welcome message, there is another one on the wall where we showcase our latest realizations with pictures and links, one in the kitchen area with heaps of fun stuff, and another one in our restroom inviting you to..read our blog!
The cool part is that all our visitors can “attach” their own bits to our stickers. Fun stuff, no?

Beyond this, what blows our minds the most, are all the possibilities given by this application. By letting anyone attach a digital message to any physical object, StickyBits is bridging the gap between real life and digital world.

Just imagine what it means for brands. Currently all the content appearing on barcodes is user-generated content. But StickyBits plans to release in June tools for brands, including means to manage the conversations popping up on its products and an analytics dashboard. Brands will be able to track where and when people scan its products, publish official content, or talk to users that have checked in previously.

Geo-localisation apps like Foursquare or Gowalla, can help brands and retailers get the consumers in the store, but StickyBits is actually in the store with the consumer when he is making his final purchasing act! And figures indicate that 30% are using their mobile phones at this exact moment (to call someone for advice, or look for recommendations online for example).

Therefore it’s very important, in our opinion, that brands hurry to take ownership of their product’s barcode.
Why? By doing so they can turn a basic “product” into a “universe” or “user experience”. Imagine being in a shop, scanning your favorite coffee and getting in return info about its origin, composition, or environmental footprint. But we could also imagine getting more practical outputs like video advice from George Clooney for example, recipe ideas, other consumer’opinions, discount coupons, or an advertising message.
There are millions of creative ideas to come up with for brands to give life to their products and deliver a unique experience to consumers. We are looking forward to help you achieving just that!

Here is a 5 minutes video we made to show you a bit more in details how StickyBits works. Any feedback welcomed!

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“.

Mac / iPhone / iPad – Détecter l’inactivité de l’utilisateur avec I/O Kit

macmade — Tue, 09 Feb 2010 16:26:43 +0000

Il peut être parfois utile, dans une application, de savoir si l’utilisateur est en train d’intéragir avec son ordinateur (ou téléphone) ou s’il est parti boire un café.
Cet article explique comment détecter l’inactivité de l’utilisateur. Il s’applique aussi bien au développement pour Mac OS X que pour iPhone / iPad.

I/O Kit

Il n’existe à ma connaissance pas de moyen direct, en Cocoa, pour déterminer l’inactivité.
Par inactivité, il faut comprendre absence d’interaction de l’utilisateur avec la machine. L’interaction peut être le déplacement de la souris, une action sur le clavier, etc, mais non une action déclenchée uniquement par la machine.

Le système dispose bien entendu de cette information. C’est ce qui permet de déclencher un économiseur d’écran, ou de mettre la machine en veille.

Pour accéder à cette information, nous allons devoir utiliser I/O Kit.
Il s’agit d’une collection de frameworks, librairies et outils destinés principalement au développement de drivers pour des composants matériels.

Dans notre cas, nous allons utiliser plus principalement IOKitLib, une librairie permettant aux applications d’accéder aux ressources matérielles par le biais du kernel.

Comme il s’agit d’une librairie de (relativement) bas niveau, nous allons devoir coder en C pour l’utiliser.
Nous allons donc, pour des raison pratiques, et pour permettre une utilisation générique, créer une classe Objective-C encapsulant ce code C parfois un peu moins digeste pour certains développeurs Cocoa et iPhone.

Configuration du projet

Avant de commencer, nous allons configurer notre projet XCode, afin de permettre l’utilisation de IOKitLib.
En effet, puisqu’il s’agit d’une librairie, celle-ci doit être «linkée» à notre application finale.

Il suffit d’ajouter un framework à notre projet:

Pour une application Mac OS X, nous allons choisir “IOKit.framework”.
Pour iPhone et iPad, ce framework n’est pas disponible dans son ensemble. Dans un tel cas, il faudra choisir “libIOKit.dylib”.

Le framework est du coup ajouté à notre projet, et sera «linké» avec notre application après la compilation.

Utilisation d’IOKitLib

Avant toute chose, voici les documents de références d’I/O Kit:

Nous allons tout d’abord créer une classe Objective-C qui nous permettra de connaître l’inactivité:

#include

@interface IdleTime: NSObject
{
mach_port_t ioPort;
io_iterator_t ioIterator;
io_object_t ioObject;
}

@property( readonly ) uint64_t timeIdle;
@property( readonly ) NSUInteger secondsIdle;

@end

Cette classe contient 3 variables d’instances qui nous servirons à communiquer avec I/O Kit.
Les types correspondants à ces variables sont définis dans le fichier “IOKit/IOKitLib.h”, que nous incluons.

Nous définissons également deux propriétés, qui nous servirons à accéder au temps inactif. La première en nanosecondes (ce que nous retournera I/O Kit), et la seconde en secondes (ce qui est souvent un peu plus pratique).

Voici l’implémentation basique de la classe:

#include "IdleTime.h"

@implementation IdleTime

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

}

return self;
}

- ( void )dealloc
{
[ super dealloc ];
}

- ( uint64_t )timeIdle
{
return 0;
}

- ( NSUInteger )secondsIdle
{
uint64_t time;

time = self.timeIdle;

return ( NSUInteger )( time >> 30 );
}

@end

Nous avons une méthode “init”, qui nous servira à établir la communication de base avec I/O Kit, une méthode “dealloc” qui nous permettra de libérer les ressources que nous avons alloués, et une méthode (getter) pour chacune de nos propriétés.

La seconde (secondsIdle) ne fait que prendre le temps en nanosecondes et le convertir en secondes. Pour ce faire, il suffit de diviser le temps par 10 puissance 9. Puisque nous avons des valeurs entières, un décalage de 30 sur la droite reviens exactement au même résultat (en plus rapide bien sûr).

Nous allons maintenant nous concentrer sur la méthode “init”, et établir une communication avec I/O Kit, qui nous permettra d’obtenir des informations sur le matériel.

- ( id )init
{
kern_return_t status;

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

}

return self;
}

Nous déclarons une variable de type “kern_status”, qui nous permettra de connaître le status de la communication avec I/O Kit, afin de gérer d’éventuelles erreurs.
La suite de code se passe à l’intérieur de l’instruction “if”:

status = IOMasterPort( MACH_PORT_NULL, &ioPort );

Ici, nous établissons la connexion avec I/O Kit, sur le port par défaut (MACH_PORT_NULL).

Pour contrôler le résultat de l’opération, nous pouvons comparer la valeur de “status” avec “KERN_SUCCESS”:

if( status != KERN_SUCCESS ) {

/* Error management... */
}

I/O Kit se compose de plusieurs services. Celui qui nous intéresse est “IOHID” (I/O Human Interface Driver). C’est celui qui nous permettra de connaître l’état de l’interaction entre l’utilisateur et la machine.
Nous récupérons dans le code suivant un itérateur sur les services I/O Kit, qui nous servira à accéder à IOHID.

status = IOServiceGetMatchingServices(
ioPort,
IOServiceMatching( "IOHIDSystem" ),
&ioIterator
);

Nous pouvons maintenant stocker notre service IOHID:

ioObject = IOIteratorNext( ioIterator );

if ( ioObject == 0 ) {

/* Error management */
}

IOObjectRetain( ioObject );
IOObjectRetain( ioIterator );

Nos effectuons ici un “retain”, pour s’assurer que nos objets ne seront pas désalloués automatiquement.
Il ne faut donc pas oublier d’effectuer un “release” dans la méthode “dealloc”:

- ( void )dealloc
{
IOObjectRelease( ioObject );
IOObjectRelease( ioIterator );

[ super dealloc ];
}

Nous avons donc maintenant établi la communication avec I/O Kit, et obtenu un accès au service IOHID.
Il ne nous reste plus qu’à interroger ce service, dans la méthode “timeIdle”.

- ( uint64_t )timeIdle
{
kern_return_t status;
CFTypeRef idle;
CFTypeID type;
uint64_t time;
CFMutableDictionaryRef properties;

properties = NULL;

Nous déclarons ici les différentes variables que nous allons utiliser.

Nous allons en premier lieu récupérer les propriétés de IOHID.

status = IORegistryEntryCreateCFProperties(
ioObject,
&properties,
kCFAllocatorDefault,
0
);

Nous récupérons ici dans notre variable “properties” un dictionnaire, comparable à l’objet “NSDictionnary”.
Nous récupérons également toujours un status du kernel, qu’il nous faut vérifier comme précédemment.

Nous pouvons donc désormais obtenir un propriété de IOHID. Celle qui nous intéresse se nomme “HIDIdleTime”:

idle = CFDictionaryGetValue( properties, CFSTR( "HIDIdleTime" ) );

if( !idle ) {

CFRelease( ( CFTypeRef )properties );

/* Error management */
}

En cas d’erreur, il ne faut pas oublier de releaser l’objet “properties”, afin d’éviter un memory leak.

Un dictionnaire peut contenir plusieurs types de valeurs. Nous devons donc connaître le type de la propriété “HIDIdleTime” avant de la traiter.

type = CFGetTypeID( idle );

La propriété peut être de type “number” ou “data”. Pour obtenir la valeur correcte, chaque cas doit être pris en compte.

if( type == CFDataGetTypeID() ) {

CFDataGetBytes( ( CFDataRef )idle, CFRangeMake( 0, sizeof( time ) ), ( UInt8 * )&time );

} else if( type == CFNumberGetTypeID() ) {

CFNumberGetValue( ( CFNumberRef )idle, kCFNumberSInt64Type, &time );

} else {

CFRelease( idle );
CFRelease( ( CFTypeRef )properties );

/* Error management */
}

Il ne reste plus qu’à releaser nos objets, et à retourner la valeur:

CFRelease( idle );
CFRelease( ( CFTypeRef )properties );

return time;

La classe est terminée. Pour l’utiliser, il suffit de l’instancier et de consulter sa propriété “secondsIdle” (depuis un timer par exemple).

Demo

Voici un exemple de programme utilisant cette classe pour afficher l’inactivité:

idle.m

Pour le compiler et l’executer:

gcc -Wall -framework Cocoa -framework IOKit -o idle idle.m && ./idle

Quel produit sera présenté le 27 Janvier ?

jean — Tue, 19 Jan 2010 23:32:59 +0000

Le 27 Janvier prochain, Apple va présenter un nouveau produit lors de sa keynote. A priori, le buzz du moment est la future tablette, iSlate ou autre nom, vous ne pouvez pas y avoir échappé.

Pour ma part, je me souviens de la keynote d’il y a 3 ans, où a été présenté l’iphone pour la première fois, et la révolution que cela a entrainée. Sommes nous à l’aube d’une autre révolution ? Je l’espère, et attends avec impatience de découvrir ce qui va nous être présenté.

Je pari sur une tablette, avec webcam intégré, 3G, un Kindle sauce Apple, mais communiquant. Le compagnon parfait de mon ordinateur.

En souvenir, l’image que je retiens de la keynote 2007, que vous pouvez retrouver ici : http://www.apple.com/quicktime/qtv/mwsf07/

Plus que quelques jours à attendre….

VIDEO ITW – What are the next cool things for conversation?

netinfluence — Tue, 08 Dec 2009 09:10:53 +0000

This article was originally created by Marie Girardet (Left our team)

The difference between the US and europe, in terms of technology adoption, is less and less the time. We used to have to wait years to get access to new stuff. This is less and less the case.

Thanks to the internet which eliminated boundaries & distances, we are shiffting toward a “real-time conversations area”. And the mobile development as allowed for a vast potential for future applications. Blogs used to be conversations as once stated Loic Le Meur. Now conversation is everywhere, anytime, and live.
Loic has shared his vision on how he was seeing conversations evolving , and we want to share it with you too

Following leWeb, whether online or live, if you are in paris, is a must.

For those of you developing businesses or online strategies, this is the “must be” area, every year. Check their website, subscribe or follow the ustream feed.

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

Leweb09 : pourquoi ce rendez-vous est indispensable

sandrine — Thu, 08 Oct 2009 10:26:00 +0000

Voici pourquoi j’irais au web09 et pourquoi je vous RECOMMANDE VIVEMENT d’y aller.

Je ne dis pas ça par amitié uniquement pour les organisateurs, mais parce que le programme de la conférence cette année est extraordinaire. J’en parlais l’année passée, pour les entreprises, ce qui est important, c’est vraiment de pouvoir comprendre les avantages et les exemples de succès des entreprises qui utilisent les réseaux sociaux dans leur communication.

Cette année, leweb09, rassemblera les leaders de ces plateformes avec des entreprises qui les utilisent. On y verra aussi de nombreux intervenant pour parler de la guerre iPhone – android et surtout on y parlera e-commerce, notamment avec Tony Hsieh de Zappos.

Je sais que vous allez dire que le prix est important, mais dites vous la chose suivante : c’est en gros ce que vous demandera un consultant à la journée pour vous dire probablement pas 1/5 de ce que vous allez entendre deux jours durant.

Alors dépensez cette somme et venez voir les acteurs, ces pionniers en chair en en os et profitez de cette exceptionnelle opportunité de faire un networking de haut vol.

Et si vous venez de Suisse et vous sentez perdu, souhaitez que nous vous présentions les personnes qui comptent, je me tiens à votre disposition pour vous aider sur place et me réjoui de faire votre connaissance.

Si vous voulez économiser sur le billet, en y allant à plusieurs comme raphael le suggère vous pourrez profiter d’un rabais > surveillez twitter, vous n’êtes probablement pas les seuls à y aller.

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.

EVENT | NETALKS – Join our meeting on keynote & iPhone 3GS

sandrine — Tue, 09 Jun 2009 06:57:00 +0000

Back from the keynote and based an what info is public (NDA should run for quite a few months based on last year), we propose to organize a casual “unmeeting” on thursday 18th in our office. This not-quite-a-meeting would allow attendees to share info, for those who have been to San Francisco and ask questions for those of you willing to take advantage of developments on the iPhone. The event is open but please register by mail (contact at netinfluence.ch) so that we make sure all of us can fit in the room and that we get sufficient drinks So if you want to talk about what to develop, how, what comes next and keynote impressions, join us on thursday 18th june, 18:00 at netinfluence’s office (rue marterey 1-3, lausanne)

Keynote news : new iPhone and really improved features !

sandrine — Mon, 08 Jun 2009 18:20:00 +0000

To make it short, the new iPhone 3G S is going to be faster (s for speed) and with a longer battery life and will come in 2 versions :

8GB (99$) – current version
16GB (199$) – 3GS
32GB (299$) – 3GS

Among the new features comes :

improved camera lens with auto exposure, auto focus, 3MP
video capture enabled
video editing from within the iPhone
compas (tells you the north, south, lattitude…)
lansdcape keyboard for all native apps (email, messages, notes…)
MMS feature (allowing to send text & pictures)
Voice control to make your calls or control your iPod music launch
feature to find your iPhone (makes a small alert)
Number to block your iPhone in case it gets stolen
Push now available : comes with 3 different possibilities > sound alert, messaging of app launch
copy / paste and undo features available also within developers apps (comes within API)
more than 1’000 new APIs are available

To be also noticed from the application side :

more “health apps” to control your blood pressure, alert in case of patient health pb…
major navigation app coming with TOMTOM

Figures :

The iPhone has already 50’000 applications whilst android hardly got 5’000 and blackberry 1’000
2/3 of “phone browsing”, 65% is done by an iPhone
They already got more than a billion apps downloaded
As of april 23, they had sold 40 million iPod Touch & iPhones

More here : iPhone website Follow the guided tour (15 minutes)

10 days to get the best out of the valley!

netinfluence — Sun, 07 Jun 2009 05:27:00 +0000

This article was originally created by Marie Girardet (Left our team)

Here we are! Good morning San Francisco! We dreamt of it, now here we are
Two members “net-team” will be in the silicon valley for just 10 days. Emilien is here to attend the WWDC conference while I will be wandering around, meeting people and attending a few events.
Isn’t that great ?

We arrived a few hours ago in the airport where we could already feel the fever of the city, and the kindness of people.
On the way of our hotel, we met a nice guy, friend with the guy who developed the “iBeer” iphone application.
People are great ! They talk easily and always try to help giving useful tricks and stuff. That’s nice to be welcome and treated like that. I guess we should learn a lesson from this!

Here is the program of the week:

Emilien, our iphone expert is booked all week with the WWDC.
In the meantime, I will try to make as many things as possible.
First I’m booked for wednesday and thursday for 2 conferences :

The first one is “Influx Curated“ and takes place in San Francisco. In this event I will attend some sessions and make some networking. My objective is to meet people, create a relationship and share experiences.
The second event, is an unconference, a barcamp. It takes place in Mountain View, where you have all the Google, Apple and Ebay headquarters.

I hope that I will meet a lot of interesting people and attend nice sessions. I’ll try to visit a bit more of Mountain View but it is quite hard to enter Google or Apple buildings without knowing somebody working in it.( so any ideas, let me know…)

The rest of the week I have planned some interviews with web leaders and marketing gurus. I am curious to find out what will be the outcome
Indeed we thought it would be interesting to talk with people working over here, in the heart of the web beat, to see how they perceived european web companies, and how they see the future, what is going to be the next big thing …

I will keep on sharing in the blog and of course post the ITW once they get ready. Hope you enjoy and if you have suggestions or remarkes…do not hesitate to add your comments

See you then for the next episode

UIAlertView en mode paysage

netinfluence — Tue, 26 May 2009 07:05:00 +0000

This article was originally created by Emilien Vuillaume (Left our team)

Si comme moi vous avez développé une application uniquement en mode paysage (bouton home à droite ou à gauche) vous avez pu noter un problème plus ou moins gênant.

En effet, en utilisant une UIAlertView, celle-ci s’affichera en mode portrait !

Le problème vient du fait que l’on a défini l’orientation dans le fichier plist et que lors du chargement de l’application, l’orientation n’est pas bien reportée au niveau de la “StatusBar” de l’application.

Exemple :

La solution est de réaffecter la valeur d’orientation actuelle de votre iPhone ou iPod Touch à la propriété StatusBarOrientation de l’application avant d’afficher votre alerte :

if([[UIDevice currentDevice] orientation] == UIDeviceOrientationLandscapeRight){   [[UIApplication sharedApplication]                    setStatusBarOrientation:UIInterfaceOrientationLandscapeLeft];}else{   // en mode LandscapeRight par default   [[UIApplication sharedApplication]                   setStatusBarOrientation:UIInterfaceOrientationLandscapeRight];}

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:title]                                                message:message                                               delegate:nil                                      cancelButtonTitle:@"OK"                                      otherButtonTitles:nil];

[alert show];[alert release];

et voici le résultat :

Une communauté iPhone très active en Suisse

netinfluence — Fri, 15 May 2009 12:10:00 +0000

This article was originally created by Emilien Vuillaume (Left our team)

La 3ème réunion du groupe “Les développeurs iPhone de Suisse Romande” hier soir au sous-sol du café Le Vaudois à Lausanne à rencontré un grand succès.

Le but de ce groupe, qui compte actuellement 125 membres, est tout d’abord “l’échange d’informations autour du développement iPhone, le partage d’expériences et l’organisation d’événements une fois par mois dans la région Lémanique”.

Après un tour de table pour présenter tous les nouveaux arrivants, deux sujets de discussion ont été lancés :

Présenté par Sébastien Hugues, le premier sujet présentait l’utilisation des services Facebook dans les applications iPhone et l’intérêt viral que cela représente.
Par exemple il est très facile de publier le score de l’utilisateur sur son profil Facebook ce qui va entraîner une sorte de compétition entre les membres de son réseau et ainsi accroître rapidement la popularité de votre application.
Pensez-y dans vos futurs projets et n’hésitez pas à le proposer à vos clients.
Le second thème, présenté par Gilles Cherix, plus technique, portait sur le choix du format d’échange des données entre deux entités (iPhone/Serveur web, iPhone/iPhone, etc…). Après une longue discussion, les deux principaux formats retenus sont le XML et le JSON. Il en ressort que la solution la plus simple est toujours la meilleure. Si votre application iPhone ou votre serveur doit intégrer une bibliothèque complexe pour utiliser le flux d’information, alors pensez à un autre format d’échange…

Pour conclure cette session, nous avons fait le point sur la communication entre les membres du groupe (forum, mailing-list, etc…) ainsi que sur un possible changement de nom. Il se pourrait même qu’une application open source voit le jour!

Affaire à suivre…

Si vous êtes intéressé à nous rejoindre et à participer à nos rencontres, rejoignez le groupe Facebook : Les développeurs iPhone de Suisse Romande

A bientôt…

Application iPhone en mode paysage

netinfluence — Wed, 13 May 2009 06:41:00 +0000

This article was originally created by Emilien Vuillaume (Left our team)

Par défaut, une application est définie en mode portrait et effectue une rotation en fonction de la position de l’iPhone/iPodTouch.

Cependant il peut arriver que l’on ait besoin de forcer le mode d’affichage de l’application en mode paysage et empêcher sa rotation.

Plusieurs solutions existent pour définir le mode d’affichage.
Par exemple, il est tout à fait possible d’effectuer une rotation de chaque vue lors de leur chargement comme j’ai déjà pu le voir… Mais cela implique plusieurs inconvénients :

il est très fastidieux voir impossible de définir correctement la disposition des éléments sur la vue (label, bouton, etc…) en mode paysage à partir du visuel en mode portrait.
l’application risque de manquer de fluidité et dégrader fortement l’expérience utilisateur.

Une meilleure solution consiste à utiliser les directives de configuration disponible dans XCode et le SDK ainsi que d’utiliser au mieux Interface Builder (IB) :

Configuration
Dans le fichier “.plist” de votre application, ajoutez la directive suivante :
```
Initial interface orientation / Landscape (right home button)
```
Ceci aura pour effet de lancer l’application en mode paysage dès son chargement.
Interface Builder (IB)
Créez vos interfaces directement en mode paysage.
Pour faire une rotation de la vue, cliquez sur la flèche en haut à droite de la fenêtre de votre vue :
XCode
Vous devez surcharger la méthode suivante dans chaque classe ViewController pour spécifier si l’interface doit effectuer une rotation ou non en fonction de l’orientation de votre iPhone/iPodTouch :
```
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation{    if(interfaceOrientation == UIInterfaceOrientationLandscapeRight)	{		return YES;	}	return NO;}
```

Voila, votre application restera toujours en mode paysage.

Cours iPhone dans son canapé

julien — Tue, 21 Apr 2009 09:08:00 +0000

L’iPhone vous emballe et je comprends pourquoi. Mais vous voulez aller plus loin en développant votre propre application et la voir grimper dans la classements de l’AppStore. Le seul problème, c’est qu’il faut apprendre à développer en Objective-C. Voici une solution simple : iTunes U.

En effet, iTunes U permet depuis quelques semaines un accès simple à une formation sur le développement sur iPhone. Il s’agit des cours donnés aux étudiants de Stanford qui ont été enregistrés et “podcastisés” sut iTune. C’est accès est gratuit et l’enseignement de qualité, c’est Stanford tout de même…

Le seul pré-requis est d’avoir un mac avec Xcode et de bonnes bases dans un langage de programmation quelconque, ensuite on s’installe et on apprend. Le cours vient avec son site web (slides, exercices, etc).

Bon cours

Liens :

http://itunes.stanford.edu/
http://www.stanford.edu/class/cs193p/cgi-bin/index.php