Développement et Jaguar

[molgow]

Je ne sais pas si on va pouvoir me répondre. Mais est-ce qu'un programme en Cocoa (ou éventuellement Carbon) risque de ne pas fonctionner sur Mac OS 10.2, s'il a été compilé à partir d'une version antérieure ?

Ou plus simplement, est-ce que mes petites applis que j'ai réalisée sous 10.1.x et qui fonctionnent parfaitement, risquent de ne plus fonctionner sur 10.2 ? Ma question est peut-être stupide, mais j'ai parfois entendu des commentaires sur les bétas de Jaguar qui relatait le disfonctionnement de certaines applications...

 

[Membre supprimé 2]

Oui, bien sur qu'il y a ce risque, comme c'est le cas a chaque maj majeure... Mais ca ne doit pas pouvoir poser trop de problemes pour corriger les erreurs, amha

 

[omiossec]

Cela vas sans doute dépendre de tes applications. Des appels au systeme, library .... Pour une application relativement simple je ne pense pas mais pour le reste ?

 

[molgow]

C'est bien ce que je pensais. J'espère juste que les développeurs d'applications de renommées, ne s'amuseront pas à faire des applications uniquement pour > 10.2 (comme ça a été le cas pour certaines applications au passage à la 10.1, qui elle était "gratuite", donc ça posait moins de problème).

