# Quel livre pour apprendre cocoa ?



## Anonyme (26 Avril 2004)

Salut à tous,

Je vais essayer de me remettre à nouveau à cocoa, j'ai du temps en ce moment.
J'avais acheté le livre "Cocoa par la pratique" puisqu'il est en Français il y a quelques temps, mais j'avoue que j'ai eu du mal, même avec les bonnes notion de C que je possède.

Je compte investir dans un autre livre mais il y en a pas mal en Anglais.
Cocoa for dummies
Cocoa in a nutshell
Learning cocoa with objective-c
Cocoa recipes

Bref, je ne sais lequel prendre pour un niveau le plus débutant possible... Si vous avez acheter ces livres, dites le moi.
Merci.


----------



## Tiff (26 Avril 2004)

J'ai bien aimé Cocoa par la pratique même si j'avoue ne pas avoir tout compris à fond (Je l'ai lu 3 ou 4 fois, une cinquième devrait faire l'affaire, avec du recul !).
Mais c'est le livre qui m'a le plus aidé. J'avais essayé Learning Cocoa de O'Reilly, que j'ai trouvé trop théorique et peu explicatif dans les exemples, surtout lorsqu'ils se compliquent, c'est le comble ! J'attends qu'un nouveau livre sorte car, depuis Panther, Cocoa a vu arriver, entre autres, les Object Controller qui permettent d'économiser du code. Donc les "anciens" guides risquent d'être dépassés pour la nouvelle philosophie de Cocoa. Mais je ne suis pas pressé.
Es-tu allé sur le site de ProjectOmega, qui propose pas mal d'exemples traduits en français ?


----------



## Tiff (26 Avril 2004)

Ah les coquins, le forum MacGé et le forum Project:Omega ne font qu'un. Donc tu connais forcément ProjectOmega...


----------



## Anonyme (27 Avril 2004)

Oui, je connais ProjectOmega. =)
J'ai fait les 2-3 premiers tuts pratiques pour Cocoa. Merci à eux pour ces traductions.

Je vais réessayer de m'atteler à "Cocoa par la pratique" mais c'est vrai que j'avais explosé au bout de 50 pages la dernière fois... même quand on relis des paragraphes 2 fois... c'ets hard.


----------



## Ludopac (27 Avril 2004)

Je pense que le mieux pour apprendre, c'est de se fixer un petit projet (sans être trop ambitieux).

Tu commences ta petite application et à chaque blocage tu fais une recherche. Après tu te replonges dans ton bouquin et ça te paraîtras plus clair


----------



## mpergand (27 Avril 2004)

Je ne connais aucuns des titres que tu cites, mais je doute que la seule lecture de l'un d'entre-eux te permette d'acquérir la maîtrise immédiate de Cocoa.

 Apprendre à programmer en  Cocoa est un processus long et difficile, cette framework est vraiment particulière et ne ressemble en rien à ce que l'on peut rencontrer dans d'autre environnement (OS 9 , Windows, etc)
L'autre problème est que la doc Apple est loin d'être un modèle du genre 
	

	
	
		
		

		
		
	


	




Le meilleur moyen de progresser en programmation, c'est la pratique: s'exercer encore et encore,  et plusieurs mois seront certainement nécessaires avant de te sentir à l'aise.

Et puis ne pas griller les étapes, débuter par des choses simples:  commencer par bidouiller les différents boutons et objets graphiques dans interfaceBuilder, et comprendre comment interagir avec eux. Et petit à petit le brouillard devrait s'éclaicir 
	

	
	
		
		

		
		
	


	





Ne pas oublier qu'il existe une alternative à Objectivec: c'est Java. Beaucoup pensent qu'il est incongru d'utiliser Java en cocoa, mais  c'est juste un autre moyen (outil) de faire les choses, pas la finalité.
Java permet juste de faire une appli Cocoa deux fois plus rapidement qu'en ObjectiveC (on parle ici de programmation en amateur, bien sûr), alors 'just have a try !'


Voilà, courage et persévérance devraient te permettre d'arriver à tes fins


----------



## Tiff (27 Avril 2004)

Effectivement, dans Cocoa par la pratique, il ne faut pas s'arrêter au bout de 50 pages. Commence par le tutoriel de la page 83. Il permet de construire une application simple au départ, qui s'étoffe au fil des chapitres en utilisant les principes de base de Cocoa. Une fois que tu vois ton appli fonctionner, avec les différents "objets" qui communiquent entre eux, tu peux revenir régulièrement à la théorie (classes instances messages) des 82 premières pages.
Ne va pas trop vite ; à la fin de chaque chapitre, j'essaye de refaire l'application sans regarder le livre pour voir si j'ai compris les principes. L'écriture du code ne me parait pas très complexe, bien que je n'ai jamais fait de C. Le moins évident pour moi est de bien appréhender les différents objets qui vont être utiles, et les communications entre eux. Les diagrammes d'objets proposés par Cocoa par la pratique ne me sont pas très parlants, bien que je sois convaincu qu'il faille utiliser quelque chose comme ça.

