Learning Cocoa

steg

Membre actif
14 Février 2000
278
0
Petit Conseil à tout ce qui veulent apprendre à programmer avec cocoa, Learning Cocoa chez O'reilly est vraiment bien fait...
310 francs francais chez le monde en tique www.lmet.fr
 
M'ac outé moins cher sur Amazon, enfin je l'ai pas encore reçu ... seulment la semaine prochaine. J4ai intérêt à avoir un bon dico aussi parce que les métaphores en anglais c'est pas toujours gagné !
 
J'aimerais bien avoir l'avis de tous ceux qui ont achete ce bouquin. Ca vaut vraiment le coup?
 
Ben l'anglais utilise beaucoup d'images et des fois c'est dur de trouver la signification.

Exemple type du truc pas simple à comprendre : paradigm Model-View-Controller. J'ai du lire "paradigm" dans la doc pour savoir que le mot français paradigme existe aussi. Mais la définition du mot anglais : flou total.
 
oui oui et la première fois que j'ai cherché la définition de ce mot j'ai trouvé un truc comme ça :

"Pour rendre compte de l'allure discontinue du progrès dans la connaissance, Thomas Kuhn avançait une notion qui n'a cessé de faire fortune, sans doute à cause du flou qui entoure son usage : celle de paradigme. Selon une perspective sociologique, héritée du médecin polonais Ludwik Fleck, il désignait par là les règles admises et intériorisées comme «normes» par la communauté scientifique, à un moment donné de son histoire, pour délimiter et problématiser les «faits » qu'elle juge dignes d'étude.
Kuhn montrait que l'attachement de la communauté scientifique à «son» paradigme se paie souvent d'une certaine imprécision des concepts et d'entorses à la rigueur déductive dans l'élaboration et la mise en œuvre des théories...."

De quoi laisser rêveur non ??!!
wink.gif

Pour ma part ce jour là, j'était pas plus avancé... Heureusement qu'il existe des dictionnaires accessibles aux humains
grin.gif


Tout ca pour dire qu'un bouquin en anglais c'est bien mais le rendement est tout de même meilleurs si il est en français...

A+
 
je dirais que je préfère parfois les livres en anglais parce qu'on intègre plus rapidement la terminologie du sujet en question.

puisque de toutes façons, des docs spécialisées ne seront jamais disponibles en français, on passe parfois trop de temps à essayer de chercher les correspondances entre les mots qu'on a lu en français et maintenant ceux de la doc en anglais.

un thread, une instance, un layout, une affectation

A force de "switcher" d'une langue à l'autre, on fume vite du ciboulo.
 
Je suis tout à fait d'accord il vaut mieux integrer les mots en anglais. Le problème est lorsqu'on ne voit pas du tout à quoi se mot peut correspondre il met arriver de lire des docs du début à la fin en comprennant grosso modo mais il me manquait le sens "du" mot qui était le plus important. Et après c'est sûr tout devient clair !
 
Pour les refractaires a l'english :

je m'étais renseigné auprès de O'reilly france concernant l'édition de "learning cocoa". Ils m'avaient dis a l'époque (le bouquin n'était pas encore sorti) qu'une traduction en frenchy était envisagée.

Quand ils m'ont averti de la dispo du livre ce mois-ci, je les ai rappelé pour avoir confirmation de la traduc : elle est bien prévue, mais pas avant le début 2002 (il leur faut environ 6 mois pour les traducs).

