Gestion des targets d'Xcode
denis_13
Membre
Bonsoir à tous,
je dois parfois travailler sur des projets â€customisés" dont les différents produits sont générés par des
"Targets" dans Xcode. Chaque projet est basé sur beaucoup de code commun mais l'aspect le nom de
l'Applie et les bundle ID sont différents.
Cela fonctionne, mais deux points ne sont particulièrement pas optimaux:
La génération de nouvelles targets (basé sur la duplication d'une target existante), car on doit éditer
beaucoup de fichier à la main (contenu et target membership)
Dans une moindre mesure l'ajout de certaines fonctionnalités au projet (par exemple quand on a besoin
de nouveaux frameworks, il faut les ajouter individuellement à chaque target).
Est il possible de â€scripter Xcode pour générer une nouvelles targets de manière un peu automatisée ?
par exemple si je duplique une target, renommer mon fichier info.plist de manière à ce qu'il ne s'appelle
plus blabla-info-copy.plist ou décider que certains XCassets ne fasse pas partit de la nouvelle target et
les remplacer par d'autres et de même pour d'autres fichiers (sources ou storyboard).
Par ailleurs l'usage de targets dans mon cas n'est peut-être pas la seule solution? mais je n'en connais pas d'autres.
Denis
Réponses
1) Cela te permettra de te prendre le chou à ajouter les nouveaux frameworks à la main pour chaque target que tu crées, CocoaPods s'en charge pour toi
2) Tu pourras à la fois utiliser CocoaPods pour importer des librairies tierces dans tous tes targets en une ligne, mais je te conseille aussi de l'utiliser pour aussi importer des "Development Pods", autrement dit découper ton code / projet en petits modules et créer un "Pod" pour ça histoire de bien l'isoler proprement... et dans ton Podfile, tu peux alors le référencer par "MonSuperModule1", :path => "Modules/MonSuperModule1" pour l'intégrer à ton projet en utilisant le code local.
Ainsi, plus besoin d'ajouter à chaque fois tes fichiers à tous tes targets, au risque d'en oublier un, etc. Tu ajoutes tes fichiers à ton module / Pod, et tous les Targets de ton appli principale sont liés à ton Pod / module donc en profiteront.
merci pour le conseil, ca a l'air en effet très intéressant, ben... beaucoup de lecture en perspective... ;-)
c'est un peu l'idée développée dans cet article ?
http://dev.hubspot.com/blog/architecting-a-large-ios-app-with-cocoapods
CocoaPods à la base est fait pour intégrer très facilement des librairies tierces dans ton appli, comme AFNetworking, MagicalRecord, OHHTTPStubs, et j'en passe.
Mais il peut aussi être utilisé pour intégrer des "librairies locales" ("Development Pods") que tu aurais créé localement, de sorte de découper ton applications en sub-apps / modules et intégrer le tout dans ton appli finale. Meilleure facilité de maintenance, meilleur découpage, plus de flexibilité...
C'est ce que semble expliquer en effet ton article (que je garde sous le coude d'ailleurs)
oui comme ils le font remarquer il faut commencer par pratiquer (sinon c'est assez intimidant...), il faut aussi que je regarde les scripts qui automatisent la génération de builds...