Pour ma part, je me fais pas de soucis, j'en suis encore à recommencer pour la 10e fois une petite application toute bête, juste pour tenter d'améliorer ma conception des objets ("Model View Controller" me pose encore qqs problèmes d'ailleurs /ubbthreads/http://forums.macg.co/vbulletin/images/smiliesold/laugh.gif

 

[Manu]

En principe une appli cocoa ne pose pas de problèmes suite à une évolution du système. Ce qui se passe au contraire c'est qu'on s'apperçoit souvent que des fonctions que l'on a développées sont proposées sous forme de méthodes supplémentaires qui rendent la vie plus facile. A chaque fois que j'ai modifié une appli cocoa c'est pour la rendre plus performante et plus facile en utilisant les nouveaus apports du système.
Peux tu expliquer exactement ce qui te pose problème dans le concept Model View controller? car il me semble que c'est un concept assez facile d'approche pour développer.
A+

 

[molgow]

Ben en fait, si j'ai bien compris ce MVC, depuis le View, je n'ai pas accès aux données du controller, juste ?

Si c'est juste, ça me pose des problèmes, car pour mettre à jour l'affichage j'ai souvent besoin des "données" contenues dans mon controller.

Si ce que j'ai dit est complétement faux, c'est que j'ai encore moins compris que je ne le croyais /ubbthreads/http://forums.macg.co/vbulletin/images/smiliesold/confused.gif

Pour être plus précis, j'essaie de développé un tout petit "jeu", ou plutôt, une petite image (bonhomme) qui puisse ce déplacer dans ma fenêtre. Donc, j'enregistre la position de ce bonhomme dans mon Controller, et puis dans mon View je le dessine, mais pour le dessiner, je dois connaître sa position, qui se trouve dans le Controller, lequel je n'ai pas accès depuis la View. Voilà en gros, ce que j'ai compris (ou pas compris? de MVC.

Si tu as le courage de m'expliquer brièvement comment faire "comme il faut", c'est avec plaisir que je lirais tes commentaires!

 

[Manu]

En effet t'es assez loin du compte. Pour comprendre le conceptt MVC il faut d'abord que tu t'habitues à l'idée que tu fais de l'orienté objet.
Lorsque tu veux développer une appli, t'as en fait une idée de ce à quoi elle va ressembler. C'est à dire ce qu'elle est censée faire.
La View c'est en fait l'interface graphique de ton appli. C'est par elle que l'utilisateur réagit avec ton appli.
On se sert d'Interface Builder pour dessiner la VIEW.
En se servant des éléments fournis dans les pallettes d'IB.
Ton interface contient des boutons, des zones de saisie éventuellement etc.
Lorsque l'utilisateur appuie sur un bouton, il doit déclencher une action. C'est ce qu'on appelle une IBaction.
Les zones de saisie sont destinée a afficher ou saisir des infos. C'est ce qu'on appelle des IBoutlet (IB pour Interface Builder)
Seulement ces actions et ces outlets il faut les définir quelque part.
C'est dans l'objet CONTROLLER que tu le fais. Cet objet en général a pour attributs les IBoutlets + certains autres, et pour methodes des IBaction.
Ainsi pour toute interface TOTO, tu as un TOTOCONTROLLER. Donc à une View tu attaches un controller.
On se sert d'interface Builder pour créer un controller, que l'on instancie ensuite. Il est souvent repésenté dans Interface Builder par une brique dans la fenêtre IB.
Le MODEL de MVC provient de la modelisation de ton appli. ou plutôt de ton idée de départ.
La modélisation consiste à définir ce qu'on appelle des objets de base ou objet métier.
Dans ton exemple, on peut définir comme objet model une Personne.
C'est ton objet de base.
Ses atributs sont sa couleur, etc. comme méthodes, tu définiras comment il se dessine, comment il s'efface, une metode pour fournir ses coordonnées, etc.
Ta View sera ton interface ou fenetre. Le controller pour décrire les actions déclenchées par l'utilisateur.
D'ailleurs dans ton cas, une instance de Personne sera un attribut de ton controller. Il représente l'image d'une personne dans ta fenetre.
pour avoir les coordonnées de ton image, il s'uffit d'appeler sa méthode.
Le fait de déplacer ton image consiste à lui envoyer 2 messages (pour exécuter deux méthode de l'objet personne) . Un pour lui demander de s'effacer, et un pour lui demander de se dessiner à l'endroit défini par les coordonnées que tu lui passe en paramètres.
Si ta fenetre est assez complexe tu peux également en faire un objet model appelé FenetreJeu par exemple un objet de type View (qui sait se dessiner etc..)
Dans ce cas ton interface sera une fenétre vide. Son Controller aura pour attributs des instances de personne et de FenetreJeu.
A l"exécution, le controller envoi un message à l'objet FenetreJeu de se dessiner en lui founnissant le contexte ( la taille de la fenetre par exemple).
J"espère que j"ai été ckair.

A°

 

[PowerMike]

Ça fait toujours plaisir de savoir qu'on s'est planté .. ça évite d'avoir à chercher dans le mauvais sens. Pauvre Manu ça fait dix milles fois qu'il nous reprend les uns après les autres /ubbthreads/http://forums.macg.co/vbulletin/images/smiliesold/smile.gif
Merci Manu, à chaque fois je relis et je comprends encore mieux. Un jour je serais un vrai développuer Cocoa /ubbthreads/http://forums.macg.co/vbulletin/images/smiliesold/smile.gif
Faudriat qu'on pense peut-être à faire un récapitulatif de tout ça. tu en as déjà fait pour WebObjects non ?
on verra tout ça.

 

[molgow]

Ouahh... MERCI beaucoup Manu ! /ubbthreads/http://forums.macg.co/vbulletin/images/smiliesold/smile.gif

Juste encore une question, je crois que ce que je n'ai pas bien compris, c'est comment intéragir, entre mon View et son Controller. Est-ce que View a un outlet qui pointe sur Controller, ou est-ce l'inverse ? ou les deux (il me semble que c'est pas possible dans les deux sens?)

Parce que lorsque l'utilisateur clique (par exemple) dans mon View, le traitement de cette action "doit" se faire dans mon Controller non ?

 

[Manu]

Alors mon gars t'as déjà utilisé interface Builder? En fait une fois que tu as instancié ton controller et qu'il apparait dans la fenêtre IB, tu fais des liaisons entre les outlets de ta view et celui de ton controller ainsi que entre le bouton et ton IBaction en tirant des traits dans le sens du parcours des données entre les deux.
Par exemple pour lier un bouton à une action, tu positionnes ta souris sur le bouton et en maintenant la souris appuyée,et la touche pomme, tu deplace ta souris vers le controller, ceci est matérialisé par un trait. En lachant, une fenëtre Inspecteur s'ouvre en t'affichant les IBaction que tu as définies dans le controller.
Tu choisis la bonne IBaction et tu valides en appuyant sur le bouton Connect.
Pour une outlet tu fais la même chose mais en partant du controller vers l'outlet view.
Tu peux d'aiileurs une fois terminer tester ton interface.
C'est toute la magie d'Interface Builder.
Ensuite tu demandes à IB de générer les sources .h et .m de ton controller. Il n'y a plus qu'à entrer le code nécessaire.
Tu peux pour commencer mettre du code bidon pour tester le comportement de ton interface.
Par contre n'oublie surtout pas que quand tu crées une view (appelée couramment une custom view) , il y a des méthodes que tu dois implémenter car elles sont souvent appelées soit pour redessiner, etc. Pour cela potasse bien la classe NSView. Quand on débute en cocoa c'est le truc le plus 'chiant'. Une fois qu'on a l'habitude c'est évident.
Je ne répèterais jamais assez qu'avec cocoa on fait de l'orienté objet. Cela veut dire que l'on adopte un mode de programmation plus proche du monde réel.
C'est pourquoi il faut absolument mettre to idée sur papier et raisonner en objets. Poses-toi la question De quels objets j'ai besoin pour mon appli.
Dans ton cas par exemple. T'as besoin de deux objets. Une personne et une scène.
La personne doit avoir toutes les méthodes décrivant son comportement dans le jeux (déplacement,etc). Et pour attributs sa forme etc.
Ta scàne peut être une vue représentant un espace vert avec des sentiers, des arbres, des lacs etc.
Elle doit avoir des methodes lui permettant d'afficher une partie de son contenu à l'intérieur d'une fenêtre dont tu lui passe les caract"ristiques (une structure NSRect).
Ainsi lorsque la personne se déplace, Tu lui envoies des messages de déplacement, ensuite tu envoie à la view de ta scène un message pour qu'elle se redessine dans une fenêtre que tu lui donneras en paramètre.
Le grand intérêt de modéliser (avoir des objets de base) comme une personne ou une scène, c'est que tu peux dans une autre appli les réutiliser.
Par exemple la personne tu peux en lui ajoutant quelques méthodes, en faire un tennisman.
En cocoa tu le fais en utilisant les catégories. (en fait tu fait appartenir ta personne à la catégorie tennisman).
C'est comme dans la vie réelle on fait d'une personne un tennisman on lui attribuant un comportement adhoc.
J'espère que tout ceci t'éclairera.
A+

 

[molgow]

Cool. Encore un grand merci pour tes explications.

J'ai bien compris le système des outlets dans IB. Mon problème est juste de faire ces outlets dans le bon sens et avec les bons objets. Mais je commence à croire, grâce à tes explications, que mes problèmes viennent du fait que je n'ai pas créé d'objets comme il faudrait. En fait, c'est "penser objet" qui me pose le plus de problème /ubbthreads/http://forums.macg.co/vbulletin/images/smiliesold/frown.gif

Je crois que je vais recommencer mon projet à zéro, en créant intelligemment plus d'objets. Pour l'instant je vais partir en vacances, mais dès mon retour, je te dirai si j'ai bien réussi à appliquer tes explications /ubbthreads/http://forums.macg.co/vbulletin/images/smiliesold/smile.gif

Merci encore!