Le manuel idéal serait interactif, proposant un projet à construire, avec des choix à faire (type d'application, controleur de l'appli, classes à créer, à utiliser, etc). Si on répond à côté, le guide explique pourquoi. Et on avance ainsi, petit à petit.

Enfin, si tu bloques à la page 85, fais-moi signe !


----------



## Anonyme (27 Avril 2004)

Déjà, merci de votre accueil.  
	

	
	
		
		

		
		
	


	




Ludopac : oui, c'ets une bonne idée un petit projet. De toute façon, pour programmer il faut passer son temps à fouiner dans les docs...  Mais je crois qu'une fois les principes "majeurs" compris (OO, messages, receivers, héritage...etc), ça doit aller, il faut juste chercher la syntaxe de tel ou tel langage... ici cocoa. J'ai fait beaucoup de php (mais pratiquement pas d'objet) alors je rame pour apprendre tous ces concepts, mais ça va finir pas rentrer j'espère.

mpergrand : je passe directement sur objectiveC, bien que java soit un "grand langage", car c'est le langage natif OS X (je t'apprends rien), alors quitte à apprendre un langage pour le Mac, j'essaie celui-là vu que j'en ai entendu et lu tant de bien 

Tiff : merci, je vais m'y atteler ! Et je te ferai signe si je patine. C'est clair qu'il faut refaire les exercices sans le bouquin, bonne idée.


----------



## aLittleWoodElfe (28 Avril 2004)

Si tu comprends l'anglais je te conseille aussi l'excellent http://www.cocoadev.com/ qui complète bien la doc d'Apple.

Comme bouquin j'utilise aussi Objective-C précis &amp; concis de chez O'REILLY, attention ce n'est pas un bouquin pour apprendre cocoa mais juste une synthèse du langage Objective-C (syntaxe, gestion de la mémoire,etc).


----------



## Anonyme (28 Avril 2004)

Merci.
CocoaDev a l'air bourré de ressources... sympa.


----------



## Anonyme (28 Avril 2004)

Bon, j'ai fait les 6 premiers tutorials project-omega (jusqu'au colorimètre), et je me replonge dans Cocoa par la pratique. 

Et je commence à piger plein de choses.  Joie.
vive cocoa.


----------



## Anonyme (29 Avril 2004)

J'ai fini le tut sur la gestion des employés dans cocoa par la pratique (à vrai dire je n'ai compris que la moitié du code), ça compile, pas d'erreurs. Mais lorsque j'ajoute un employé, rien ne se passe... :-(

Tu as eu un Pb similaire Tiff ?


----------



## Tiff (29 Avril 2004)

Pas de problème pour l'appli de gestion des employés du chapitre 4.
Au démarrage de l'appli, une fenêtre s'ouvre avec écrit :
Employé 1 sur 1
Nouvel employé
0,00 %

SI je clique sur Créer employé, j'obtiens :
Employé 2 sur 2
Nouvel employé
0,00 %
et les boutons Employé précédent et Supprimer employé deviennent actifs.

Les champs Nom et augmentation ne changent pas, car, par défaut, tous les employés créés s'appellent Nouvel employé et ont un taux de 0,00% (code écrit dans la méthode init de la classe modèle Person, et que tu peux modifier comme tu veux).

remarque : l'interface utilisateur de cette première appli n'est pas très performante, mais ce n'est qu'un début

Quel est ton problème exactement ? Si tu changes le nom et l'augmentation et que tu cliques sur Créer employé, que se passe-t-il ? Vraiment rien ? Le bouton est-il bien relié à File's Owner ?

Pour m'écrire directement :  jerome.care@wanadoo.fr


----------



## Manu (3 Mai 2004)

Je ne répèterai jamais assez ceci :
Pour bien programmer en Cocoa il faut bien comprendre le concept MVC. Pour cela une démarche toute bête. dès que t'as une idée de dev, commence par dessiner sur un bout de papier ton interface graphique ou du moins comment tu l'imagines.
Ensuite tu donnes des noms à des éléments de ton interface. Par exemple un bouton valider_saisie, un champ NOM un autre PRENOM etc...
Ensuite tu dessines sur une autre feuille un objet sous forme de 'patate' dans lequel les noms et prenom sont ce qu'on appelle des IBOUTLET (pour zone de Interface Buider d'alimentation des champs), et au nom des boutons tu associes des actions ou IBACTION. Ex : valider_saisie.

