[Débutant] Xcode 4 : fichiers de base. Explications ?

MacArthurEU

Membre enregistré
27 Août 2010
6
0
Salutations !

Je me mets enfin à l'Objective-C et à Cocoa... Mais là n'est pas la question (pourtant habituelle).
Non, ma question est plus basique...

Lorsque je crée un nouveau projet d'application dans Xcode 4, certains fichiers de base se créent. Normal, comme avec tout IDE digne de ce nom.

165218itest.png


Mais...

  1. A quoi sert la classe "AppDelegate" ? Peut-on la supprimer ?
  2. A quoi correspond le dossier "Supporting Files" ? Peut-on y sortir le "main.m" à la racine du projet ?
  3. Qu'est-ce que le "-Prifix.pch" ? Peut-on le supprimer ?
  4. Lorsque je crée une nouvelle classe, où dois-je mettre mes fichiers .h et .m ? Dans un nouveau dossier "classes", à la racine ou dans "Supporting Files" (à côté du "main.m") ?
Ça me perturbe un peu vu que la plupart des cours/tutos sont encore pour la version 3 de Xcode qui proposait une structure de départ différente et plus "dénudée".

Merci d'avance !
 
Dernière édition:
Ça me perturbe un peu vu que la plupart des cours/tutos sont encore pour la version 3 de Xcode qui proposait une structure de départ différente et plus "dénudée".
Je ne sais pas ce que tu as lu comme "cours" mais vu les questions posées ils ne devaient pas être terribles :D:D:D

plist : properties list
pch : pre compiled headers
strings : chaînes de caractères pour l'internationalisation
credits : credits

Tous ces fichiers existent déjà dans les projets créés avec Xcode 3. Le rangement dans les groupes importe peu. Et cela est aussi valable pour ton code, tu peux bien le mettre où tu veux dans ton projet.
 
Je ne sais pas ce que tu as lu comme "cours" mais vu les questions posées ils ne devaient pas être terribles :D:D:D
Oui, je sais, j'en ai presque honte. :siffle:

Mais qui dit "débutant", dit "simplification et stricte minimum"...

Objective-C/Cocoa ne me posent pas trop de problèmes (ayant déjà de bonnes bases en prog' OO).
Mais commencer avec un nouvel IDE (qui plus est dans une nouvelle version assez changeante par rapport aux cours/tutos/livres déjà rédigés), c'est moins évident.

Sinon, je viens de remarquer que ce détail est expliqué sur le SdZ : http://www.siteduzero.com/tutoriel-3-455547-presentation-de-cocoa-et-de-ses-outils.html#ss_part_2

Merci bien quoi qu'il en soit ! ;)
 
:p OO est cocoa... si tu ne comprends pas l'ApplicationDelegate :rolleyes: ca doit etre beau ta vision de Cocoa tient!

meme avec un outil de type de command-line en cocoa par exemple un deamon, tu pourrais envisager t'utiliser la Class Application comme main Looper en effet un objet recevant des messages "tournant" dans son thread.

l'application delegate et l'objet callback de ce looper, le nom est assez clair, c'est un des principes de base de toute la structure du model objet de cocoa et en particulier l'AppKit et cela depuis maintenant 20ans!


http://en.wikipedia.org/wiki/Precompiled_header, si tu ne veux pas precompiler les frameworks de base change le dans les propritées de ton target, mais c'est totalement idiot.

les groupes et sous groupes de xcode ne correspondent pas toujours a ton systeme de fichier, mais je te conseil fortement de les "synchroniser". voir images 1 et 2 et le conseil fonctionne pour tout type de language voir image 3,

mais par exemple j'utilise deux types de convention:

quand j'ecris une librairie ou une application, puis les differentes conventions ISO pour coder: pure unix-like-c, c++, obj-c chose qui n'est pas imposée en Europe et qui est une tres mauvaise habitude ne pas coder suivant ces standards dans toutes les Entreprises bien "connues" c'est la premiere question qui tombe et je peux te dire qu'il regarde ton "style" et de toutes les facons c'est obligatoire par exemple le franc-anglais... tu peux te dire que ca va etre tendue pour avoir le job, tabulation representée par le charactere tabulation, c'est a la preference du coder de choisir la taille du charactere tab est en aucun cas au code de le porter ecetera.

c'est pour cela que je le repete souvant: "le style" des noms, un bonne Anglais, ce n'est pas pour etre chiant c'est juste que volontairement vous vous fermez des portes et vous vous enfermez vous meme et vous ne pourrez jamais devenir un coder.


Et ces Entreprises ont bien raison: quand tu as des millions de ligne de code voir milliards a maintenir et a faire evoluer avec des milliers de personnes tu ne peux pas vivre dans un gros bordel ou tous les porcos ajoutent leur caca ou alors tu fais faillite un code degueulasse un model pauvre a beaucoup plus d'impacte que sa "degueulasseté"
 
Dernière édition: