Appearance
Aperçu du Bridge Unifié
Concept
Le Bridge Unifié (classe UnifiedPlatformBridge dans src/lib/classes/platforms/platformBridge.ts) est un mécanisme de communication standardisé qui permet à l'application d'interagir avec les applications hôtes via l'API postMessage. Il est conçu pour les environnements intégrés en iframe, fournissant une interface unifiée pour les opérations sur les appareils à travers différentes plateformes TV (Samsung, LG, Philips, etc.). Cela assure un comportement cohérent tout en revenant automatiquement aux implémentations spécifiques à la plateforme lorsque le bridge n'est pas disponible ou échoue.
Fonctionnement
Le bridge fonctionne en :
- Envoi de messages : Envoi de messages structurés
TV_API_REQUESTàwindow.parentcontenant une action (e.g.,GET_IDENTIFIER), un ID de requête, et des paramètres. - Gestion des réponses : Écoute des messages
TV_API_RESPONSE, correspondance par ID de requête, et résolution/rejet des promesses. - Gestion des délais : Expiration des requêtes après 5 secondes si aucune réponse n'est reçue.
- Détection d'iframe : Tentative de communication bridge uniquement si en cours d'exécution dans un iframe (
window.self !== window.top). - Stratégie de repli : En cas d'échec, utilisation automatique des implémentations basées sur Capacitor (e.g., via
IdentifierFactory).
Actions prises en charge incluent : GET_IDENTIFIER, GET_HOST_CAPABILITIES, GET_NETWORK_INFO, GET_SYSTEM_INFO, GET_STORAGE_INFO, CAN_LAUNCH_APP, LAUNCH_APP, LAUNCH_TV, OPEN_SYSTEM_SETTINGS, OPEN_MANUFACTURER_SETTINGS, PURGE_DATA, REBOOT, INSTALL_APP, GET_MAC, GET_MANUFACTURER, GET_MODEL. L'action legacy OPEN_SETTINGS reste tolérée en fallback pendant la migration. (Voir les détails des échanges pour la spécification des paramètres).
Architecture et Bénéfices
L'un des objectifs majeurs du Bridge Unifié est de découpler l'application d'interface utilisateur (UI) de la partie hôte spécifique au matériel. Cette architecture offre plusieurs avantages stratégiques :
1. Séparation des Responsabilités (SoC)
- L'Application SvelteKit se concentre exclusivement sur l'expérience utilisateur, la logique métier et la présentation. Elle est agnostique du matériel.
- L'Application Hôte gère toute la complexité et les spécificités de la plateforme (APIs natives LG, Tizen, Android, appels système, gestion réseau, etc.).
2. Sécurité Renforcée
En déportant les traitements sensibles (accès aux identifiants matériels, contrôle du Wi-Fi, lancement d'applications système) dans l'application hôte, l'iframe de l'UI n'a pas besoin de permissions étendues ou d'accès directs aux APIs propriétaires. Le bridge agit comme une passerelle sécurisée et contrôlée.
3. Agilité et Cycles de Déploiement
- Mises à jour Web rapides : L'application UI peut être mise à jour et déployée sur un serveur web indépendamment du matériel. Les changements visuels ou de logique CMS sont instantanés.
- Stabilité de l'Hôte : L'application native hôte (plus complexe à mettre à jour car nécessitant souvent des validations constructeurs ou des installations locales) reste stable et ne change que lorsqu'une nouvelle fonctionnalité matérielle est requise.
4. Portabilité et Maintenance
L'ajout d'une nouvelle plateforme TV ne nécessite pas de modifier le cœur de l'application UI. Il suffit de développer une nouvelle application hôte implémentant le protocole du Bridge Unifié. L'UI s'adaptera automatiquement en utilisant les messages standardisés.
Stratégie de Repli (Fallback)
Le Bridge Unifié prend en charge des stratégies de repli (détaillées dans docs/technique/features/platform-fallback-spec.md) pour les environnements où l'hôte n'implémente pas encore le bridge ou en cas d'échec de communication. Dans ce cas, l'application bascule automatiquement sur les implémentations intégrées basées sur Capacitor, assurant ainsi une résilience maximale à travers divers écosystèmes TV.