1 projet, 2 applis
hdex
Membre
Salut à tous,
Je suis en train de faire une appli, et j'aimerai bien faire une version standard et une version allégée.
La version allégée serait quasi identique à la version standard à l'exception de 3 boutons que je veux rendre inaccessible.
J'avais pensé à faire 2 projets différents mais ça me semble faire compliqué alors que la majorité du code est identique.
Je cherche donc un moyen de faire ça dans un projet XCode unique. Je suppose qu'il faut utiliser plusieurs "targets"/"executable" (éventuellement avec des #ifdef) mais j'avoue ne pas bien saisir comment faire.
Quelqu'un aurait des infos ?
Je suis en train de faire une appli, et j'aimerai bien faire une version standard et une version allégée.
La version allégée serait quasi identique à la version standard à l'exception de 3 boutons que je veux rendre inaccessible.
J'avais pensé à faire 2 projets différents mais ça me semble faire compliqué alors que la majorité du code est identique.
Je cherche donc un moyen de faire ça dans un projet XCode unique. Je suppose qu'il faut utiliser plusieurs "targets"/"executable" (éventuellement avec des #ifdef) mais j'avoue ne pas bien saisir comment faire.
Quelqu'un aurait des infos ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Car j'ai pas envie de perdre du temps à te faire une réponse, alors que quelqu'un sur un autre site aura perdu le même temps !
.
Mais celui-ci est uniquement consacré à Objective-C & Cocoa.
Surtout qu'en plus tu donnes la réponse dans la question, et que la doc Xcode est assez claire sur ce point...
Ca m'est arrivé par le passé aussi. Des fois, on bloque sur un truc et on veut la réponse vite vite et on multiplie les chances...
Ca m'est passé mais ça me rappelle mes débuts...
a+
Ce qui est évident aux uns ne l'est pas forcément pour les autres.
Non non, Hdex est toujours le bienvenue avec ses questions ici.
[size=6pt]Il faut juste comprendre que les gens ici, ils sont bénévoles, ont une famille et un boulot.
Répondre à une question, c'est du temps pris sur la famille et le boulot.
Alors, multiposter pour augmenter ses chances de réponse car on est pressé, c'est un peu un manque de respect vis à vis de ces gens là .[/size]
.
Bien sûr, mais il y a une différence entre:
- Je pense qu'il faut aller dans cette direction, pouvez-vous m'expliquer?
et:
- J'ai essayé cette voie sur base de ce qui est marqué à cette adresse, et il y a une erreur de compilation que je ne comprends pas (cf. capture ci-jointe).
Dans le premier cas, j'interprète ça comme "j'ai la flemme de lire la doc, faites moi un résumé svp" et dans le second "j'ai essayé un truc mentionné dans une doc ou un tuto et je ne comprends pas mon erreur". Je trouve que le 1er cas est aussi une forme de manque de respect.
Si j'ai posé cette question de cette façon, c'était que j'avais justement lu la doc et que ça ne me semblait pas évident. Donc avant de m'embarquer dans la construction d'une usine à gaz, je cherchais une confirmation ou juste quelques retours d'experience.
Ma question était probablement mal posé. Comme indiqué par Renaud la doc Xcode explique comment créer des targets multiples avec plusieurs executables ... cela dit pour un débutant, la doc omet pas mal de détails (modif du creator code, du product name dans les options de compil ...).
La doc est plutot orienté "1 projet, 1 appli, plusieurs executables/framework".
La différence c'est mon besoin d'invidualiser les applis tout en partageant un code commun mais bon je vais continuer ma lecture de la doc.
Leçons apprises :
- Pas de multi-postes; même sur des sites différents
- questions plus précises
@+
Pour ce qui concerne le "lien" entre objective-cocoa et macbidouille, il n'est pas si fort que tu sembles le penser, il y a effectivement bru et quelques autres qui fréquentent régulièrement macbidouille, mais ce n'est pas la règle.
Ceci dit, maintentant que la "morale" a été faite, j'ai quand même été voir sur macbidouille pour voir ce qui a été dit, et comme la réponse est insuffisante à mon goût, je répondrai ici.
La solution de faire plusieurs targets est OK, mais je ne suis pas sûr que ce soit la meilleure dans le sens où tu aurais du rajouter de toute façon des build rules, qui suffisent en elles-mêmes à faire des exécutables différents (mais avec des noms identiques, donc il te faudra éventuellement les renommer avant de les diffuser - et modifier le info.plist). Faire des targets est utile si tu ne veux pas faire ces petites modifs à la main, mais il faudra alors t'assurer que lorsque tu rajoutes un fichier il soit bien rajouté pour les 2 targets.
Donc le principe est simple:
- Tu doubles cliques sur l'icone du projet dans la liste de gauche. Dans le tab "Configurations", tu dupliques les 2 configurations (que tu nommes par exemple DebugFull et ReleaseFull).
- Tu vas dans le tab "Build" et tu fais la modif suivante dans les 2 configs que tu viens de créer:
Others C Flags: -DFULL
Dans tous tes fichiers, que ce soit des .h ou des .m tu peux alors mettre les fameux #ifdef/#endif. Tout ce que tu mettras entre ces directives sera ignoré à la compil si le paramètre FULL n'est pas défini.
[tt]#ifdef FULL
// du code spécifique à la version full
#endif[/tt]
[tt]#ifndef FULL
// du code spécifique à la light
#endif[/tt]
Le code que tu peux mettre peut être dans un .h des déclarations de variables, de méthodes, voire des déclarations de classe:
[tt]@interface MyClass : NSObject {
id var1;
#ifdef FULL
id varFull;
#else
id varLight;
#endif
}
#ifdef FULL
-(id)varFull
#endif[/tt]
Bon, la suite, je te laisse extrapoler.
PS: je le laisse le soin de mettre un lien sur macbidouille pour éviter que quelqu'un qui n'est que chez eux se donne la peine de dire la même chose que ce qui est dit ici.
Mon souci du moment, c'est que quand je demarre AppA j'ai un menu "AppA" avec en sous-menu "About AppA", "Quit AppA" etc ... Quand je demarre AppB j'ai bien un menu "AppB" mais les sous menu reste avec la mention AppA.
A priori, il n'existe pas de variable pour faire la modif automatiquement, genre "About $Product_Name" que je pourrais inclure dans le NIB, donc soit je duplique le fichier mainmenu.nib pour AppB, soit je fais des modif du menu dans le code.
L'une et l'autre solution fonctionne mais j'aimerai avoir votre avis sur ce qui est le plus "propre" en particulier quand je commencerai a localiser les applis ?
Encore merci de votre aide ...
Suffisante pour le laisser un peu chercher lui mêmeÂ
Ou plutôt dans "Preprocessor Macros" sans le -D ([GCC_PREPROCESSOR_DEFINITIONS, -D]), mais bon, ça ne change pas grand chose...
On peut même introduire des changements mineurs d'interface en ajoutant des boutons manuellement par exemple... (ou mieux, en insérant des vues toutes faites).
Ce qu'il ne faut pas dire c'est que la vraie raison du post ici est de générer un peu de trafic vers ce site à partir de macbidouille, apparamment c'est réussi Mais bon, vu la teneur "moraliste" de ce post, ce n'était peut-être pas une bonne idée :P
Juste, je ne le trouvais plus en fait.
Les targets multiples sont plus propres, te permettent d'utiliser des fichiers différents suivant les versions, mais il faut pas oublier pour chaque fichier que tu ajoutes de l'inclure pour les 2 targets. Mais dans tous les cas, ça ne te dispense pas de devoir créer des build rules différentes. Utiliser des fichiers différents peut être un bien ou un mal: ça complique la maintenance, donc à ta place je privilégierais un maximum de fichiers communs, et pour les nibs prévoir qu'ils puissent être modifiés par code (donc par exemple rajouter quelques outlets).
Non, c'est réussi, je viens de m'inscrire aux notifications de pas mal de forums d'ici
Comme j'adore Cocoa, je me suis dit "pourquoi pas, je peux apporter des choses et en apprendre"Â
Surtout qu'il y a des niveaux technique impressionnants ici ! (pour l'instant j'ai repéré bru qui a l'air bien calé sur les fonctions non documentées  :o)
Fais attention de ne pas t'y tromper, il est calé aussi sur les fonctions documentées!
Je m'en doute bien