Outils de Live Coding : celedev & Injection4Xcode
AliGator
Membre, Modérateur
Bonjour à tous,
Suite à une remarque de Céroce dans un autre sujet :
Ces solutions permettent de modifier le code ou jouer sur des paramètres et de voir ces modifications appliquées en live dans votre application, sans relancer cette dernière, alors qu'elle est encore en train de tourner.
Aujourd'hui je connais 2 solutions permettant cela :
Pour ma part je n'ai pas encore eu l'occasion de tester ni l'une ni l'autre, mais je compte bien m'y atteler incessamment sous peu !
Suite à une remarque de Céroce dans un autre sujet :
Je rebondis dessus pour ouvrir le sujet des outils de Live Coding.Je trouve que le cycle de développement est lent (écrire, lancer le simu, attendre, corriger, etc).
Ces solutions permettent de modifier le code ou jouer sur des paramètres et de voir ces modifications appliquées en live dans votre application, sans relancer cette dernière, alors qu'elle est encore en train de tourner.
Aujourd'hui je connais 2 solutions permettant cela :
- La première, c'est Injection4Xcode, un plugin Xcode qui permet de demander à recompiler juste un fichier ou un bout de son appli... et directement l'injecter dans l'application qui est en train de tourner sans avoir à redémarrer cette dernière. Entre autres on peut recompiler du code à la volée mais aussi injecter des valeurs dynamiques comme des couleurs que l'on change ensuite via une palette de couleurs fournie par le plugin. Je vous laisse regarder la vidéo sur son site pour la présentation.
- L'autre solution, c'est Celedev, un éditeur de code alternatif à Xcode. Ce dernier n'est pas encore officiellement disponible, puisque son auteur JL Jumpertz est encore en train de travailler dessus, mais une version beta est dans les bacs et va sortir très très très bientôt. Le principe est de développer des bouts de code en LUA (langage de scripting très très facile à apprendre et qui possède un pont avec tout le SDK Cocoa le rendant trivial à utiliser) pour avoir du code dynamique qui change à la volée. Sa solution permet aussi de changer les ressources (par exemple modifier une image PNG et la sauver et voir l'image changer directement dans l'application toujours en train de tourner). Il en a également fait une démonstration très impressionnante lors d'un récent CocoaHeads Rennes (dispo en vidéo).
Pour ma part je n'ai pas encore eu l'occasion de tester ni l'une ni l'autre, mais je compte bien m'y atteler incessamment sous peu !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je rebondis sur ce post:
Il existe également http://revealapp.com qui permet d'interagir sur l'UI. Modification de couleurs/Layers... etc
Merci pour les infos.
Je ne connaissais pas InjectionForXcode... à essayer.
Pour Celedev, je trouve qu'écrire le code en Lua est quand même une contrainte, parce qu'il va falloir intégrer le runtime de Lua dans l'application, et certainement une partie de sa bibliothèque standard. De plus, utiliser Cocoa avec autre chose qu'Objective-C n'est pas très naturel. Et puis, je ne cache pas que ça me fait un peu peur de baser mon travail sur un système propriétaire qui peut disparaà®tre du jour au lendemain.
Cela dit, l'idée est intéressante, et à vrai dire, c'est à Celedev que je pensais quand j'ai écrit la phrase citée par Ali.
Pareil je vais tester de ce pas. Merci.
[EDIT Modo]Concernant le message précédent c'était un robot spammeur, il a été ejecté des forums.[/EDIT]
ça l'air tentant... (merci Spek de ton retour).
Je l'ajoute à ma liste de choses à voir !
Je viens également de tester InjectionForXcode, et c'est vraiment très simple à installer et utiliser.
Je n'ai pas encore eu beaucoup le temps de tester, mais mes essais sont concluants pour l'instant. ça va sans doute devenir un outil indispensable pour moi !
Je viens de voir la démo et ça a l'air super.
Je ne vais pas tarder à l'installer.
Son principe n'est pas vraiment du Live Coding, mais permet de voir votre interface / hiérarchie de vue en 3D, pour afficher un découpage en couches de votre UI et voir comment s'empilent les vues (et quelle sont leurs frames, comprendre que si telle vue n'est pas affichée c'est parce qu'elle est masquée par telle autre, etc). C'est très pratique pour le débug d'interfaces graphiques.
Sauf que depuis qu'il n'est plus en beta, il est passé payant... et son prix est, je trouve, assez élevé... surtout par rapport à la concurrence : ~3x plus cher pour des licences individuelles, sans parler que pour une licence entreprise, il faut autant de licences à 179€ que d'utilisateurs dans l'entreprise !!
C'est pour cela que de notre côté nous sommes partis pour acheter des licences de son concurrent Spark Inspector, qui a le même fonctionnel, mais est 3x moins cher, et en + offre des licences flottantes, ce qui permet de n'en acheter que 2 ou 3 sièges de licence à 30€ l'unité (et pas 179€!) pour que tout le monde dans l'entreprise puisse l'utiliser. Certes on ne pourra pas être plus de 2 ou 3 à l'utiliser en même temps / en parallèle, mais en général ce genre d'outil on l'utilise seulement ponctuellement pour débuguer un pb précis, donc ça suffit
InjectionForXcode a l'air très sympa.
Par contre, n'y a t'il pas un risque avec le " Patch project for injection " ?
1) Tu peux lui demander d'annuler les modifications qu'il a faites et d'annuler le patch
2) L'application du patch consiste juste à rajouter qques lignes dans le main.m et dans le prefix.pch
3) Il me semble que tu as même moyen, dans le menu de Injection4Xcode, de lui demander de t'afficher le script qui sert à appliquer ce patch, si tu veux regarder un peu comment c'est fait
J'ai cru lire il n'y pas longtemps que ponydebugger permet de faire du livre coding sur les vues. (Comme un peu ce que fait reveal, mais en répercutant la modif dans le code).
Je crois que c'était dans ce CocoaHeads :
http://cocoaheads.tv/ponydebugger-by-jay-thrash/
Mais j'ai jamais vu PonyDebugger modifier le code source en live, et ça serait de toute façon bizarre comme concept (si je crées une variable x et que je fais monLabel.frame = CGRectMake(2*x,0,width-2*x,height), comment PonyDebugger va savoir qu'en modifiant en live mon code c'est x qu'il faut modifier et pas des valeurs en dur qu'il faut mettre ? De toute façon les valeurs en dur c'est le mal absolu). Il ne peut pas savoir vraiment quelle(s) ligne(s) de code font que tel composant est à telle place, surtout si le tout est dynamique. Je ne parle même pas de si on utilise les contraintes...
Non par contre ce que PonyDebugger sait faire, c'est la même chose que Sparkle et Reveal, à savoir modifier des valeurs dans leur interface (flat pour PonyDebugger, 3D pour Sparkle & Reveal) et que ça se répercute en live sur l'application qui est en train de tourner (mais bien sûr si tu quittes et relance l'application, ou si tu changes d'écran et revient sur l'écran et que ça le recharge et repasse dans le viewDidLoad, ça va retomber sur le layout prévu par le code et pas celui que tu as modifié au Runtime). Tu quittes et relance l'appli ton code n'a pas été modifié et tu retombes sur le cas prévu par le code, sans les modifications faites en live sur l'écran en cours.
Effectivement, si l'on peut savoir ce qu'il fait exactement, ça se tente
En gros :
- si tu as des modifications non encore commitées tu les stash pour partir d'une working copy propre
- ensuite tu appliques le patch Injection4Xcode sur ton projet et tu commites les modifications que cela a généré
- puis tu réappliques le stash pour retrouver ton travail en cours où tu l'avais laissé.
Et basta. Après tout, GIT c'est fait pour ça.Et si ça pose des soucis au moment de l'application du stash, il sera toujours temps d'annuler le commit (ou si tu as des soucis plus tard et que tu as déjà empilé d'autres commits depuis, tu peux toujours faire un "reverse commit" qui applique tout seul les modifications miroir du commit de patch Injection4Xcode de toute façon)
---
Mais bon en plus concrètement t'es même pas obligé d'installer le patch Injection4Xcode sur ton projet pour pouvoir patcher ton code (le plugin sait piloter lldb pour injecter le code au Runtime).
Appliquer le patch Injection4Xcode n'a d'intérêt que si tu veux pouvoir patcher une appli sur device (et signée) ou des choses comme ça, mais si comme dans la plupart des cas tu utilises Injection4Xcode juste pour ajuster des petits bouts de code par tâtonnement ou le temps de régler un bug par étapes, l'injection de code en live sur le simulateur sans avoir à patcher le projet suffit amplement. Tu peux juste faire "Product" -> "Inject Source" même sur un projet non patché et ça marchera