Live Preview
Oui, ça existe, et il y a plusieurs “familles” de solutions. L’idée générale est toujours la même : • le téléphone (ou l’émulateur) exécute l’app • le desktop exécute un “studio” • les deux gardent une connexion ouverte (USB ou Wi-Fi) • le studio envoie des “patchs” (des deltas) ou des “commandes” à l’app pour mettre à jour l’UI en live.
Voici les 3 mécanismes principaux.
⸻
1) Hot Reload / Live Reload “classique”
C’est la solution des frameworks (Flutter, React Native, etc.).
Comment ça marche : • le desktop compile (ou transpile) le code, • un serveur de dev tourne sur le desktop, • l’app sur le téléphone se connecte à ce serveur, • quand vous modifiez un fichier, le serveur pousse une mise à jour.
Deux variantes : • Live reload : recharge toute la page / l’écran (on perd parfois l’état). • Hot reload : injecte du code et tente de garder l’état.
➡️ Là, le “dialogue” desktop ↔ téléphone est souvent : • WebSocket / HTTP • et/ou un protocole de debug intégré au runtime.
⸻
2) UI “pilotée par données” (ce qui vous intéresse pour Dyglot Teacher / Studio)
C’est le modèle “studio + runtime” : l’app n’est pas recompilée, elle interprète une description d’écran.
Comment ça marche : • l’app sur le téléphone contient un moteur de rendu (renderer), • le studio sur desktop édite une représentation (JSON / DSL / arbre), • le studio envoie cette représentation à l’app, • l’app re-render immédiatement.
Connexion typique : • WebSocket (parfait pour du “push” temps réel) • ou HTTP polling (moins bien) • ou USB via un “bridge” (adb pour Android, instruments/bonjour/etc pour iOS)
Gros avantage : • pas besoin que le teacher compile quoi que ce soit • “Dyglot Studio” peut être un outil graphique (drag & drop), et le téléphone devient une “preview live”.
C’est très proche de ce qu’on voudrait pour : • Teacher définit ses views • Preview instantané sur téléphone • sans imposer HTML/SQL/programmation.
⸻
3) Remote DevTools / Inspection + “commande”
C’est le modèle Web (Chrome DevTools, Safari Web Inspector) ou certains outils no-code.
Comment ça marche : • l’app expose un port de debug • le desktop se connecte à ce port • vous modifiez des propriétés, du DOM, des styles, etc.
C’est très puissant, mais souvent moins “teacher friendly” (car on retombe sur des concepts techniques).
⸻
Concrètement : comment “ils font dialoguer” desktop et téléphone ?
Dans 90% des cas : un WebSocket.
• Le téléphone ouvre : ws://
Le reste (USB, etc.) n’est qu’un moyen de transporter cette connexion.
⸻
Pour Dyglot (vision réaliste)
Vous pouvez viser un modèle très simple :
Dyglot Studio (desktop) • édite une View • sérialise la View en JSON (ou en “Dyglot View AST”) • envoie en WebSocket
Dyglot Student (phone/emulator) en mode “preview” • se connecte au studio • reçoit la View • l’affiche • permet de simuler “Question → Answer” • et d’afficher la barre de boutons générée par l’Engine choisi
Ça colle parfaitement à votre séparation : • Teacher définit la View • Engine injecte header + boutons
⸻
Si vous voulez, je peux écrire une page Markdown “Teacher — Live Preview (Dyglot Studio ↔ Dyglot Student)” qui décrit ce mécanisme proprement, sans vous enfermer dans un choix technologique trop tôt (mais avec une option recommandée : WebSocket).