Projet Commun Console, Mac et iPhone
Ganzolo
Membre
Bonjour,
Je suis en train de faire un petit jeu de société. J'ai commencé par faire le moteur du jeu avec l'IA sans aucune interface donc je le fais en mode console j'ai choisit Foundation tools dans les Templates. Pour l'instant j'ai tout juste commencé le développement donc il me reste du temps.
Mais pensez-vous qu'il me sera possible par la suite d'ajouter a mon projet une interface Mac et iPhone et deux règles de compilations pour que dans mon projet il y ai les 3 exécutables?
Si oui est-ce facile, bien documenté? Parce que les rare fois où j'ai essayé de faire quelque chose de similaire j'ai recommencé un nouveau projet car je perdais trop de temps à chercher.
Merci d'avance
Je suis en train de faire un petit jeu de société. J'ai commencé par faire le moteur du jeu avec l'IA sans aucune interface donc je le fais en mode console j'ai choisit Foundation tools dans les Templates. Pour l'instant j'ai tout juste commencé le développement donc il me reste du temps.
Mais pensez-vous qu'il me sera possible par la suite d'ajouter a mon projet une interface Mac et iPhone et deux règles de compilations pour que dans mon projet il y ai les 3 exécutables?
Si oui est-ce facile, bien documenté? Parce que les rare fois où j'ai essayé de faire quelque chose de similaire j'ai recommencé un nouveau projet car je perdais trop de temps à chercher.
Merci d'avance
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est ce que je fais pour ma part.
Maintenant si tu envisages vraiment que tes futures interfaces graphiques soient par dessus ton "Foundation Tool", donc pilotent ton outil en ligne de commande (avec des NSTask), c'est jouable sous MacOSX mais pas sous iPhone qui ne peux pas avoir deux process de lancés en paralèle donc tu ne peux pas avoir une appli iPhone qui exécute des "commandes terminal" genre "Foundation Tool". D'ailleurs sous iPhone on n'a pas le droit d'utiliser non plus des librairies dynamiques, autre que celles du framework fourni par Apple bien sûr (pour des questions de politique de sécurité en fait)
Donc moi ce que je fais dans ces cas là c'est une librairie statique, que je crée et compile dans un projet, projet auquel tu peux rajouter à la limite pourquoi pas un "Target" supplémentaire, histoire d'avoir un "Target" pour builder ta librairie statique, et un "Target" pour builder ton Foundation Tool, ce dernier targer pouvant avoir une dépendance sur le target de ta lib statique (c'est à dire que Xcode va s'assurer de builder ta lib statique avant ton foundation tool).
Après pour rajouter un autre target genre interface graphique MacOSX, tu peux à la limite faire ça dans le même projet de la même manière en rajoutant un autre "Target" à ton projet, et en y incluant les bons fichiers source. Mais je trouve plus propre de créer alors un nouveau projet (de type Cocoa Application par exemple) et d'y faire glisser dessus (dans "Groups & Files") le projet qui contient ta lib, ce qui va te permettre de rajouter une dépendance sur cette lib à ton target de ta Cocoa Application, et de faire glisser aussi ta lib (et ses headers) dans ton projet Cocoa Application pour pouvoir linker avec et l'utiliser.
Avec cette technique propre tu te construit ainsi une "brique" fonctionnelle (ta lib, qui contient toute ton IA, ton moteur de jeu quoi) réutilisable ensuite quelle que soit l'interface graphique (ou ligne de commande) que tu mets par dessus. Et ensuite tu peux créer 3 exécutables (Foundation Tool, appli OSX, appli iPhone) qui vont chacun simplement utiliser cette "brique" (cette lib) et n'auront donc pas à recoder ton IA et ton moteur.
Et comme ça si tu mets à jour / modifies ton moteur (genre améliore ton IA, etc...) bah t'as juste à modifier le code de ta lib, et le reste se fait tout seul : quand tu vas recompiler tes 3 exécutables utilisant cette lib ils utiliseront du coup la nouvelle IA
Il y a juste deux ou trois trucs que je n'ai pas compris. Cette question de librairie, quel est la différence entre fabriquer une librairie (statique ou dynamique là vraiment je nage un peu :-\\) et avoir un ensemble de classes sous forme de fichiers dans le projet contenant les 3 targets?
Après concernant les projets, tu dis que tu trouves ça plus propre de créer un nouveau projet mais la seule différence entre tout dans le même projets (et donc 3 targets) et 3 projets différents, c'est juste que la première solution est une factorisation de la seconde?
Ainsi, quand tu construis ton IA, à l'aide disons de 20 fichiers .m + 20 fichiers .h par exemple :
- avec la solution de copier tous tes fichiers .h et .m dans tous tes projets utilisant cette IA, l'inconvénient premier est que ça fait 40 fichiers à maintenir, surtout si tu en fais des copies dans chaque projet utilisateur... va suivre les versions après, en plus :P. Et en plus le projet utilisateur de cette IA peut voir l'implémentation (les .m) et les headers privés éventuels (.h dont il n'a pas besoin pour utiliser l'IA dans son appli, mais qui sont juste là parce que tu as des classes internes dans ton projet qui fait l'IA, à vocation purement interne et pas à être utilisées par l'appli finale directement)
- avec la solution de faire une librairie pour encapsuler cette IA, l'avantage c'est que tu masques l'implémentation de ton code, donc si tu veux distribuer cette IA à d'autres personnes, tu peux le faire sans avoir peur qu'ils te modifient ton code pour le réutiliser ou qu'ils voient comment tu as implémenté telle ou telle chose (utile pour des questions de copyright par ex), et en plus il faut que tu publies avec cette lib les headers pour l'utiliser (pour que l'appli qui intègre ton IA sache quelles fonctions elle a le droit d'appeler, en lisant le @interface des classes accessibles dans ta lib), mais tu peux ne fournir que les headers des classes publiques et ne pas fournir les .h des classes privées que tu utilises en interne dans ton IA. Et au final ça peut ne faire que disons 10 fichiers à publier (9 headers + la lib) car bien souvent l'API publique est bien plus légère que l'ensemble des headers privés nécessaires à ta lib.
Oui tout à fait... sauf que ça dépend si c'est factorisable, aussi. Quand c'est pour la même architecture (i386) et plateforme (Foundation Tool pour Mac, Cocoa Application pour Mac) ça va, tu peux en général tout mutualiser, faut juste faire gaffe aux réglages que tu mets dans chaque "target". Mais si tu rajoutes un target pour iPhone... ça commence à compliquer la configuration de Xcode et les réglages des targets pour out bien gérer.
Et puis l'avantage de faire un projet par application cible c'est surtout que tu as des templates tout faits pour ça, préconfigurés, et que si tu as fait ton IA dans une lib, t'as plus qu'à faire glisser ta lib dans le projet et basta... mais bon après rien ne t'empêche de tout mutualiser dans un projet unique, c'est juste que du coup ça sera à toi de faire les bons réglages pour chaque target, mais après tout c'est tout à fait faisable...
Je n'ai pas beaucoup d'expérience dans le développement. Mais cette technique est elle vraiment répandue? Est ce que par exemple les éditeurs de jeux vidéo encapsule leurs moteurs graphique ou même le moteur de jeu (l'automate qui assure le bon déroulement du scenario) dans des librairies?
Merci encore :-*
Bien sûr qu'elle est répandue. Tout projet de taille conséquente est découpé en librairies, ne serait-ce que parce que ce sont des équipes différentes qui travaillent sur des composants différents de l'application finale, et également parce qu'en pratique, certaines portions de code sont réutilisables et donc réutilisées dans de nombreux projets.
En ce moment, pour mon job, je travaille sur un système serveur de données boursières (sur PC windows, et systèmes Unix), avec une équipe située à l'étranger, et au total, on a découpé le projet en 5 librairies distinctes, certaines étant réutilisées par d'autres équipes sur d'autres projets.