[Gifour]

Mauvaise nouvelle pour tous Gifour essaie de se mettre à XCode et Interface Builder.
J'ai télécharger différents tutos pour me faire les dents.
Il se trouve que je butte tous au meme endroit. Il semblerait que dans la derniere version d'Xcode et IB (3,2,1) celle que j'utilise et que j'ai chargé sur le site apple certaines fenetres aient changées et je ne n'arrive pas à suivre les tutos. L'endroit où je bute à chaque fois est au moment de creer les connexions. Il semble que le contenu de la fenetre est changé Quand j'appele ma view identity le contenu n'est pas celui qu'on me decrit
voila une petie copie d'écran de ce que je devrais avoir et de ce que j'ai



Est ce que quelqu'un peu m'aider?


j'ai peur que cela soit la premiere d'une longue serie de questions..;

[Gifour]

Continuant mes essais j'ai trouvé un nouveau tuto avec la dernière version de Xcode et IB. j'ai tout repris et pense trouver quel était mon problème. A priori je déclare bien" mes éléments d'interface dans le code XCodes. Mais lorsque je les créer physiquement dans IB ils n'apparaissent pas dans l'inspecteur. Je devrais avoir une section "Outlets" dans ma fenêtre avec mes éléments. mais je ne l'ai pas.
Un problème de casse? Merci

[Go'Gaule]

Gifour, le 06 février 2010 - 16:33 , dit :

Citation

Continuant mes essais j'ai trouvé un nouveau tuto avec la dernière version de Xcode et IB. j'ai tout repris et pense trouver quel était mon problème. A priori je déclare bien" mes éléments d'interface dans le code XCodes. Mais lorsque je les créer physiquement dans IB ils n'apparaissent pas dans l'inspecteur. Je devrais avoir une section "Outlets" dans ma fenêtre avec mes éléments. mais je ne l'ai pas.
Un problème de casse? Merci

Bonsoir Gifour .
A tu pensé a approvisionner ta pharmacie en , .... et en ..... ! (La pub gratuite est interdite.)
Bon courage.
Cordialement.
Bravo pour ton puzzle .

Le meilleurs tuto : Cocoa par la pratique de A.Hillegass chez Eyrolles .

Ce message a été modifié par Go'Gaule - 06 February 2010 - 18:59 PM.

[AliGator]

Hello Gifour,

En effet la présentation des palettes a un peu changé dans les dernières versions de Xcode et IB.
Si tu cherches à voir la liste des Outlets de l'objet qui est sélectionné dans InterfaceBuilder, c'est maintenant dans l'onglet avec un rond bleu et une flèche blanche (la flèche symbolisant les "connexions" entre les objets, j'imagine).
Onglet de l'inspecteur que tu peux aussi avoir via le menu "Tools" > "Connections Inspector".
 IBOutletsActions-XCode321.png (49.67 Ko)
Nombre de téléchargements : 6

Ceci dit, perso je n'utilise jamais cet onglet. Je passe par le ctrl-clic plutôt.
En effet, un ctrl-clic (ou un clic droit) sur un objet dans IB t'affiche une petite palette flottante noire-translucide qui liste les connexions de et à cet objet, sur la même idée que l'onglet "Connexions" dans l'inspecteur.
 IBOutletsActions-FloatingPalette.png (51.02 Ko)
Nombre de téléchargements : 3

Si tu veux directement effectuer des connexions d'un objet à un autre, un drag & drop de l'objet source à l'objet destination tout en maintenant ctrl (un ctrl+clic+glisser, quoi) permet de connecter des objets. Mais si tu veux faire plusieurs connections d'affilée partant d'un même objet (par exemple connecter tous les IBOutlets de ton "File's Owner" à chacun des objets de ton interface auxquels ils doivent être associés), faire juste un ctrl-clic pour ouvrir la palette flottante noire, et ensuite pour chaque connexion, "tirer un fil" à partir du rond qui t'intéresse à droite dans la palette vers l'objet à relier.

