Dans l'application Simulateur iPhone, tu as la possibilité de changer de device simulé à tout moment. Or, changer de simu provoque l'arrêt de l'application. Je t'assure que ça perturbe beaucoup les stagiaires en formation.
Ah oui OK ! En effet, pour moi ça c'est quand tu utilises le simulateur de façon, disons, stand-alone. C'est à dire tu as déjà ton application qui a été installée sur le simu et tu veux la relancer pour faire mumuse avec ou la montrer à tes collègues ou, cas plus fréquent, la montrer en démo en réunion par exemple. Là tu ne pilotes pas le simu via Xcode, c'est pas Xcode qui a lancé ton application dans un simulateur donné et a attaché le débuggeur à l'appli, c'est juste le simu que tu utilises tout seul indépendamment, comme tu utiliserais n'importe quelle application, et pas le simu piloté par Xcode qui le lance dans une certaine config.
Dans le simulateur, on peut simuler la gélocalisation courante. Dans Xcode aussi, au bas de la fenêtre, près des outils du débogueur. Je ne sais jamais lequel des deux (Xcode ou simu?) l'emporte.
Ah oui ok tu parlais de la position GPS, d'acc ^^ Bah c'est pareil là . Dans ton Scheme tu choisis le fichier de parcours simulé que tu veux tester pour ton application. C'est propre à chaque projet. Quand par exemple je travaille sur 2 ou 3 projets en parallèle (ce qui est assez fréquent vu mon job et mon poste d'architecte transverse où j'interviens pour coacher un peu plein de projets à la fois en une journée) quand je lance le projet A qui simule un certain parcours (qui a du sens pour ce projet A), puis lance peu après le projet B qui simule un autre parcours, je suis bien content qu'il n'ai pas gardé le parcours du projet A pour tester le projet B. Et si je retourne sur le projet A ensuite, je suis bien content quand je veux débuguer mon projet dans Xcode via le simu qu'il m'adapte le parcours en conséquence. Ca me parait logique puisque je suis dans un contexte de lancement de l'application et du simulateur à partir de Xcode, qui est celui qui se charge de tout (de lancer le simulateur, de lande lldb, d'attacher le débugueur au process dans le simulateur, de charger le xcappdata si j'en ai mis un particulier pour mon test, de charger le GeoJSON si j'en ai mis un aussi, de restaurer le contexte qui va bien en terme d'OS et de modèle. Si le simulateur était un simu iPhone iOS6 et que là je viens d'ouvrir dans Xcode un projet iPad iOS7-minimum, encore heureux que quand Xcode lance ensuite le projet il bascule comme il faut sur un iPad et non un iPhone, et sur un iOS7 et pas un iOS6, quel que soit ce que j'ai fait faire au simu avant.
Quand Xcode lance une application dans le simu, il adapte donc les réglages pour coller au contexte, au projet, et à ce que tu lui as demandé. Après si tu changes les valeurs après coup, par exemple pour la géoloc, bah tu changes la valeur en live donc ça la change. Bon si la valeur que tu changes c'est le modèle évidemment que ça aura pour side-effect de killer l'appli, c'est logique, et si à ce moment là en restant dans le simulateur tu tap sur l'icône du Springboard du simu pour lancer ton appli, elle se relancera. Ou si tu changes la géoloc là ça ne nécessite pas de reboot donc ça prend direct la nouvelle valeur.
Je comprend que ceux qui ne sont pas habitués soient tentés de changer le modèle dans le simu, et que ça quitte l'appli et que du coup ils ont le réflexe de la relancer avec Xcode qui forcément met le modèle qu'on lui demande de mettre et donc rechange le modèle de simu... au début ça doit perturber. Mais bon c'est parce qu'on lance l'appli depuis Xcode et qu'on demande à Xcode un certain modèle de simu (et heureusement que c'est lui qui le force). Si tu restais dans le simulateur après avoir changé de modèle, et relançait l'appli par un tap sur le Springboard, rien ne t'empêche de faire mumuse avec l'appli dans cet autre simulateur (voire de réattacher le débuggeur de Xcode à cette nouvelle instance d'application).
Réponses
En effet, pour moi ça c'est quand tu utilises le simulateur de façon, disons, stand-alone. C'est à dire tu as déjà ton application qui a été installée sur le simu et tu veux la relancer pour faire mumuse avec ou la montrer à tes collègues ou, cas plus fréquent, la montrer en démo en réunion par exemple. Là tu ne pilotes pas le simu via Xcode, c'est pas Xcode qui a lancé ton application dans un simulateur donné et a attaché le débuggeur à l'appli, c'est juste le simu que tu utilises tout seul indépendamment, comme tu utiliserais n'importe quelle application, et pas le simu piloté par Xcode qui le lance dans une certaine config.
Ah oui ok tu parlais de la position GPS, d'acc ^^
Bah c'est pareil là . Dans ton Scheme tu choisis le fichier de parcours simulé que tu veux tester pour ton application. C'est propre à chaque projet. Quand par exemple je travaille sur 2 ou 3 projets en parallèle (ce qui est assez fréquent vu mon job et mon poste d'architecte transverse où j'interviens pour coacher un peu plein de projets à la fois en une journée) quand je lance le projet A qui simule un certain parcours (qui a du sens pour ce projet A), puis lance peu après le projet B qui simule un autre parcours, je suis bien content qu'il n'ai pas gardé le parcours du projet A pour tester le projet B. Et si je retourne sur le projet A ensuite, je suis bien content quand je veux débuguer mon projet dans Xcode via le simu qu'il m'adapte le parcours en conséquence.
Ca me parait logique puisque je suis dans un contexte de lancement de l'application et du simulateur à partir de Xcode, qui est celui qui se charge de tout (de lancer le simulateur, de lande lldb, d'attacher le débugueur au process dans le simulateur, de charger le xcappdata si j'en ai mis un particulier pour mon test, de charger le GeoJSON si j'en ai mis un aussi, de restaurer le contexte qui va bien en terme d'OS et de modèle. Si le simulateur était un simu iPhone iOS6 et que là je viens d'ouvrir dans Xcode un projet iPad iOS7-minimum, encore heureux que quand Xcode lance ensuite le projet il bascule comme il faut sur un iPad et non un iPhone, et sur un iOS7 et pas un iOS6, quel que soit ce que j'ai fait faire au simu avant.
Quand Xcode lance une application dans le simu, il adapte donc les réglages pour coller au contexte, au projet, et à ce que tu lui as demandé. Après si tu changes les valeurs après coup, par exemple pour la géoloc, bah tu changes la valeur en live donc ça la change. Bon si la valeur que tu changes c'est le modèle évidemment que ça aura pour side-effect de killer l'appli, c'est logique, et si à ce moment là en restant dans le simulateur tu tap sur l'icône du Springboard du simu pour lancer ton appli, elle se relancera. Ou si tu changes la géoloc là ça ne nécessite pas de reboot donc ça prend direct la nouvelle valeur.
Je comprend que ceux qui ne sont pas habitués soient tentés de changer le modèle dans le simu, et que ça quitte l'appli et que du coup ils ont le réflexe de la relancer avec Xcode qui forcément met le modèle qu'on lui demande de mettre et donc rechange le modèle de simu... au début ça doit perturber. Mais bon c'est parce qu'on lance l'appli depuis Xcode et qu'on demande à Xcode un certain modèle de simu (et heureusement que c'est lui qui le force). Si tu restais dans le simulateur après avoir changé de modèle, et relançait l'appli par un tap sur le Springboard, rien ne t'empêche de faire mumuse avec l'appli dans cet autre simulateur (voire de réattacher le débuggeur de Xcode à cette nouvelle instance d'application).