Ca fait trop tard pour moi (j'ai donc le bouquin depuis une quinzaine), mais pour ceux qui peuvent attendre, ca vaut le coup.

Pour les autres, par contre, le bouquin ne sera vraiment utile que si vous n'avez pas passé les tutor. d'apple (de Currency Converter à Travel advisor).

Pour ceux qui connaissent deja les NSTableView, NSMatrix, NSNotificationCenter et consort, le livre ne sera pas d'un grand interet.

Pour ceux qui cherchent à comprendre le fonctionnement des classes principales d'OS X, le livre est très bien expliqué.
 
Au fait PM toi qui demandais la doc NeXT. Le bouquin learning cocoa reprend à la sauce OS X la doc NeXT Discovering OpenStep.

A+
 
Il est vrai que le livre est interessant. A mon avis (je me base sur mon expérience personnelle) pour apprendre cocoa il faut se dire que développer une application c'est comme bâtir une maison, il faut savoir quels sont les outils mis à disposition pour mener à bien le projet, ensuite savoir comment les utiliser pour aboutir au résultat escompté.

Dans notre cas les outils sous Cocoa se présentent sous la forme de deux frameworks.

Foundation Kit et Application Kit.

Avant de commencer à les utiliser il faut savoir ce qu'ils contiennent et à quoi ils servent.

Cocoa est un environnement de développement orienté objet. Ce qui veut dire qu'il faut toujours raisonner objet quand on utilise cet environnement.

Foundation Kit rassemble sous forme d'objets les éléments que l'on trouve dans un OS ou dans un programme.
Les chaines de caractères (NSString), les nombres (NSNumber), les données sous forme structurées (NSSet, NSArray, etc) ou non (NSData), les process (NSTask), les tthreads (NSThread), les applications (NSApplication), les fichiers (NSFileHandle), etc.

Application Kit rassemble les objets de l'interface graphique tels les fenêtres (NSWindows), les boutons (NSButton), etc.

L'avantage d'avoir des objets c'est que l'on dispose des interfaces de haut niveau pour utiliser ces objets et leur faire faire des choses relativement complexes, qui auraient demandé plusieurs jours de développement.

Des 2 frameworks Application KIT est très riche. pas seulement parce qu'il a plus d'objets mais surtout ce que certains de ces objets signifient. Par exemple les NSControl, les NSCell, etc;. ces classes dites abstraites sont très importantes.
A travers la relation de certains objets notamment NSResponder qui est la classe père de pas mal de classes comme NSWindows, etc, Application Kit implémente un mécanisme de gestion des évènements assez sophistiqué. Par exemple le principe du target/action que vous faites 'aveuglément' sous Interface Builder par ctrl tiret entre 2 objets puis connection.
Application Kit regroupe aussi à travers les classes NStextView, NSLayoutManager et NSTextStorage un mécanisme de gestion de texte très sophistiqué.
Bref Lisez bien la doc sur les Frameworks pour bien comprendre ce qu'ils renferment et surtout ce qu(ils permettent de faire.
Ce n'est que comme cela que vous pourrer les utiiliser efficacement.
Learning cocoa fournit des exemples c'est bien beau. Mais quand tu veux développer une petite appli qui n'a rien à voir avec leus exemples tu ne sais toujours pas par où commencer.

La prochaine fois je vous donnerai une idée de la meilleure façon de raisonner quand on veut développer une appli sous cocoa.

Salut.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
Il est vrai que le livre est interessant. A mon avis (je me base sur mon expérience personnelle) pour apprendre cocoa il faut se dire que développer une application c'est comme bâtir une maison, il faut savoir quels sont les outils mis à disposition pour mener à bien le projet, ensuite savoir comment les utiliser pour aboutir au résultat escompté.
<HR></BLOCKQUOTE>

Ok et pour ceux qui sont vraiment interessés mais qui devront poser des congés pour pouvoir s'y mettre, existe-t-il des cours accélérés ??
wink.gif


A+
 
Je ne sais pas ce que tu entends par cours accélérés. Je pense justement qu'il ne faut rien accéléré du tout. Il y a tout juste certains automatismes à avoir.

Comme je l'ai dit, normalement avec les apis fournis dans cocoa tout développeur doit pouvoir s"en tirer.

Voyez-vous il y a un principe qui est utilisé pour tout développement dans OS X pour rendre les choses très aisées au programmeur.

En effet Apple a fait de sorte que lorsqu'il existe une démarche commune pour développer un type d'applications, Apple fournit les ressources communes nécessaires. Le développeur ne se préocupant que d'implémenter la partie de son appli qui se différencie de celle des autres. Sachant ce principe, lorsque vous devez résoudre un problème (base de départ d'une appli), partez de l'hypothèse qu'il existe dans les frameworks une classe entière qui résoud votre problème.
Si cette classe n'existe pas, essayez de décomposer votre problème en petits problèmes et posez vous la même question pour chaque petit problème et ainsi de suite.