[Gifour]

AliGator, le 07 février 2010 - 20:32 , dit :

Hello Gifour,

En effet la présentation des palettes a un peu changé dans les dernières versions de Xcode et IB.
Si tu cherches à voir la liste des Outlets de l'objet qui est sélectionné dans InterfaceBuilder, c'est maintenant dans l'onglet avec un rond bleu et une flèche blanche (la flèche symbolisant les "connexions" entre les objets, j'imagine).
Onglet de l'inspecteur que tu peux aussi avoir via le menu "Tools" > "Connections Inspector".
IBOutletsActions-XCode321.png

Ceci dit, perso je n'utilise jamais cet onglet. Je passe par le ctrl-clic plutôt.
En effet, un ctrl-clic (ou un clic droit) sur un objet dans IB t'affiche une petite palette flottante noire-translucide qui liste les connexions de et à cet objet, sur la même idée que l'onglet "Connexions" dans l'inspecteur.
IBOutletsActions-FloatingPalette.png

Si tu veux directement effectuer des connexions d'un objet à un autre, un drag & drop de l'objet source à l'objet destination tout en maintenant ctrl (un ctrl+clic+glisser, quoi) permet de connecter des objets. Mais si tu veux faire plusieurs connections d'affilée partant d'un même objet (par exemple connecter tous les IBOutlets de ton "File's Owner" à chacun des objets de ton interface auxquels ils doivent être associés), faire juste un ctrl-clic pour ouvrir la palette flottante noire, et ensuite pour chaque connexion, "tirer un fil" à partir du rond qui t'intéresse à droite dans la palette vers l'objet à relier.

Merci j'avais effectivement trouvé cette petite palette mais je ne savais pas comment m'en servir. Le problème que j'avais est que mes connexions n'apparaissait pas dans la palette alors que semble t il j'avais tout fait bien. Etrangement ce mation quand j'ai rouvert le projet mes outlets étaienr là. Je continue ma découverte.

[AliGator]

Petit truc tout con, mais faut penser à sauver ton .h

En fait en pratique ce qui se passe c'est que InterfaceBuilder "scanne" tes fichiers ".h" à la recherche des mots "IBOutlet" et "IBAction", pour pouvoir t'afficher ces connections. C'est grace à ces mots clés qu'il repère tes Outlets (qui ne sont que des variables visibles depuis IB, en fait, quand on y pense) et tes Actions.

Sauf que du coup... si tu rajoutes un IBOutlet (ou une IBAction) dans ton .h mais que tu fais pas un petit "Pomme-S", bah IB le voit pas C'est tout con, mais je me suis fait avoir 2 ou 3 fois Suffit de sauver le .h et retourner dans IB, et... ouf !
Et sinon si vraiment tu vois que IB n'arrive pas à détecter les IBOutlets et IBActions que tu rajoutes dans ton code / tes ".h", tu as toujours la possibilité de faire glisser-déposer le fichier ".h" dans ta fenêtre d'InterfaceBuilder pour le "forcer à le rescanner"

[Gifour]

Merci de ces explications. Voilà la suite de mes découvertes

Souhaitant partir sur de bonnes bases voilà ce que j'ai cru comprendre Merci de me corriger je vais surement dire des énormités.
Il y a donc deux logiciels Xcode et Interface Builder. Ce dernier intervenant lors de la création de l'interface et la connexion avec les différents éléments
Un projet XCode est lui composé d'un ensemble de fichiers.

Les deux fichiers intéressants sont le ".p" et le ".h"

Le ".h" sert à faire des déclarations qui permettront à l'interface et au code de faire la liaison . En gros on utilise un "élément" graphique ou une fonction que l'on place avec IB et que Xcode "connaitra" par la suite grâce à cette déclaration dans le ".h"


Le ".p" contient le code en lui même. C'est dans ce fichier que l'on place le code que l'on veut utiliser.
Pour résumer Dans IB je créé un bouton dans ma fenêtre. Dans l'action" de mon bouton je dis que je vais exécuter la fonction "bouger"

