Importer un header dans tout le projet
JegnuX
Membre
Bonjour
Voilà je me demandais quelle était la meilleure solution pour importer un header dans tout le projet ?
Par exemple les headers de mes categories, j'aimerais l'importer à un seul endroit, et comme ça XCode ne me met pas de warning si jamais j'ai pas importé ma categorie dans une de mes classe.
Pour le moment je les met dans mon _Prefix.pch en dessous de Fondation et UIKit (donc dans le "ifdef __OBJC__") et ça marche bien, mais après je sais pas si c'est la bonne solution ou si y'en a pas des meilleures. Je me dis que peut-être que le prefix est utilisé pour autre chose et que c'est pas judicieux de les y mettre dedans. C'est donc pourquoi je souhaiterais une confirmation de votre part :-)
Ah et au passage, j'aurais besoin d'un petit rappel sur les headers justement : dans un .m normalement je ne dois importer que le .h correspondant à l'interface de la classe c'est bien ça ? si j'ai besoin d'autres classes ou frameworks je dois les mettre dans le .h ou bien on s'en fou et je peux mettre direct dans le .m ?
Donc voilà si vous pouviez me redonner quelques rappels de base ça serait cool ^^ Merci
Voilà je me demandais quelle était la meilleure solution pour importer un header dans tout le projet ?
Par exemple les headers de mes categories, j'aimerais l'importer à un seul endroit, et comme ça XCode ne me met pas de warning si jamais j'ai pas importé ma categorie dans une de mes classe.
Pour le moment je les met dans mon _Prefix.pch en dessous de Fondation et UIKit (donc dans le "ifdef __OBJC__") et ça marche bien, mais après je sais pas si c'est la bonne solution ou si y'en a pas des meilleures. Je me dis que peut-être que le prefix est utilisé pour autre chose et que c'est pas judicieux de les y mettre dedans. C'est donc pourquoi je souhaiterais une confirmation de votre part :-)
Ah et au passage, j'aurais besoin d'un petit rappel sur les headers justement : dans un .m normalement je ne dois importer que le .h correspondant à l'interface de la classe c'est bien ça ? si j'ai besoin d'autres classes ou frameworks je dois les mettre dans le .h ou bien on s'en fou et je peux mettre direct dans le .m ?
Donc voilà si vous pouviez me redonner quelques rappels de base ça serait cool ^^ Merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Il faut juste savoir si tu importe XX.framework dans Tata.h, et que dans Toto.h tu importes que Tata.h, tu auras aussi XX.framework importé dans Toto.
Si tu veux que ça ne sorte pas de Toto, tu importes XX.framework dans le .m
Je veux dire, si j'importe titi.h dans tata.h, et que j'importe tata.h dans toto.h, est-ce que ça importe aussi titi.h dans toto.h ?
sinon je pense que tu voulais dire "Si tu veux que ça ne sorte pas de Tata, tu importes XX.framework dans le .m"
C'est ça d'utiliser des noms débiles
Pour l'inclusion des .h dans les .h ou dans les .m tout va dépendre du cas.
Pour la quasi totalité des situation j'inclus tout dans le .m, le .h ne contiens que Cocoa/Cocoa.h, si par exemple j'utilise une iVar de type Employee je rajoute un @class Employee avant le @interface dans le .h.
Cela évite les références croisé et inclusion de .h un peut partout (bien que ce ne soit pas génant, #import protège de lui même les .h). Je trouve ça plus propre et c'est une bonne habitude lorsqu'on travail sur des framework.
Le seul cas où je trouve intéressant d'inclure dans le .h c'est lorsqu'une méthode renverra un objet non inclus dans Cocoa/Cocoa.h, si j'ai en return un objet de type Employee, alors je met l'inclusion dans le .h
La bonne pratique est de se contenter de déclarer l'existence des choses dans le .h, et leur définition complète dans le .m. Comme tu le fais pour les méthodes où tu ne mets que leur signature dans le .h et leur code dans le .m, il est donc de bon aloi de ne faire que déclarer que la classe Machin existe " avec une ligne "@class Machin" dans le .h " parce que tu as besoin que le compilateur ait connaissance de l'existence de ladite classe (pour pas qu'il gueule en disant "hé tu utilises un "Machin" mais ça n'existe pas", en gros tu lui dis "t'inquiète, je te dis que Machin ça existe, je t'expliquerai plus tard " dans un .m " ce que c'est au juste). Et de n'importer toute la classe et donc son API complète (savoir quelles méthodes du as le droit d'appeler, etc) dans le .m qui en a besoin.
En gros faire un #import du .h de la classe Machin que quand tu as besoin d'utiliser explicitement ce qui est dans le .h (appeler une méthode de la classe Machin, déclarée dans le dit .h, appel de méthode dont tu n'as besoin que dans le .m de ta classe qui utilise Machin).
Après évidemment, d'une part c'est pas un drame de faire le #import dans le .h même si ça suffirait de le faire dans le .m et se contenter de "@class"; dans le .h". Et beaucoup de monde le fait comme ça d'ailleurs, par flemme ou méconnaissance de la directive @class ou autre. C'est juste que c'est un peu inutile et que ça peut avoir des effets de bords sur le temps de compilation (genre si tu changes des lignes dans Machin.h, au moment de compiler il va recompiler tous les fichiers qui importent Machin.h, donc tous les .h où tu as mis #import "Machin.h"... et tous les ".m" de ces classes puisque ces .m importent leur ".h" correspondant qui viendra à son tour d'être recompilé, etc... bref ça recompile des trucs pour rien, c'est pas un drame, mais c'est un peu bête :P
Puisque, dans Prefix.pch, Apple importe par défaut :
Pourquoi dans chaque nouvelle classe créée par défaut, Apple écrit :
ou
selon le type de classe ?
Simple double précaution ?