[Objective-C] Les bases de l'Objective-C [Article]

[Kerod]

Bonjour,

Voici un petit tutoriel, écrit par Axon_de TutoMobile, qui nous fera découvrir les bases du développement sur iPhone. Il nous permettra de nous familiariser avec l'Objective-C et les outils de développement fournis par Apple (Xcode dans un premier temps) : http://a-renouard.developpez.com/tut...e-objective-c/

Toutes les remarques sont les bienvenues !

Merci.

[Madmac]

Est-ce qu'il existe un émulateur Iphone qui permet de tester le programme sans avoir un Iphone ?

[Ragmaxone]

Envoyé par Madmac

Est-ce qu'il existe un émulateur Iphone qui permet de tester le programme sans avoir un Iphone ?

dans les outils installés avec Xcode il y a un testeur iPhone (je sais pas pour iPad).

ce n'est pas un émulateur car Xcode compile l'appli en x86, pas en ARM.

pour s'en servir, il me semble qu'il y a une commande "tester" dans l'interface de Xcode (peut pas en dire plus )

[sgamel]

Objective-C n'est pas un langage limité à iOS. C'est aussi le langage de choix pour Mac OS X (dont iOS n'est qu'une variante).

Mais le principal "inconvénient" pour un développeur c'est de devoir acheter un Mac pour faire du développement iOS.

C'est totalement vrai (même si quelques solutions peuvent exister).

En revanche pour Objective-C vous pouvoir déjà vous faire la main sous Windows et Linux en utilisant GNUStep, une implementation open-source de l'essentiel des classes de Cocoa.

Pas de développement iOS donc mais la possibilité d'appréhender les API communes à Cocoa et Cocoa-touch en attendant de recevoir votre Mac

Et pour se mettre à Obj-C il existe quelques livres sympas

[sgamel]

Oui XCode est fourni avec un simulateur de iPad et iPhone.

Il suffit de lancer l'application en indiquant quel simulateur doit être utilisé (ou quel périphérique si un iPhone, iPod ou iPad est branché).

Mais c'est largement insuffisant puisque certaines applications ne compileront pas pour le simulateur (par exemple si on utilise le framework de capture vidéo). Impossible de tester ce qui est spécifique au niveau matériel (accéléromètre, boussole, gyro, multipoint a plus de 2 doigts, etc.)

Mais c'est un bon début. Et suffit de s'enregistrer gratuitement comme développeur.
Ceux qui payent ont simplement accès à un certificat qui leur permet d'installer sur un périphérique et de publier sur l'App Store.

[Zack_r]

Juste pour compléter le poste de sgamel, ceux qui souscrive à l'offre particulier (pas entreprise), peuvent installer jusque 100 appareils iOS. Pratique pour faire des tests sur différentes plateformes.

++

[youpitralala]

Bonjour,

Cette formation est vraiment très très claire. J'espère qu'il y en aura beaucoup d'autres par la suite et qu'il n'y aura pas de découragement du rédacteur.

Bonjour,

Bon tutoriel, mais (oui, il y a toujours un mais quand ça commence bien) je me permets de faire ces remarques :

- l'Objective-C étant un « dérivé » du C, vous pouvez coder aussi bien en Objective-C qu'en C, cependant vous devez entourer votre code avec des crochets pour que le compilateur interprète votre code en tant qu'Objective-C et non en C ;

il serait plus correct de dire : Les appels de méthodes en obj-C se font par crochets. C'est à dire [objet methode]; et non objet.methode();

- lorsque vous utilisez une chaîne de caractères Objective-C, vous devez le « signaler » au compilateur en la précedant du signe @.

Code c :

Je pense qu'il manque dans cette phrase la distinction entre tableau de caractères en C et la classe NSString.

Il manque dans le code -selon moi- les types :

Code c :

1
2
3
4
// Chaine C
char myString[] = "Chaine C";
// Chaine Objective-C
NSString *myString = @"Chaine Objective-C";

Code c :

