Installer la même application 2 fois
Bonsoir !
Je souhaiterais installer plusieurs fois sur mon device l'application que je suis en train de faire.
L'idée, c'est d'avoir : la version de septembre, la version d'octobre, etc.
J'avais déjà cherché à résoudre ce problème et j'y étais arrivé, mais impossible de retrouver l'info !
Si quelqu'un pouvait m'aider, ce serait cool. En plus je pense que l'info intéressera d'autres lecteurs.
Merci !
Colas
EDIT : je crois que je converge !
multiple versions same app ios simulator
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Solution
- dupliquer le target existant pour créer un nouveau target qui ne servira qu'à créer des versions en plus
- pour ce nouveau target : aller dans Info.plis et changer le Bundle identifier et Bundle display name
Exemple :
Bundle identifier = com.moi.MonAppv2
Bundle display name = MonAppv2
Donc effectivement si tu veux plusieurs copies de ton application sur ton device (ou simulateur, d'ailleurs), il faut utiliser des Bundle Identifiers différents.
Une solution est de faire autant de Targets que de versions que tu veux, mais c'est sans doute un peu dommage car ça veut dire qu'à chaque fois que tu vas rajouter un fichier il faudra le rajouter dans les 2 Targets, et tes 2 Targets vont toujours est identiques (compiler les mêmes fichiers, avoir les mêmes Build Settings, etc), leur seule différence sera le BundleIdentifier du Info.plist. Tout dupliquer pour ne changer que ça, c'est un peu rude dans ton cas de figure spécifique.
Moi je serais toi, je créerai plutôt plusieurs Scheme, compilant tous le même Target, et c'est au niveau du Scheme que j'injecterai qqch dans mon Info.plist. Par exemple, dans le Scheme "BundleID1" mettre une "Pre-Action" de build qui va modifier ton Info.plist à la volée, et dans le Scheme "BundleID2" mette une "Pre-Action" de build similaire mais qui mettra un autre BundleID dans ton Info.plist. Un script utilisant un utilitaire comme "/usr/libexec/PlistBuddy" pour changer le Plist à la volée, par exemple.
Bon, en même temps, je ne suis pas sûr de comprendre vraiment ton besoin. Si tu veux vraiment avoir ton application de Septembre et ton application d'Octobre sur ton device, pourquoi faire et surtout maintenir 2 Targets (ou 2 Scheme) ? Ton code va évoluer entre le code de Septembre et celui d'Octobre, tu vas avoir de nouveaux fichiers, de nouvelles classes, modifier du code de certaines classes existantes... donc tout va bouger. Pas que le BundleIdentifier, mais aussi le code. Si tu recompiles ton Target "AppDeSeptembre" courant octobre, ça va inclure tes nouvelles modifications d'octobre dans ton code, donc ça ne correspondra plus du tout à ton app de septembre... Donc j'ai du mal à suivre ta logique du coup.
Ou alors tu compiles ton app de fin septembre une fois pour toutes, tu changes ton BundleID une fois pour toutes, et tu ne touches plus jamais à ton app de fin septembre et à son ancien BundleID, tu ne les recompiles plus pour ne pas risquer d'y introduire du nouveau code... mais j'ai tjs du mal à voir la logique de ce que tu veux appliquer au final.
Moi non plus je ne comprends pas trop ... le + simple et qui te prendra moins de 10 secondes à chaque fois ==> compresser ton dossier du projet tout simplement et l'appeler Version1_1_Date_15_09_14.zip par exemple si ton but est de garder une sauvegarde ... SI c'est juste pour tester si tu arrives à reproduire un bug de ta dernière version sur une ancienne ça peut paraà®tre logique ton truc mais généralement c'est pas la meilleur à chose à faire je pense.
Moi je ne prend pas la tête j'ai une version "qui marche" je la zip en gros et fur et à mesure j'ai mes clic & clac pour revenir en arrière si j'ai fait une catastrophe que je ne n'arrive pas à corriger
Tu tag ta version dans GIT et puis c'est tout. Tu continues à coder normalement ensuite.
Si un jour tu veux réinstaller ton ancienne version tu reviens au tag et tu refais Commande-R
Pourquoi se compliquer la vie et faire des targets et des scheme et des ZIP dans tous les sens ? Si tu veux garder un historique de tes versions, remonter en arrière dans l'historique si tu as cassé un truc, comparer 2 versions du même code à N mois d'écart, trouver automatiquement à quel moment dans l'historique de ton code tel trucs a commencé à merder... pour tout ça y'a GIT.
C'est fait pour, simple et puissant et transparent à utiliser pourquoi s'en priver ?
Je veux juste pouvoir comparer deux designs. Quand je veux charger une version à comparer, je change le targette, je modifie le plist et je compile.
Dans l'idéal, une version scriptée serait le mieux, mais bon tout le monde n'est pas architecte ici, y'en a qui bossent ;-) !!!
Si tu veux juste comparer 2 designs (2 applications qui ont le même code, évoluent en même temps au fur et à mesure que tu continues de coder " puisqu'un changement dans le code va prendre effet sur les 2 targets de ton projet au final " mais seul les assets graphiques changent) alors pourquoi pas, tu fais 2 targets avec exactement les mêmes fichiers qui sont compilés par les 2, à part pour le Assets.catalog où dans ce cas le target 1 link avec l'AssetsCatalog 1 et le target 2 avec l'autre AssetsCatalog (qui a des images du même nom, mais des graphismes différents).
Mais si tu as du code qui diffère réellement, les 2 versions A et B que tu veux comparer ayant du code différent (parce que ce n'est pas juste des images qui changent entre A et B mais aussi du code différent), les targets ne vont pas t'aider !!
---
Si c'est ça tu ferais mieux de ne garder qu'un seul target mais de faire 2 branches dans ton GIT, et basculer de l'une à l'autre quand tu veux comparer. Quitte à ce que dans une des 2 branches tu aies un BundleID donné dans ton Info.plist et dans l'autre branche tu en utilises un autre.
Comme ça au moins :
- Tes 2 branches seront autonomes, tu pourras changer le code dans l'une (pour adapter à ton nouveau design) sans impacter l'autre (pour garder l'ancien design inchangé et que les modifications du code d'un design n'aient pas d'impact sur l'autre design), les 2 versions seront indépendantes.
- Tu pourras aussi les installer toutes les 2 côte à côte sur ton iPhone (puisque tu leur auras mis des BundleID différents une fois pour toutes, pas besoin de targets différents ou de scripts ou quoi que ce soit tu l'auras changé à la main au début de ta branche et tu n'y touches plus après).
- Tu pourras basculer d'une version à l'autre (et donc d'un code à l'autre) d'un simple checkout GIT ("git checkout versionA" / "git checkout versionB") " ou d'un simple double-clic dans SourceTree (si tu préfères une interface graphique plutôt que le terminal pour GIT)
Vraiment avec tes 2 targets non seulement tu te compliques la vie (là ça va peut-être marcher au tout tout début tant que tu ne modifies rien ou presque dans ton code, mais quand tu vas devoir faire diverger le code pour la version B pour un truc spécifique au nouveau design sans que ça doive changer le design de la version A... galère) mais en plus ça ne va pas tenir longtemps, car dès que tu vas modifier ton code ou rajouter des fichiers, tes targets vont commencer à différer et tu vas vite oublier de mettre un fichier dans un target plutôt que l'autre.Si tu veux travailler sur (et comparer) 2 versions différentes de ton appli, pour tester ce que pourrait donner telle ou telle alternative, une branche GIT est ce qu'il te faut. C'est justement fait pour ça en plus !
Le seul point négatif (pour mon usage) c'est que je dois faire gaffe à toujours ajouter les fichiers aux deux targets.
Mais bon, je vais essayer de suivre tes conseils ! Je crois que j'ai un peu peur de brancher dans tous les sens pour merger ensuite car les rares fois où j'ai mergé deux branches où il y avait des conflits, j'ai trouvé ça galère (il refuse de merger et me parlait de trucs incompréhensible... HEAD et cie. --> je suis un SourceTreeGitter). Et puis, je code dans tous les sens, je ne fais pas une fonction à la fois. Dès que je pense ou vois une autre amélioration à faire, je la fais.
Bonne pratique Git : une modification fonctionnelle, une branche !
Si les branches contiennent trop de modifications, la probabilité de conflit sur une fusion augmente.
Mais alors, du coup, les targets sont encore moins adaptées a ton cas du coup en + !!!
Bah si sans problème, si tu ne comptes pas continuer à modifier tes anciennes versions et donc ne comptes pas faire évoluer les 2 en parallèle mais juste "marquer les étapes clés" pour pouvoir y revenir, un tag est amplement suffisant.
ça dépend ce que tu veux en fait ; vu que c'est pas très clair... À toi de voir et de nous dire.
GIT c'est payant ("enfin c'est ce que j'ai compris de github" après il doit y avoir des solution locale donc gratuite) sauf si tu veux partager ton code "en tant que code source" ouvert à tout téléchargement.
Alors je ne dirais pas beuuurk ^^' surtout que moi AU MOINS je peux accéder à ma sauvegarde sur mon disque dur même si je n'ai pas internet ... même si je suis dans un coin paumé de chez paumé ...
MAJ : Du coup je n'ai rien dit
Je m'étais référé à ça : https://github.com/pricing
Bon passons GIT est une bonne solution
- GIT fonctionne très bien en local. Pas besoin d'internet, on peut tout à fait faire des commit et des merge et tout ce qu'on veut sans réseau
- On peut avoir un repo GIT sur sa machine pour un projet sur lequel on bosse tout seul, il n'y a pas besoin forcément de passer par GitHub ou autre. D'ailleurs, quand on crée un nouveau projet avec Xcode, il nous propose une case à cocher pour faire du dossier projet un repo GIT (local sur notre Mac)
- C'est totalement gratuit d'utiliser GIT sur sa machine ou même entre collègues ou autre. Ce qui est payant ce sont les services en ligne permettant d'héberger des repos GIT (pour y avoir accès d'un peu n'importe où et n'importe quelle machine en partageant/clonant ton code sur le serveur web), mais GIT lui-même et utiliser GIT en local est gratuit
- Ce n'est pas parce qu'on travaille tout seul qu'on peut se passer de GIT. J'utilise GIT sur bcp de mes projets persos que je n'ai pourtant que sur mon Mac (pas sur GitHub) et sur lesquels je bosse tout seul. Ca me permet d'avoir un historique de mon code, remonter dans les versions de mon code et de mon app, comparer des versions, tout ça. Ca m'arrive de copier un GIT sur une clé USB pour l'amener sur un autre poste, continuer à faire des commits, puis le remettre sur mon poste aussi...
Bref, GIT de ce côté n'a rien à voir avec SVN : Il est décentralisé (pas de besoin absolu de serveur, ça marche très bien sur une machine), très facile à mettre en place, intégré à OSX, bcp plus friendly, permet les commits locaux (même sans internet), prend moins de place aussi (ne stocke que les diffs des versions, un peu comme TimeMachine, et pas une copie de chaque version comme le font les branches et tags de cette horreur de SVN...) et tout ça.Comparer GIT à SVN, c'est comme comparer un repas gastronomique avec un McDo bien gras : les 2 à la base servent à peu près à la même chose, à savoir te nourrir, mais bon, c'est quand même le jour et la nuit
Okok. Oui j'ai fait un tour en fait sur le site officiel puis sur Wiki puis j'ai lu que c'était une solutions free & open-source d'ou mes ratures au dessus ...
Ca à l'air cool au final
HS : Merci pour l'explication je pense que je vais me lancer dans GIT au passage de Yosemite
*d'ailleurs je te déconseille le menu SourceControl intégré à Xcode, ça a beau être Apple, pour le coup c'est pas super ergonomique leur interface dans gérer GIT dans Xcode pour les commits, merge, checkouts et tout. Autant leur mode Assistant pour voir les diffs, blame et logs en côte à côte est bien, mais pour les actions de commit, branches et toutes les actions via le menu, c'est pas tjs super visuel / clair. SourceTree est bien plus sympa pour ça et bien + visuel. Mais bon ça aussi on en a parlé dans d'autres sujets plein de fois déjà ...[/u]