Bonjour, je suis Sanya - développeur iOS et dans cet article, je partagerai ma façon de résoudre les maux de tête qui se produisent lorsque vous travaillez sur un projet avec plusieurs cibles.
Je prévois la question "pourquoi avez-vous besoin de plusieurs cibles dans le projet, Sanya?" Je réponds: sur le projet où j'ai travaillé une fois, il y avait une cible liée au compte client, de sorte que:
- nous n'avions pas accès à ce compte;
- il n'était pas possible de générer des profils d'approvisionnement et des certificats de distribution;
- le pire était qu'il n'était pas possible d'ajouter de nouveaux appareils aux profils d'approvisionnement.
Ainsi, lors de l'achat de nouveaux appareils en studio, nous attendions toute une série de négociations avec le côté client pour les ajouter à votre compte et avoir l'opportunité de les tester.
La solution était évidente - créer une deuxième cible, qui sera similaire à la principale, mais qui aura un identifiant de bundle différent et qui sera complètement et complètement lié à notre compte studio. Aussitôt dit, aussitôt fait! Le deuxième objectif nous a permis de réaliser un développement à part entière quels que soient les développeurs du côté client, ce qui a sauvé le processus de développement plus d'une fois, par exemple, lorsque les développeurs du client ont supprimé tous nos appareils sur le profil d'approvisionnement de la cible principale et que nous ne pouvions pas exécuter l'application sur leurs appareils.
Plusieurs cibles peuvent toujours apparaître dans votre projet si nécessaire, par exemple:
- Collectez plusieurs applications à partir d'une base de code, mais avec des ressources différentes;
- Conservez plusieurs instances de l'application sur un seul appareil.
Mais le travail sur plusieurs cibles conduit à ses inconvénients, l'essentiel est la nécessité de contrôler strictement le processus d'ajout de nouveaux fichiers au projet. Ils sont tous les deux identiques, respectivement, lors de l'ajout d'un nouveau fichier au projet, il est nécessaire de cocher devant les deux cibles.
C'est très difficile lorsque l'on travaille dans une grande équipe à plusieurs niveaux, à la fois en compétences et en toute bonne foi.
Si vous ne suivez pas cette règle simple, après la fusion suivante, vous pouvez constater que l'une des cibles a cessé de collecter, et Xcode jure qu'il ne peut pas trouver l'une ou l'autre classe. Mais la chose la plus intéressante est que si quelqu'un n'a pas ajouté un fichier de Copy Bundle Resources aux deux cibles (par exemple, les cellules xib), vous ne pouvez trouver qu'une telle erreur dans l'exécution.
Après un autre problème avec la cible de débogage, nous avons décidé de contrôler la cohérence des cibles de script. Nous avons choisi le langage Ruby comme outil, car il possède un excellent bijou xcodeproj , qui est presque la norme pour les outils d'écriture pour le développement iOS (voir fastlane, generamba, etc.).
En conséquence, nous avons développé un script qui implémente la logique de travail suivante:
- le chemin d'accès au fichier de projet et les noms des cibles testées sont introduits dans l'entrée;
- sur le chemin du projet, le script trouve le projet lui-même;
- sélectionne les cibles souhaitées, en collecte les fichiers (Compiler les sources, Copier les ressources du bundle et les cadres);
- rechercher la différence entre les listes de fichiers;
- nous jetons les fichiers de notre liste blanche de cette différence. Par exemple, des fichiers avec des constantes qui diffèrent selon la cible (baseUrl, si vous décidez d'organiser le projet pour que les applications de différentes cibles accèdent à différents serveurs), ou des fichiers GoogleService-Info.plist, qui seront différents pour différentes cibles.
Si le script trouve une différence, nous avons un problème. Cela signifie que tel ou tel fichier / framework a été ajouté à une cible, mais pas ajouté à une autre.
Ainsi, le script vous permet de:
- assurez-vous que tous les fichiers des sources de compilation et des ressources de l'ensemble de copie ont été correctement ajoutés aux deux cibles;
- l'identité des listes de frameworks ajoutés est également vérifiée, ce qui est très important si votre projet a une architecture multi-modules;
- l'intégration du script sur Build Phase vous permettra d'identifier le problème avant même la phase de construction du projet;
- et si vous avez précédemment collecté les deux cibles sur CI pour cela, vous pouvez maintenant laisser l'assembly à une seule, réduisant de moitié le temps d'assemblage sur CI.
En cas d'erreur, dans Xcode vous pouvez observer le message suivant:
En cas de succès, vous trouverez des licornes:
Instructions détaillées pour l'ajout au projet, les paramètres, ainsi que l'exemple-projet dans le référentiel .
L'utilitaire résultant montre parfaitement que même en tant que développeur iOS, vous pouvez faire un petit morceau de créativité dans votre travail quotidien et faire de l'automatisation et des scripts qui vous simplifieront la vie!
Merci de votre attention!