Vous arriverez fatalement à un moment où vous constaterez 2 choses.
1- il existe bien une classe ou plusieurs classes qui résolvent mon petit problème.
2 - quleques classes permettent de résoudre une partie de mon problème.
dans ce dernier cas je doit en utilisant lcertaines classes et en utilisant le principe d'héritage, de, créer une classe plus rixhe qui résoud la partie manquante et ainsi de suite.
Pour rendre cette démarche plus facile, Apple a classifié les classes de ses frameworks en plusieurs domaines d'utilisation.
D'autre part ne perdez pas de vue que les frameworks renferment un certain nombre de paradigmes (PM ça te dis qque chose?) comme la délégation et la notification qui aident ENORMEMENT.

En effet quand vous aurez l'habitude de développer sous cocoa vous comprendrez que ces notions sont d'une efficacité incroyable qui rendent les choses tellement plus faciles.

Dernièrement je vous ai soumis une petite appli avec comme interface une zone de saisie de texte et deux textfields affichant au fur et à mesure de ma saisie, l'un le nombre de cmots de mon texte et l'autre le dernier mot saisie.
Personne apparemment ne s'y est interessé.
Essayons de le résoudre.
Quel est mon problème? c'est de trouver un objet qui me permet de saisir du texte et qui dispose de méthodes me permettant l'un d"avoir le dernier mot du texte et l'autre le nombre de mots de mon texte.
Dans Application Kit l'objet me permettant de saisir du texte c'est NSTextView. mais ces 2 méthodes n'exitent pas.
Par contre dans la description de la classe NStextView qui hérite de NSText, je m'apperçoit qu'elle envoie à son délégué le message textDidChanged (décrit dans NSText), à chaque fois que je saisis un caractère.
Je peux donc saisir cette occasion pour faire mon traitement de compter les mots et trouver le dernier mot de mon texte.
Dans Interface Buider je crée mon interface avec dans ma fenêtre, en haut une textView et en bas deux textFields avec pour titre le premier le nombre de mots et le second le dernier mot.
Toujours dans IB je crée un controleur CompteurMots avec comme outlets leTexte (textView), nombreMots pour le 1er textField et dernierMot le second.
Je crée mon instance (brique dans la nib). Je fais mes connections outlet avec des traits allant de mon onjet controleur aux 3 outlets.
Ensuite et c'est IMPORTANT, je tire un trait de la textView vers le controlleur et je clique dans l'inspecteur de la textView sur delegate.
je fais donc de mon controlleur le délégué de l'objet leTexte.
Après la sauvegarde je crée les fichiers source de mon appli.
dans CompteurMots (nom de mon controlleur), je vais implémenter 2 méthodes.
- (void)awakeFromNib dans laquelle j'intialise mes fields.

[nombreMots setIntValue:0];
[dernierMot setStringValue;@" "];

avant la clause implémentation, je déclare une variable NSArray *zarray;

La seconde méthode sera

- (void)textDidChanged.
c'est dans cette méthode que je fais faire les traitement spour avoir le nobre de mots et le dernier mot.
Pour cela je dois d'abord traduire mon texte en chaine de caractères (NSString)
En effet je me suis apperçu que la classe NSString possède une méthode décrite dans doc comme suit :
- (NSArray *)componentsSeparatedByString
frown.gif
NSString *)separator

elle me permet de découper ma chaine de caractères en mots dans un objet de type NSArray.
D'autre part deux méthodes de NSArray count et lastObject me donnent le nombre de mots et le dernier mot respectivement. Et le tour est joué.

J'ai donc ;

- (void)textDidChange (NSNotification *)aNotification {
zarray=[[leTexte string] componentsSeparatedByString:mad:" "];
[nombreMots setIntValue;[zarray count]];
[dernierMot setStringValue:[zarray lastObject]];
}

Essayer de le tester.



[03 juillet 2001 : message édité par Manu]
 
Manu !

C'est pas qu'on ne s'y est pas intéressé. Peronnellement j'ai bookmarké la page pour pouvouir y revenir plus tard. J'ai pas tellement le temps en ce moment. Mais en plus c'est grâce à ton aide qq chose qui est tout à fait dans mes cordes.

Je confirme Cocoa, pour un esprit comme le mien qui a du mal à abstraire les choses, prend parfois son temps pour rentrer. Mais quand il est rentré : tala !!

et bien que je n'est toujours pas vraiment compris le mot Paradigme, j'ai compris les idées sous-jacentes aux différents mécanismes. Cocoa is great. Ça c'est sûr. Même si les crétins de la poste ne veulent pas monter 6 étages pour me le livrer Learning Cocoa ce qui m'oblige à alles à une poste bondée demain je le metriserais. Et ensuite à moi WebObjects !