Ici, il faudrait mettre Définition (je reconnais que c'est du pinaillage)

Sinon, je trouve le tutoriel pas mal, il a le mérite de ne pas confondre Objective-C et cocoa.

[yannickcadin]

Bonjour,

Désolé, je vais jouer les rabat-joies.

L'expression

[[myObject release] release];

produit une erreur à la compilation. Et pour cause, la méthode release retournant un 'void', en gros ne retournant RIEN (pas d'objet), il est délicat alors d'envoyer un 'release' à du vide.

Je n'ai pas tout regardé car je n'en ai pas besoin (je sais, je suis TRÈS prétentieux) mais il me semble qu'il y a d'autres coquilles du même acabit.

Quoi qu'il en soit, ceci se veut être une critique constructive. Autrement dit bravo pour le travail réalisé et bonne continuation :-)

[JeitEmgie]

@implentation -> @implementation

strcmp(‘maChaine', ‘maChainedeComparaison') -> strcmp(maChaine, "maChainedeComparaison")

et l'équivalent en Objective-C est - (NSComparisonResult)compare:(NSString *)aString et non isEqualToString

Code :

1
2
myString = @"Chaîne Objective-C";

L'usage de caractères accentués dans les constantes de chaînes de caractères est source de problèmes et doit être proscrit.
Il faut les "escaper" avec \u####, ce qui donnera ici @"Cha\\00eeune Objective-C"

Code :

1
2
- (void) changeProperty: (id *) property andName: (NSString *) name;

le type id est un pointeur en lui-même :

Code :

1
2
3
4
typedef struct objc_object {
    Class isa;
} *id;

donc id * signifie que l'on passe l'argument par adresse
ce n'est pas nécessairement ce que l'exemple voulait indiquer, tel qu'écrit cela veut dire qu'on l'invoque ainsi :

Code :

1
2
3
NSObject *param ;
[someObject changeProperty:&param andName:@"someName"];

Code :

1
2
myString = [NSString init]; => myString = [[NSString alloc] init] ou myString = [NSString alloc] ; [myString init] ; ou encore myString = [NSString new] ;

et

Code :

1
2
[NSString release]; => [myString release]

La syntaxe [] est inspirée de SmallTalk mais la "dot syntax" est supportée aussi depuis Objective-C 2.0 pour les accès au variables d'instance :
[bat setFoo:@"Foo"] ou bar.foo = @"Foo" (pour les variables d'instance @synthesize-d…)

(À noter aussi : sous certaines conditions le KVC-coding pour l'accès aux variables d'instance est aussi supporté : [object setValue: forKey:] et [object valueForKey:])

Le caractère OO d'Objective-C va au-delà des notions habituelles de taxonomie de classes :
le binding est "late and dynamic" : la méthode à invoquer est évaluée au runtime et non à la compilation ("La Grosse" différence par rapport au C++).
C'est ce qui permet aussi lors de l'exécution la définition (la construction) de nouvelles classes , la substitution de classes, l'ajout ou le remplacement de méthodes, … (exemple: class_addMethod … une méthode Objective-C n'étant jamais qu'une fonction C prenant 2 premiers arguments implicites : "id self" et "SEL cmd")

Et petits détails : les messages à "nil" ne plantent pas un programme, les appels de méthodes non déclarées ne sont que des warnings à la compilation, et le comportement à l'exécution peut être configuré (il est possible d'interception l'exception, rediriger le message vers un autre objet, …).

Ce qui implique aussi que l'Objective-C ne doit pas être utiliser là où ces caractéristiques n'apportent rien, car le "late binding" a un coût à l'exécution : implémenter une FFT en Objective-C sera pour le plaisir et pas pour les performances.

L'atout principal est évidemment l'usage qui en fait pour réaliser la "glue" entre les interfaces utilisateurs et le code dans InterfaceBuilder mais il y en a d'autres comme l'injection de nouvelles classes dans un code existant… l'énorme facilité (par rapport au C++…) pour réaliser un programme qui supportera des plug-ins… le support de l'invocation de méthodes d'objet distants (dans un autre process… sur une autre machine…), etc.

Parmi les pièges du débutant à éviter, l'usage abusif des classes comme NSString là où le traitement peut être réalisé avec des char * ou wchar_t :
NSString encapsule le traitement des chaînes pour faciliter la gestion des encodages, des caractères spéciaux (ß, fi, fl, …) dans les tris,… et facilite par là-même l'affichage quel que soit le système de l'utilisateur : comme des chaînes romanes sur un système japonais…

Si vous devez manipuler des chaînes qui n'ont aucune vocation à être affichées, triées selon des localisations,… des chaînes qui n'ont qu'une vie interne au programme… il n'est pas nécessairement malin (pour les performances…) d'en faire des NSString… par contre si le code concerné n'est pas crucial pour les performances, il est clair que le confort apporté est non négligeable.
(Remarque valable aussi pour NSArray, NSNumber, … )