Le dessin de ton interface c'est la pertie VIEW, ta patate c'est ta partie CONTROLLER. 
Si tes donnée proviennent de fichiers ou autres chose, tu dois décrire sa structure par exemple
Employe : nom, prenom, adresse ... 
et tu défini donc un objet EMPLOYE. Ce sera ton MODELE.
Le controller fait la liaison entre ton modèle et ton interface.
Une fois que t'as saisi ce concept, les concepts fondamentaux à connaitre sont la délégation et la Notification.
Pour mieux comprendre le concept objet, ne te casse pas la tête. Dès que t'as un problème à résoudre, dis toi que tu veux un objet qui peut le résoudre. Ensuite tu liste toutes les actions que cet objet est censé accomplir. Tu appliques le concept MVC. C'est assez rudimentaire mais croies moi c'est bête et efficace. J'ai plein de copains qui sont devenus des dieux de cocoa en appliquant ces règles qui sont primaires certes mais te permette de vite assimiler le concept fonadamental et te permet de t'instruire ensuite par les lectures ou mieux en lisant bien les détails des objets des Frameworks Fondation Kit et Application Kit. Le premier contient tous les objets que tu utilises dans ton programme en codant le CONTROLLER, le second contient en fait le détail des objets que tu utilises dans Interface Builder.
Un exercice qui te permet d'appliquer tout ce que je viens de dire :
Une petite appli avec une interface comprenant une zone de saisie texte (texteView), deux zones d'affichage.
Le but de l'appli : 
Au fur et à mesure que l'on saisie du texte dans la première zone, la seconde affiche le nombre de mots que tapés et la troisième le dernier mot tapé.
Cet exercice réuni la plupart des notions à connaitre sur Cocoa.


----------



## Anonyme (3 Mai 2004)

Merci manu.
J'ai lu plein de fois ce fameux terme MVC appelé paradigme je crois.

Je suis en train de faire le premier exercice de cocoa par la pratique :
- 1 zone de saisie
- 1 bouton
- 1 zone qui affiche le nombre de lettres du mot entré dans la zone de saisie.

Cet exercice se rapproche du tient. Mais je patine... 
	

	
	
		
		

		
		
	


	



(J'ai demandé de l'aide à Tiff par mail)


Toutefois, si j'avais à faire le tient, voilà ce que je ferai :

- 3 outlets pour les 3 champs (text saisi, comptage mots, dernier mot)
- 2 actions
- je crée une classe appelée "Counter", je l'instancie.
- je relis mes oultets (instances vers outlets, puis connect)



Dans xtools, je me retrouve avec mon fichier Counter.h ou sont déclarés mes outlets, et mes actions.
Maintenant, je vais dans Counter.m pour développer mon contrôleur.
Et là, je pige pas des trucs.

Dans ma première action, je dois compter le nombre de mots de la phrase par une méthode cocoa.
Deuxième action : prendre le dernier mot de la phrase.
Et ensuite envoyer ça à mes outlets, par exemple : afficheNbWord et afficheLastWord comme ça :
[afficheNbWord setIntValue:compteur];

Bon, ya des trucs flous ds ma tête. Les actions sont des types de méthodes particuliers. Seulement, est ce qu'il faut appeler une méthode pour compter le nombre de mots depuis cette action, méthode qui peut être définie par un void, ou bien est ce qu'on fait tout à l'intèrieur de l'action (si c possible) ?

Par exemple, pour compter les lettres d'un mot,on te dit d'utiliser cette méthode : -(int) length;
Est-ce qu'on doit se servir de ça dans l'action ou à part ?

Je viens du php, et en php on écrirait :
$compteur_lettres=méthode($ma_var);

là je voudrais écrire un truc de ce genre :
[nb_lettres length: textSaisi];


----------



## la tortue (3 Mai 2004)

izostar a dit:
			
		

> Je viens du php, et en php on écrirait :
> $compteur_lettres=méthode($ma_var);
> 
> là je voudrais écrire un truc de ce genre :
> [nb_lettres length: textSaisi];



Simple: nb_lettres = [textSaisi length];


----------



## Anonyme (3 Mai 2004)

Ok merci tortue.
J'ai testé ça marche.


----------



## la tortue (3 Mai 2004)

<blockquote><font class="small"> izostar:</font><hr />J'ai testé ça marche. 

[/QUOTE]
La syntaxe générale pour les messages ObjC:
(rv =) [obj methodeparam1 (puisaram2) etc)];