Merci Manu pour ton aide. Autre question, peut-être connaîs-tu l'IOKit et pourrais m'apporter qq precisions.
 
Ok,

je ne cherche pas à précipiter les choses mais ayant (comme tout le monde) à travailler pour ramener de l'argent à la maison (et rembourser le prêt fait pour mon Tibook
wink.gif
) je peste et me sent frustré de ne pas pouvoir appréhender plus rapidement cocoa en général et EOF en particulier...

Bon si j'ai bien compris la notion de délégation représente (du moins dans l&#8217;exemple) un couplage que l'on pourrait considérer comme assez "fort".
Est-il possible d'inscrire un objet lors de son instanciation à un gestionnaire d'évènements (le NSResponder ou une de ces instances) et de gérer des interactions du même type mais sans avoir à créer de lien graphique ??
Ca permettrait de créer des briques logiciels quasi indépendantes gérant elles même leurs interactions propres...

A moins que ce soit justement le fait de choisir graphiquement le délégué de l'objet qui permette de rendre la gestion des évènements plus "pointue" en adressant uniquement les messages aux objets concernés d'ou une meilleur cohérence des interactions ??

J&#8217;ai bien compris le principe de la délégation mais j&#8217;avoue ne pas avoir encore complètement assimilé ou l&#8217;appliquer judicieusement dans le cadre d&#8217;un développement orienté objet&#8230;

A+
 
Interface builder ou autre outil graphique ne fait que de représenter graphiquement l'utilisation objets programmatiques.

De même qu'on peut changé dans le code l'action target d'un bouton on peut je pense changer tous les autres types de liens qui existent entre les objets.C'est ce qui fait effectivement tout le dynamisme des choses.

On clique sur un bouton. Dans l'action associé on fait une tache mais on change aussi l'état du bouton, son texte et son target. Lorsqu'on re-cliquera dessus ce sera une autre action qui sera executer.
 
En fait les gars qui avaient développé les apis cocoa, notamment les objets de l'Application Kit qui sont des éléments de l'interface graphique ont juste voulu trouver un moyen pour un objet d'avertir tous les autres objets lorsqu'il change de statut. En effet on part du principe que les objets agissent dans un environnement (interface graphique) dans lequel leurs actions peuvent avoir de l'influence sur les autres objets. C'est ainsi que dans cocoa il existe pour un objet 2 moyens lui permettant d'avertir un ou plusieurs autres objets à chaque fois qu'il change son état. d'ailleurs si jamais vous développer un élément de l'interface graphique, il faudra y penser. C'est fondamental autant pour vous que pour celui qui utilisera votre objet.
Les 2 moyens sont la délégation et la notification.

1 - la notification.

Toute application cooca dispose par défaut d'un objet appelé le NotifacationCenter. celui-ci est accessible par la commande ; [NSNotificationCenter defaultCenter]

Voici comment cela marche.

Supposons qu'un objet TOUL à chaque fois qu'il change de couleur emet une notification ChangementDeCouleur il postera cette notification au NotificationCenter par la commande :
[[NSNotificationCenter defaultCenter] postNotificationName:mad:"ChangementDeCouleur" object:self ];

tout objet B interessé par cette notification s'inscrit auprès du Notification Center par la commande :

[[NSNotificationCenter defaultCenter ] addObserver:self
selector:mad:selector(ToulAChangeDeCouleur: )
name:mad:"ChangementDeCouleur" object:TOUL];

Cela revient à dire au NotificationCenter; A chaqque fois que vous recevez de TOUL la notification ChangementDeCouleur, venez chez moi exécuter la méthode ToulAChangeDeCouleur.

Si dans la commande TOUL a une valeur nil la méthode sera exécutée lorsque le Notification center recevra la notification ChangementDeCouleur de tout objet.
Par contre si la notification a la valeur nil et que le paramètre objet à la valeur TOUL, la méthode est exécutée pour toutes les notifications de TOUL reçues par le Notification center.

Ce principe de notification est souvent utilisé pour synchroniser des actions asynchrones.
Eléguant n'est-ce-pas?

2 - La délégation

