Quel livre pour apprendre cocoa ?

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...).
sick.gif

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.
 
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
zen.gif
, 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.
rose.gif
 
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.
crazy.gif
 
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.
laugh.gif
 
ç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.
wink.gif
 
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.