1 projet, 2 applis

hdexhdex 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 ?

Réponses

  • BruBru Membre
    19:44 modifié #2
    J'attends que sur MacBidouille on te réponde...

    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 !

    .
  • hdexhdex Membre
    19:44 modifié #3
    Merci quand même et désolé si j'ai fait perdre du temps ... j'étais pas certains que les 2 communautés était si intiment lié.
  • muqaddarmuqaddar Administrateur
    19:44 modifié #4
    Oui, plusieurs membres sont sur les deux forums...
    Mais celui-ci est uniquement consacré à  Objective-C & Cocoa.
  • 19:44 modifié #5
    dans 1170971821:

    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 !


    Surtout qu'en plus tu donnes la réponse dans la question, et que la doc Xcode est assez claire sur ce point...
  • LeChatNoirLeChatNoir Membre, Modérateur
    19:44 modifié #6
    bouah, vous acharnez pas...
    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+
  • aranaudaranaud Membre
    19:44 modifié #7
    Le pauvre va pu oser posser une question.

    Ce qui est évident aux uns ne l'est pas forcément pour les autres.
  • BruBru Membre
    19:44 modifié #8
    dans 1171097682:

    Le pauvre va pu oser posser une question.


    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]

    .
  • 19:44 modifié #9
    dans 1171097682:

    Ce qui est évident aux uns ne l'est pas forcément pour les autres.


    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.
  • hdexhdex Membre
    février 2007 modifié #10
    Toutes mes excuses si mon message a été considéré comme un 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  :o :
    - Pas de multi-postes; même sur des sites différents
    - questions plus précises

    @+
  • février 2007 modifié #11
    à‰videmment au plus la question est précise, au mieux c'est. Mais pour ce qui me concerne, le plus important est de montrer qu'on a cherché la réponse avant de poser la question (il y en a qui ne se gênent pas pour considérer les forums pour des "moteurs de recherche intelligents", et ça m'agace), donc pour moi le plus important est de montrer qu'on a cherché avant de poser des questions (genre mentionner une doc (ou plusieurs docs) et montrer où ça coince).

    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.
  • hdexhdex Membre
    19:44 modifié #12
    Merci renaud, je teste ca des que possible. C'est vrai que le target multiples peuvent porter a confusion ... j'ai cherche pendant 10 minutes pourquoi mon appli n'affichait pas une valeur pour decouvrir que Xcode lancait l'autre appli qui n'avait pas ete recompile et ne contenait donc pas mes dernieres modifs.

    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 ... o:)
  • schlumschlum Membre
    février 2007 modifié #13
    dans 1171203690:

    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.

    Suffisante pour le laisser un peu chercher lui même  :)

    - 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

    Ou plutôt dans "Preprocessor Macros" sans le -D ([GCC_PREPROCESSOR_DEFINITIONS, -D]), mais bon, ça ne change pas grand chose...

    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.

    [...]


    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).
  • 19:44 modifié #14
    dans 1171260966:

    Suffisante pour le laisser un peu chercher lui même  :)

    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

    dans 1171260966:

    Ou plutôt dans "Preprocessor Macros" sans le -D ([GCC_PREPROCESSOR_DEFINITIONS, -D]), mais bon, ça ne change pas grand chose...

    Juste, je ne le trouvais plus en fait.

    dans 1171239246:

    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 ?


    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).
  • schlumschlum Membre
    février 2007 modifié #15
    dans 1171268828:

    dans 1171260966:

    Suffisante pour le laisser un peu chercher lui même  :)

    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

    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)
  • AntilogAntilog Membre
    19:44 modifié #16
    dans 1171270234:

    []
    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!  <3 <3
  • schlumschlum Membre
    19:44 modifié #17
    dans 1171276463:

    dans 1171270234:

    []
    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!  <3 <3 <br />

    Je m'en doute bien 
  • hdexhdex Membre
    19:44 modifié #18
    <3 Encore Merci  a tous <3 <br />J'avais pas pensé que ça pouvait augmenté le trafic depuis Macbidouille mais c'est une bonne idée  :)
Connectez-vous ou Inscrivez-vous pour répondre.