Dans ce cas, l'objet TOUL emet certes la notification mais celle-ci est destinée à tout objet s'inscrivant auprès de TOUL comme étant son délégué.

Dans ce cas TOUL définit une méthode toulChangeDeCouleur ayant comme paramètre la notification.
Tout délégué doit implémenter cette méthode qui est activée par TOUL par envoi de ce message à son délégué à chaque fois qu'il change de couleur.

En résumé :
Dans les deux cas, l'objet TOUL envoie une notification.
Dans le cas de la délégation il active la méthode qu'il impose à son délégué qu'il CONNAIT.
Dans le cas de la Notification, TOUL ne CONNAIT PAS celui qui recevra la notification.

Dans les deux cas les notifications envoyées tout comme les méthodes reçues par un objet sont connues car publiées.

En fait si vous lisez bien les classes sous cocoa, dans la dernière partie, on liste les notifications émises par les instances de la classe ainsi que les méthodes implémentées par un délégué.

Dans mon exercice, au lieu de matérialiser la délégation par la connection sous IB j'aurais pu dans awakeFromNib ajouter la commande [leTexte setDelegate:self];

Je vous assure que l'on arrive à faire des trucs ultra puissants avec ça c'est hallucinant.
j'ai par exemple en quelques lignes développé un objet qui surveille les messages d'une log et qui affiche certaines erreurs à l'écran et pour d'aures erreurs, l'objet poste à un administrateur un mail ou un message bip.
Quand je saurai comment mettre ces messages dans un synthétiseur vocal vous devinez ce qu'on peut faire?

NB : Ces principes ne s'appliquent pas uniquement à des objets d'interface. Par curiosité regardez de près dans Foundation Kit la classe NSFileHandle. Vous serez surpris...

Tenez pendant qu'on y est on va se marrer un peu....

Une variante du Copteur de mots. Supposant qu'on veuille que le calcul de compteur et dernier mot soit déclenché toutes les secondes comment on fait?
On suppose qu'on dispose d'un objet qui déclenche le traitement touts les secondes. Oh! miracle cet objet existe
c'est dans la Foundation Kit et c'est NSTimer. il agit en fait comme un chrono.

Dans ce cas plus de délégué la méthode textDidChange est remplace par calculMots. et dans awakeFromNib je crée un timer par la commande
NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:1
target:self
selector:mad:selector(calculMots)
userInfo:nil
repeats:YES];

Et le tour est joué.

Tout cela pour vous dire cherchez bien vous trouverez forcément ce qu'il vous faut.

Salut

[03 juillet 2001 : message édité par Manu]
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
tout objet B interessé par cette notification s'inscrit auprès du Notification Center par la commande :

[[NSNotificationCenter defaultCenter ] addObserver:self
selector:mad:selector(ToulAChangeDeCouleur: )
name:mad:"ChangementDeCouleur" object:TOUL];
<HR></BLOCKQUOTE>

Là, y a un truc que je pige pas : pourquoi on utilise pas une NSString pour name et non pas de nouveau un selector ?

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
NB : Ces principes ne s'appliquent pas uniquement à des objets d'interface. Par curiosité regardez de près dans Foundation Kit la classe NSFileHandle. Vous serez surpris...
Salut
<HR></BLOCKQUOTE>

À propos de fichiers, que faut-il mieux utiliser pour effectuer des opérations sur les fichiers (copie, déplacement, etc.)... NSWorkspace ou NSFileManager ?
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
Là, y a un truc que je pige pas : pourquoi on utilise pas une NSString pour name et non pas de nouveau un selector ?
<HR></BLOCKQUOTE>

Excusez, je veux dire... pourquoi on utilise une NSString pour name et non pas de nouveau un selector ?
 
Selector indique la méthode à exécuter chez le receveur alors que le name en NSString est le nom de la notification.
Tu remarqueras que selector se termine par ":" en effet le nom de la notification est passé en paramètre. Cela permet au receveur d'aiguiller ( par un case par exemple) dans la même méthode l'exécution d'un code par type d"évènement ou de notification.

D'autre part Le NSFileManager te permet de faire par programme ce que tu ferai sur un fichier en passant des commandes unix.

NSWorkspace pour la parie ouverture de fichier et diverses opérations que l'on fait sous le Finder. (execution d'appli,...)

[03 juillet 2001 : message édité par Manu]