[AliGator]

Heu dans l'ensemble c'est bien ça mais...
- d'où tu sors ce ".p" ? Ce sont des ".m" en Objective-C, pas des ".p", pour le code (au même titre que ce sont des ".c" en C, ".cpp" en C++", ".mm" en Objective-C++, ...)
- En effet les ".h" ne font que déclarer ce qui existe et que tu peux faire (liste des méthodes, des variables de ta classe, ...) mais le code pour implémenter ces méthodes est dans le ".m". Ce ".h" est entre autres utilisé par IB quand tu fais ton interface, pour qu'il sache à quelles IBActions il peut relier par exemple les actions des boutons, ou quels IBOutlets sont déclarés et peuvent être reliés aux objets d'interface. Mais ça ne sert pas qu'à ça
- En effet, si tu utilises par exemple une classe Voiture, qui décrit les propriétés d'une voiture et les actions qu'elle peut effectuer / ses méthodes), si après tu veux utiliser la classe Voiture dans une autre classe, disons Personne, pour rajouter une propriété (une variable d'instance) "Voiture* voiturePrincipale" à cette classe Personne... Il faut que le compilo sache à ce moment ce qu'est une "Voiture".
Pour cela, tu importes le ".h" de ta classe (donc "Voiture.h") ce qui va permettre au compilateur de lire ce ".h" et donc de savoir les propriétés d'une voiture et les actions qu'on peut faire avec une voiture. A ce stade il se fiche de savoir comment il faut faire pour démarrer une voiture par exemple, il veut juste savoir que l'on peut démarrer une voiture, pour autoriser ton autres classe (ici "Personne") à appeler la méthode "demarre" de ton objet Voiture ([voiturePrincipale demarre].
Savoir en quoi consister l'action de démarrer la voiture (le code de cette méthode) il verra plus tard.
Par contre si tu fais [voiturePrincipale vole] il va savoir te remonter une erreur car il aura vu en lisant "Voiture.h" qu'une voiture ne sait pas voler.


Donc en résumé le .h décrit une classe (fichier de déclaration, tu déclares les propriétés/variables d'instance de ta classe ainsi que le nom (la "signature") des méthodes de la classe), pour que tous les autres (le reste de ton programme, les autres classes) sachent ce que tu peux faire. C'est donc ce que tu veux exposer au reste du monde (ça correspond à l'API de ta classe). Le ".m" contient le code, lui.

Comme ça, si tu récupères un petit ensemble de classes sur le net ou d'un pote, genre une classe qui te permet disons d'appliquer des effets sur une image par exemple... bah même toi en tant qu'utilisateur de la classe, tu n'as pas besoin de savoir comment ça a été codé ni de comprendre la complexité du code de ce truc que tu as récupéré, de capter les algorithmes de traitement d'image de 3km... toi t'as juste besoin de savoir comment utiliser la classe, donc quelles sont les noms et paramètres des méthodes que tu dois appeler pour utiliser cette classe. Et pour ça tu n'as besoin que de lire le ".h" des fichiers que t'as passé ton pote (ou que tu as récupéré sur le net), pas besoin d'éplucher le .m qui fait 50x plus de lignes !

[Amarok II]

[edit]Lien supprimé par Ali, à garder privé stp Nico[/edit]



(non, mais j'ai rien dit moi !)

allez, je sais , c'est par là

Ce message a été modifié par AliGator - 08 February 2010 - 17:40 PM.

[AliGator]

Ouais bah dit rien
D'autant que ce lien je t'avais demandé de le garder privé, petit malin

(D'ailleurs, tu peux le supprimer de ton site stp ? J'attend mon MacMini d'ici à fin février pour me faire un bon environnement pour ça, mais ça restera interne et privé dans un premier temps, j'ai pas réfléchi à la licence sous laquelle j'allais ouvrir ça etc)

[Gifour]

AliGator, le 08 février 2010 - 15:06 , dit :

Heu dans l'ensemble c'est bien ça mais...
- d'où tu sors ce ".p" ? Ce sont des ".m" en Objective-C, pas des ".p", pour le code (au même titre que ce sont des ".c" en C, ".cpp" en C++", ".mm" en Objective-C++, ...)

C'était pourtant le matin j'avais pas encore picolé.....

En fait la classe ressemble à la notion de Plugin. C'est du code que tu rajoutes au tien pour lequel tu n'as pas besoin de savoir comment qua marche ou qui te demanderais trop longtemps à développer.
J'en suis à comprendre à quoi sert le delegate. Finalement se n'est pas si compliqué que ça. (Mes problemes d'outlets venaient bien betement d'un PommeS)

[AliGator]

La notion de "delegate" n'est pas bien sorcier : c'est juste un objet que tu informes quant aux différents événements que fait ta classe en gros.

Par exemple pour un textField (champ où tu peux saisir du texte), tu peux associer un objet quelconque à ce champ comme étant son "delegate" (le "délégué", en français, quoi), et ce delegate va être informé quand le TextField va rentrer en mode édition (quand l'utilisateur aura cliqué dedans), quand du texte va être inséré (l'utilisateur aura tapé ou copié/collé du texte), quand l'utilisateur cherche à sortir du mode édition (en cliquant autre part ou via la touche tabulation) -- pour te permettre par exemple de valider ce qu'il a saisi et ne pas l'autoriser à sortir du champ s'il a mal tapé, etc. -- et tout ça.

Donc le delegate d'un objet A, c'est un objet B qui va être informé de ce que fait l'objet A : l'objet A va envoyer des messages à son delegate à des moments précis de son existance, pour informer ce delegate de certains événements. C'est aussi utilisé quand l'objet A souhaite demander des infos pour connaître son comportement.

Par exemple un TextField va appeler la méthode "textFieldShouldReturn" sur son delegate lorsque l'utilisateur tape la touche Return dans ce TextField, et le delegate a donc juste à implémenter cette méthode pour retourner YES ou NO pour indiquer au textField en question ce qu'il doit en faire, s'il doit accepter la touche return ou pas. Tu peux dans ce cas juste mettre return YES comme code et la touche Return sera toujours acceptée... ou tu peux faire du code qui va vérifier des trucs, mettre des "if" et autre, pour retourner "YES" dans certains cas, et "NO" dans d'autres... et tu peux profiter de cette méthode (dont tu sais qu'elle est appellée quand l'utilisateur a tapé la touche Return) pour faire d'autres choses, comme valider le texte rentré dans le champ, passer au champ suivant, etc.

Le principe est tout bête, mais ça évite de devoir sous-classer la classe TextField juste pour modifier le code interne de la méthode textFieldShouldReturn : là c'est le delegate qui implémente ce code et dis au textField qui le demande comment réagir. Donc on délègue l'exécution de ce bout de code à exécuter quand l'utilisateur tape Return au delegate, plutôt que ce soit le TextField lui-même qui traite le problème. D'où le nom du concept.

[Gifour]

Ayant progressé dans XCode je me rend compte de la nécessité de maitriser correctement Objective C et XCode. Je pense que la meilleure solution pour moi serait de suivre une formation pour m'appendre à maitriser ces différents outils. Ma question est donc toute simple : avez vous un centre de formation ou quelqu'un à me conseiller?
Je ne connais rien en C ou C++ Il faut donc que je puisse commencer par le B A Ba..

[AliGator]

Je n'ai pas de réponse quant à la formation, mais il y a de très bons bouquins qui existent. Cela te conviendrait-il (être autodidacte avec un bouquin plutôt qu'avoir un formateur à qui tu peux poser des quesitons) ?
Cela te gêne-t-il de bosser avec des bouquins en anglais, ou est-ce un handicap pour toi ?

[Gifour]

AliGator, le 11 février 2010 - 15:42 , dit :

Cela te gêne-t-il de bosser avec des bouquins en anglais, ou est-ce un handicap pour toi ?

Le mot est juste....Je ne peux plus lire. C'est pour cela qu'il me faudrait quelqu'un plutôt que des livres. A la limite s'il s'agit d'audio livres cela conviendrait mais je ne penses pas qu'ils existent sous cette forme malheureusement. De plus 'avantage du formateur est que d'une part il peut te corriger aussitôt et que tu peux lui poser des questions Ce qui est moins facile avec un livre

[AliGator]

Bah tu peux poser des questions au livre... mais je doute qu'il te répondra

[Gifour]

AliGator, le 11 février 2010 - 16:59 , dit :

Bah tu peux poser des questions au livre... mais je doute qu'il te répondra

Effectivement j'en ai trouvé mais leurs réponses sont assez simples : la poule, la vache, le canard....

[BorakLeRouge]

Gifour, le 11 février 2010 - 18:04 , dit :

la poule, la vache, le canard....

C'est au moins de la nourriture à croco tout ça

[Gifour]

BorakLeRouge, le 11 février 2010 - 18:10 , dit :

C'est au moins de la nourriture à croco tout ça

Effectivement j'en avais trouvé qui faisaient pouet-pouet ou PimPom mais j'ai pensé que cela interesserait moins le sac à mains...

[Gifour]

Redevenons sérieux. Pour l'intialisation je pense que j'aurais besoin d'un envirronement de developpement puis je me servir directement de XCode ou dois je me procurer un autre logiciel code xarrior, Borland ????

[Go'Gaule]

Gifour , bonjour . Les autres je boude .

J'ai cherché pendant plusieurs mois un ou une formateur ou trice ..(ou un stage .)
Pas trouvé .
Très rare , donc cher . Peu de personne maitrises le Cocoa et ceux qui savent sont beaucoup trop occupés .
Bonne chance .
Cordialement.

[AliGator]

Oui pour les outils Xcode suffit.
Ou plus exactement, les "Developer Tools" suffisent : c'est à dire le pack d'outils de développement Apple, donc Xcode + Interface Builder... + quelques autres outils pour faire du profilage de code (genre voir dans quelles parties de ton code tu perds du temps, ou quelles parties de ton code prennent beaucoup de mémoire, si tu veux optimiser tout ça, ...) mais qui eux ne te serviront pas tous les jours et que bien plus tard dans les phases "avancées" (genre optimisation).

En pratique tous les jours tu n'as besoin que de Xcode et IB.

Point de Borland ou CodeWarrior, qui sont d'autres IDE* d'autres éditeurs, et qui existaient avant que Xcode ne sorte, plutôt pour faire du C ou du C++, mais maintenant qu'on a Xcode ces deux derniers sont un peu passés aux oubliettes.


*IDE = Environnement de Développement Intégré en français dans le texte, donc l'outil qui te permet de gérer ton projet, regrouper et organiser les fichiers de code de ton appli, faire l'autocomplétion, compiler ton code, le déboguer et faire du pas à pas, etc.

[Gifour]

Go'Gaule, le 12 février 2010 - 10:11 , dit :

Gifour , bonjour . Les autres je boude .

J'ai cherché pendant plusieurs mois un ou une formateur ou trice ..(ou un stage .)
Pas trouvé .
Très rare , donc cher . Peu de personne maitrises le Cocoa et ceux qui savent sont beaucoup trop occupés .
Bonne chance .
Cordialement.

Pas si cher que ça... Que 2500 euros pour 3 jours....

Je suis trompé c'était 3500 euros les 3 jours

Ce message a été modifié par Gifour - 12 February 2010 - 13:33 PM.

[Go'Gaule]

Bonjour .
Gifour :
J'ai retrouvé les codes sources des exemples du livre Cocoa par la pratique de A. Hillegass .
Si tu est intéressé je te les transmets .
Cordialement.