Ce qui correspond à l'appel de fonction suivant:
(rv =) imp(self = obj, _cmd, param1, param2, etc); 
avec _cmd = @selector(methodeuis:etc 
et imp = l'implémentation de la méthode pour la classe en question...

Allez, au boulot! 
	

	
	
		
		

		
		
	


	



Hésite pas à poser des questions.
Bon courage...


----------



## Anonyme (3 Mai 2004)

la tortue a dit:
			
		

> Allez, au boulot!
> 
> 
> 
> ...



Merci.
T'inquiètes, des questions je vais en avoir des tas... 

Par exemple, je comprends pas ce qu'est un "selecteur".


----------



## la tortue (3 Mai 2004)

<blockquote><font class="small"> izostar:</font><hr />Par exemple, je comprends pas ce qu'est un "selecteur".

[/QUOTE]
En gros selector = nom de methode.
Par exemple: [obj methodearam];
est équivalent à: [obj performSelectorselector(methode withObjectaram];
et encore à: objc_msg_send(obj, @selector(methode, param);

En fait quand tu écris :  [obj methodearam] 
le compilateur génère le code suivant: objc_msg_send(obj, @selector(methode, param);

C'est à peine plus compliqué si la méthode renvoie une valeur de type structure.
Ici "selector" est un identifiant de méthode (int) correspondant au nom de la méthode.

Voir aussi les fonctions NSStringFromSelector() et NSSelectorFromString()...


----------



## Manu (4 Mai 2004)

Première réponse :

Losrque t'as créé ton interface, pour la zone de saisie tu as 'drag'n dropper' l'element textView de la palette de IB.
les deux champs nombre de mot et dernier mot sont des NSCell.

Pour le codage de ton Controllet :
 Première chose à savoir c'est que ton controller 'controle' ton interface. La première chose c'est que dès que ton interface s'affiche, le nombre de mot est de 0 et le dernier mot à blanc. Pour initialiser tes zones tu dois utiliser la methode awakeFromNib. cette méthode est TOUJOURS appelée par le runtime cocoa avant que l'interface soit affichée.
Dans cette methode tu mettras donc 

[afficheNbWord setIntValue:0];
[afficheLastWord setStringValue" "];

Ce sont 2 methodes de l'objet NSCell dans la rubrique 'Setting' and getting cell values' de la doc de Application Kit.

Ensuite ton objet zoneDeSaisie est un NSTextView. Or en consultant la doc de cet objet dans Application Kit, on s'apperçoit que cet objet herite de NSText. Donc toutes les methodes de NSText s'appliquent.
Deuxième chose, il faut voir la zone de saisie comme du texte en continu donc une longue NSString . Donc pour transformer en NSString on consulte les methodes de l'objet NSText et Ô miracle la methode string le fait.
NSString leTextte = [zoneDeSaisie string];
On peut alors considérer qu'une chaine de caractères est un ensemble de mots separés par des blancs.
Or dans la rubrique dividing stings de l'objet NSString (Fondation Kit), j'ai la méthode componentsSeparatedByString qui permet de diviser une chaine en un ensemble (NSArray.

donc ensembleDeMots = [leTexte componentsSeparatedByString" "] ou simplement
ensembleDeMots = [[zoneDeSaisie string] componentsSeparatedByString" "];

Le tour est joué. En effet avec un objet NSArray la methode count me donne le nombre de mots et la methode lastObject me donne le dernier mot.

[afficherLastWord setStringValue:[ensembleDeMots lastObject]];
[afficherNbMots setIntValue:[ensembleDeMots count]];

Il reste une question ou mettre toutes ces instructions?
C'est là où on fait appel à la puissance de Cocoa et de l'objet NSText.
Une chose importante quand tu lis la doc d'une classe Cocoa Objective C, il y a 4 zones importantes. 
la zone Adopted Protocols qui regroupe la liste des 'protocoles' auquels la classe se conforme (j'expliquera cela après), la zone des méthodes de la classe, puis la zone Delegate Method types qui est la liste des méthodes appelés par l'objet à des moments précis.
Enfin la zone Notifications qui regroupe l'ensemble des méthodes envoyés par un objet au NotificationCenter pour informer les autres objets du changement de son état. Ces méthodes sont à déclarer par un objet qui doit être déclaré comme délégué d'un objet NSText ou NSTextView.
Donc dans la methode awakeFromNib de counter en plus des 2 methodes d'initialisation décrites plus haut je dois ajouter : [zoneDeSaisie setDelegate:self]; ton objet Counter est le délégé du NSTextView zoneDeSaisie. 
la methode du délégué qui m'interesse est textDidChange. Cette methode du délégué est appelée à chaque fois que tu tapes le texte.
En résumé : Counter contient deux methodes
- awakeFromNib pour l'initialisation
- textDidChange pour afficher tes champs à chaque modification de ton texte saisi.
Je t'ai montré comment utiliser la doc Cocoa, puis je t'ai sensibilisé à la notion d délégué qui est en Cocoa hyper importante et qui justement fait de Cocoa quelque chose de très fort.
J'expliquerai plustard les notions de délégué et de Notification si tu veux bien.


----------



## Anonyme (4 Mai 2004)

Merci de prendre le temps d'écrire des posts si longs... 

Pour la première application qui compte les lettres d'une phrase, elle marche. J'ai voulu ajouter ça pour le pluriel possible au mot lettre :

 <font class="small">Code:</font><hr /><pre>
    if (nb_lettres &gt; 1) {
	NSString *mot_lettre=@"lettres";
    }
    else {
	NSString *mot_lettre=@"lettre";
    }
 </pre><hr />

Mais je me prends des warnings sur mot_lettre. Pourtant dans la doc project omega, c'est de cette façon qu'on déclare une phrase il me semble !

Pour awakeFromNib, j'ai compris à quoi ça servait, mais là je ne vois pas à quoi ça servirait d'initialiser les variables au lancement de l'appli. Quel en est le but exact ? ça marche sans (dans mon cas), p-e que c'ets super utile pour d'autres applis certes...

Maintenant, je vais m'attaquer à la deuxième appli, celle qui compte les mots et affiche le dernier mot.


----------



## Manu (4 Mai 2004)

C'est une bonne habitude qu'il faut prendre qu'on on fait du Cocoa. En plus c'est logique car ta zone de saisie étant vide ton compteur doit afficher 0 et non être à blanc. Moi pour chaque Controller j'ai toujours un awakeFromNib même vide.
D'autre part un NSString est un objet pas une variable. Ton affectation ne lui plait pas.

NSString *toto =[NSString stringWithString"texte"] est plus appropeié.


----------



## Anonyme (4 Mai 2004)

OK, compris. 
C'est vrai que j'avais mis ??? à la place, mais un champ vide est mieux.

Quid du pb pour le NSString ?


----------



## Manu (4 Mai 2004)

Quid du pb pour le NSString ? 

[/QUOTE]

NSString est une classe NSString *toto déclare un objet. Tu ne peux faire une affectation NSString *toto = xxxx;
il faut utiliser une methode d'affectation. Par exemple stringWithString, etc.


----------



## Anonyme (4 Mai 2004)

Je comprends pas.

Dans le tutorial 7 de cocoa POmega, il est écrit :

"
Objective-C nous fournit une grande syntaxe pour créer ces chaînes :

NSString *aString = @"hello again";
"


NSString pointe vers l'objet aString.

Moi, çe ne marche pas parce que l'objet n'est pas créé ???


----------



## la tortue (4 Mai 2004)

Manu a dit:
			
		

> NSString est une classe NSString *toto déclare un objet. Tu ne peux faire une affectation NSString *toto = xxxx;
> il faut utiliser une methode d'affectation. Par exemple stringWithString, etc.


Ben non. 
	

	
	
		
		

		
		
	


	



Tu as le droit de faire: NSString *toto = @"toto";
Cela crée un objet NSString constant à la compilation et est équivalent à :
NSString *toto = (NSString *) CFSTR("toto");

<blockquote><font class="small"> izostar:</font><hr />
   if (nb_lettres &gt; 1) {
       NSString * mot_lettre =@"lettres";
   }
   else {
       NSString *mot_lettre=@"lettre";
   }

Mais je me prends des warnings sur mot_lettre. Pourtant dans la doc project omega, c'est de cette façon qu'on déclare une phrase il me semble ! 

[/QUOTE]
Le problème vient sûrement du fait que tu déclares dans chaque boucle une variable 'mot_lettre' différente... 

Fait plutôt comme ça:
NSString * mot_lettre = nil;
  if (nb_lettres &gt; 1) mot_lettre =@"lettres";
  else mot_lettre=@"lettre";

Ou encore plus court: NSString * mot_lettre = (nb_lettres &gt; 1) ? @"lettres" : @"lettre";

A+


----------



## Manu (4 Mai 2004)

Mea Culpa en effet j'en suis encore au vieu NeXTSTEP. Faisant plus du Java J2EE j'ai quelque peu oublier les évol de Cocoa.


----------



## Anonyme (4 Mai 2004)

la tortue a dit:
			
		

> Le problème vient sûrement du fait que tu déclares dans chaque boucle une variable 'mot_lettre' différente...
> 
> Fait plutôt comme ça:
> NSString * mot_lettre = nil;
> ...



Diable, tout cela marche en effet.
Joie. Merci la tortue.


----------



## Anonyme (4 Mai 2004)

Manu, j'ai essayé de faire ton appli.

J'ai presque fini, mais je n'arrive pas à m'en sortir avec textDidChange...
J'ai du mal à comprendre le principe manu. Cette méthode surveille si on tape du texte au fur et à mesure mais je ne sais pas comment l'appeler.

D'autre part, je ne pige pas pourquoi on pourrait pas faire un setStringValue à un NSTextView... d'après ce que me dit un warning dans le awakeFromNib.


----------



## Anonyme (4 Mai 2004)

Ah, ça y est, ça marche !






Je mets le code, il y a peut-être des choses qui marchent mais qui ne sont pas logiques :






En fait, j'ai pas bien pigé l'histoire du setDelegate:self
On informe que l'objet à surveiller en permanence est texteSaisi ?
Et à quoi sert le self ? C'ets pour dire qu'il se trouve dans cette classe ?


----------



## Manu (4 Mai 2004)

En fait, j'ai pas bien pigé l'histoire du setDelegate:self
On informe que l'objet à surveiller en permanence est texteSaisi ?
Et à quoi sert le self ? C'ets pour dire qu'il se trouve dans cette classe ?  

[/QUOTE]

Saches que ton Controleur que tu as crée dans IB est un objet derivé de NSObject. Il est représenté dans IB sous la forme d'une brique quand tu l'instancie.
Pour bien piger Cocoa il faut comprendre le principe de délégation et celui de Notification.
Un objet de type View est un élément d'interface donc à tout moment son aspet peut changer. Ce changement peut influencer celui des autres éléments c'est à dire d'autres objets. c'est pour cela que beaucoup d'objets de Application kit ont des méthodes dites de délégué. Ces méthodes ont un nom connu comme textDidChange. A chaque fois que tu modifies le texte, la méthode textDidChange est exécutée. On dit en objet que l'objet textView envoie le message textDidChange à son délégué. ton textesais c'est ton objet textView et le [texteSaisi setDelegate:self] codé dans l'objet Controleur dit en fait que moi Counter (self) je suis l'objet délégué de texteSaisi. Donc à chaque fois que texteSaisi est modifié, en temps réel la méthode textDidchange de son délégué est exécuté.
On objet on dit que l'objet NSTextView quand il change, envoie à son délégué le message textDidChange.
Tu remrqueras une chose curieuse, a aucun moment tu n'appelles une de des méthodes de Controleur.


----------



## Manu (4 Mai 2004)

izostar a dit:
			
		

> D'autre part, je ne pige pas pourquoi on pourrait pas faire un setStringValue à un NSTextView... d'après ce que me dit un warning dans le awakeFromNib.



setStringValue n'est pas une méthode de NSTextView ni d'une des classes dont il hérite. (NSText,etc)


----------



## Anonyme (4 Mai 2004)

Oui, c'est ce que je me disais, mais je trouve pas cela logique.  On y entre du texte aussi... (mais je vais pas remttre en cause la conception des classes, j'ai que 5 jours de cocoa...).


----------



## Tiff (4 Mai 2004)

Manu
Quel intérêt (s'il y en a un) de coder [textsaisi setDelegate: self] plutôt que de passer par IB ?


----------



## mpergand (5 Mai 2004)

izostar a dit:
			
		

> Oui, c'est ce que je me disais, mais je trouve pas cela logique.  On y entre du texte aussi... (mais je vais pas remttre en cause la conception des classes, j'ai que 5 jours de cocoa...).



NSTextView n'est pas un NSControl et setStringValue est une méthode de NSControl.

NSTextView possède les méthodes string et setString (en fait de  NSText)


----------



## Tiff (5 Mai 2004)

En pratique, avec ma petite expérience, j'utilise NSTextView uniquement pour faire du "traitement de texte". Dans la plupart des cas, NSTextField est plus pratique, s'il ne s'agit que de partager une information avec le controleur. Mais il ne supporte pas, par exemple, les sauts à la ligne.

Pour être encore plus clair, je suis en train de taper un message dans un TextView ; alors que "Re: Quel livre pour apprendre cocoa ?" se trouve dans un TextField.


----------



## Manu (5 Mai 2004)

Tiff a dit:
			
		

> Manu
> Quel intérêt (s'il y en a un) de coder [textsaisi setDelegate: self] plutôt que de passer par IB ?



En fait je l'ai fait faire comme cela uniquement pour une raison pédagogique. pour pouvoir expliquer la notion de délégué. En effet sous IB on peut le faire. L'autre avantage d'après moi c'est que lors d'une maintenance de l'appli, on s'attache plus au code qu'aux connections réalisées sur IB qu'on peut facilement oubliées. 
En général j'utilise IB pour définir les outlets et actions. Mais avec le système des Bindings apportées par la version cocoa de Panther on fera beaucoup plus de choses sur IB pour diminuer sensiblement le fameux 'glue code' du Controller. Il faut noter que l'utilisation des bindings n'est pas nouvelle en effet elle est faite dans WebObjects depuis longtemps. C'est d'ailleurs ce qui fait sa force.


----------



## Anonyme (5 Mai 2004)

mpergand a dit:
			
		

> NSTextView n'est pas un NSControl et setStringValue est une méthode de NSControl.
> 
> NSTextView possèdent les méthodes string et setString (en fait de  NSText)



OK, ok, j'ai compris maintenant.


----------



## la tortue (5 Mai 2004)

Tiff a dit:
			
		

> En pratique, avec ma petite expérience, j'utilise NSTextView uniquement pour faire du "traitement de texte". Dans la plupart des cas, NSTextField est plus pratique, s'il ne s'agit que de partager une information avec le controleur. Mais il ne supporte pas, par exemple, les sauts à la ligne.
> 
> Pour être encore plus clair, je suis en train de taper un message dans un TextView ; alors que "Re: Quel livre pour apprendre cocoa ?" se trouve dans un TextField.



Attention, ce n'est pas tout à fait juste.
NSTextView sert principalement à éditer du texte stylé (NSAttributedString) avec une mise en page pouvant être complexe.

En revanche NSTextField est un NSControl avec une seule cellule NSTextFieldCell, qui utilise à son tour un NSTextView pour l'édition du texte qu'elle contient, quand le NSTextField devient "firstResponder" dans sa fenêtre. Ce NSTextView est souvent le même pour tous les petits bouts de texte par ci par là. C'est en réalité l'objet NSText qui est "fieldEditor" pour la fenêtre.
Le fonctionnement des NSTextField paraît plus simple que les NSTextView, mais c'est faux. 
	

	
	
		
		

		
		
	


	




NSTextField comme tous les principaux NSControl sert à éditer une "valeur" ici une chaîne de texte.

A+


----------



## Manu (5 Mai 2004)

izostar a dit:
			
		

> Oui, c'est ce que je me disais, mais je trouve pas cela logique.  On y entre du texte aussi... (mais je vais pas remttre en cause la conception des classes, j'ai que 5 jours de cocoa...).



Saches une chose importante. C'est que quand tu fais du cocoa, oublies ce que tu as fait auparavant et pense encore et toujours objet. le fait de pouoir mettre du texte dans un objet NSTextView ou un objet NSTextField, ne signifie en aucun cas que cela est fait en utilisant une même méthode setStringValue.
Développer en objet c'est faire ceci : J'ai un problème à résoudre, je le divise en tâches puis je me dis que chaque tâche sera exécutée par un objet. Seulement comme je fais du cocoa, mes objets je ne les invente pas je dois les créés à partir d'objets de2 Framework de Cocoa. Je vais donc dans les Frameworks Cocoa qui sont Foundation Kit et Application Kit pour faire 'mes courses' et trouver des objets prédéfinis. C'est exactement comme si tu bâtissais une maison. tu en fais le plan, les agencements etc. Le tout sur papier et tu fais tes courses en allant chercher les briques, des portes que tu assembles. C'est aussi comme un jeu de leggo.
D'ailleurs une application Cocoa n'est ni plus ni moins composée d'objets qui interagissent les uns par rapport aux autres en s'envoyant des messages.
La notion de délégation permet à deux objets qui 'se connaissent' (car l'un est délégué de l'autre) de communiquer. 
La notion de Notification par contre permet à deux objets qui ne savent rien l'un de l'autre de se communiquer. Pour cela il passent par un objet intermédiaire appelé NSNotificationCenter. Dans chaque appli Cocoa, en plus des objets de l'application, il existe également d'autres objets appelés default objects du runtime Cocoa qui fonctionnent pendant le déroulement de l'application. Le NotificationCenter en fait partie. L'instruction NSNotificationCenter *myNotif = [NSNotificationCenter defaultCenter] permet de le designer par le nom myNotif.


----------



## Tiff (5 Mai 2004)

Manu a dit:
			
		

> En fait je l'ai fait faire comme cela uniquement pour une raison pédagogique. pour pouvoir expliquer la notion de délégué. En effet sous IB on peut le faire. L'autre avantage d'après moi c'est que lors d'une maintenance de l'appli, on s'attache plus au code qu'aux connections réalisées sur IB qu'on peut facilement oubliées.
> En général j'utilise IB pour définir les outlets et actions. Mais avec le système des Bindings apportées par la version cocoa de Panther on fera beaucoup plus de choses sur IB pour diminuer sensiblement le fameux 'glue code' du Controller. Il faut noter que l'utilisation des bindings n'est pas nouvelle en effet elle est faite dans WebObjects depuis longtemps. C'est d'ailleurs ce qui fait sa force.


D'accord, donc tu penses que c'est tout de même un réflexe à prendre que de définir les delegate dans awakeFromNib ? Je viens de perdre une heure à chercher comment définir le delegate des Barres d'outils, qui ne sont pas dans IB, jusqu'à ce que je tombe sur [toolbar setDelegate:self].
Quant au bindings, je vais m'y remettre. Mais ce n'est pas encore très clair dans ma tête. Dilemme : perdre du temps à comprendre les bindings, où perdre du temps à taper le "gluecode" ? Par curiosité intellectuelle, je choisis les bindings, mais est-ce vraiment rentable ?

En ce qui concerne NSTextField et NSTextView, merci pour les précisions 
	

	
	
		
		

		
		
	


	




, je note tout ça dans un petit coin. Mais à mon niveau, je suis obligé, pour l'instant, de me faire des raccourcis pour la comprenette. Je ne maîtrise pas toutes les classes, même les plus utilisées.


----------



## Tiff (5 Mai 2004)

Manu a dit:
			
		

> Développer en objet c'est faire ceci : J'ai un problème à résoudre, je le divise en tâches puis je me dis que chaque tâche sera exécutée par un objet. Seulement comme je fais du cocoa, mes objets je ne les invente pas je dois les créés à partir d'objets de2 Framework de Cocoa. Je vais donc dans les Frameworks Cocoa qui sont Foundation Kit et Application Kit pour faire 'mes courses' et trouver des objets prédéfinis. C'est exactement comme si tu bâtissais une maison. tu en fais le plan, les agencements etc. Le tout sur papier et tu fais tes courses en allant chercher les briques, des portes que tu assembles. C'est aussi comme un jeu de leggo.



Effectivement, c'est comme ça que je fonctionne. Mais quelle perte de temps pour chercher les infos propres à chaque classe (doc intégrée (pas toujours à jour), doc sur site Apple, tutoriels Project:Omega). Il fut un temps où j'avais commencé à rédiger un petit recueil avec pour chaque classe , son intérêt dans une appli, ses méthodes principales, la façon de les utiliser. Mais quel boulot. Enfin, on n'a rien sans rien.


----------



## GilPINATEL (9 Mai 2004)

Salut!
Il vient de sortir la deuxième édition l'excellent bouquin d'Aaron Hillegass, Cocoa Programming for Mac OS X : il traite du développement sous Mac OS X.3 avec XCode (bindings, etc...).
http://www.awprofessional.com/title/0321213149&amp;aid=1E97B728-CF9F-417E-A7F0-95F70CF6D501
Cordialement,
Gil.


----------



## Tiff (9 Mai 2004)

Trop tard, ça y est j'ai (presque) compris les bindings. Je sens que je vais me créer quelques dizaines d'appli avec ça pour remplacer tous les fichiers AppleWorks tableurs et bases de données que j'utilise.

J'attendrai la version 3 : Cocoa programming for Tiger.


----------



## Anonyme (12 Mai 2004)

ça a l'ai fabuleux ces bindings.

Moi qui débute en cocoa, je pense qu'il vaut mieux que je m'en passe d'abord pour bien comprendre les mécanismes des tables et des données, non ?

Au fait, j'ai créé un forum que sur cocoa/objective-C avec des rubriques détaillés, on est un peu à l'étroit ici au milieu des autres langages et dans un seul forum.


----------



## Tiff (13 Mai 2004)

izostar a dit:
			
		

> ça a l'air fabuleux ces bindings.



Pour faire une appli simple, où n'apparaît qu'une seule TableView, sans lien avec les autres vues de la fenêtre, les bindings ne sont pas nécessaires. Mais dès qu'il y a d'autres TableView ou même TextField qui en dépendent, la mise à jour manuelle est très vite pénible : perte de temps à taper, risques de bugs. Avec les bindings, aucune question à se poser (à part : comment ça marche ?). On relit les objets entre eux via le ArrayController et tout roule. Je suppose néanmoins que si tu veux faire des choses un peu sophistiquées, il faudra coder un minimum. Mais je n'en suis pas encore là.



> Moi qui débute en cocoa, je pense qu'il vaut mieux que je m'en passe d'abord pour bien comprendre les mécanismes des tables et des données, non ?



Tout ce qui permet d'appréhender le fonctionnement interne de l'application te sera profitable à un moment ou à un autre. Je viens de relire Cocoa par la pratique après un an de placard, et (presque) tout me paraît évident maintenant.


----------

