Pipeline de Démarrage de l'Application

Ce document décrit le fonctionnement du pipeline de démarrage (Startup Pipeline) de l'application hybride. Il couvre les étapes allant du chargement initial de la page jusqu'à la récupération et l'affichage des données provenant du CMS.

Diagramme de Séquence

Description Détaillée des Étapes

1. Détection de la plateforme et de la méthode

Le processus s'initie au montage de l'application (principalement dans src/routes/+layout.ts). Le code instancie un système d'analyse d'environnement via dashboardBootstrap.load(url). Ce module identifie précisément l'environnement d'exécution (téléviseurs LG, Samsung, Android TV, Tizen, Chromecast, etc.).

2. Récupération de l'identifiant du device (UID/MAC)

Dès que l'environnement est reconnu, l'application doit identifier unitairement l'appareil pour afficher le bon contenu. Elle appelle la fonction dashboard.getIdentifier().

• Méthodes natives : Le système tente de récupérer l'identifiant par des APIs natives spécifiques à la plateforme (par exemple, appel au module de réseau C/C++ sur les TV LG getMac()).
• Fallback (fetchWhoami) : Si l'identifiant natif n'est pas accessible, un mécanisme de secours orchestré par src/lib/services/cmsPipeline.ts prend le relais. Il interroge un service local (/cgi-bin/whoami ou une résolution mDNS) pour récupérer l'adresse MAC.

Le résultat final de cette étape est stocké de manière globale dans le store uid.

2.bis Synchronisation Hotspot au démarrage

En parallèle du bootstrap dashboard, l'application lance initializeHotspotAtStartup() (src/lib/hotspot/bootstrap.ts) pour synchroniser l'état hotspot dès le démarrage.

• Le bootstrap tente d'initialiser le host bridge avec timeout court.
• Le provider hotspot est résolu via HotspotManager.
• Les credentials sont lus via HOTSPOT_GET avec timeout.
• Le hotspotStore est mis à jour avec un statut explicite (enabled, disabled, unsupported, error).

Cette étape est non bloquante pour le rendu initial.

2.ter Provisioning VPN WireGuard

Les services de fond du layout peuvent lire les donnees CMS du device via getDeviceCmsData(uid). Cette lecture inclut le champ devices.ip_vpn.

Si ip_vpn est absent, l'application tente un provisioning WireGuard non bloquant pour le rendu initial : verification du client Android fr.tvcast.vpn, creation d'un peer via le service WireGuard, ouverture du deep link vpn://import, puis mise a jour de devices.ip_vpn dans Directus.

Une relance manuelle est disponible dans Settings > Reseau. Contrairement au flux automatique, elle utilise le mode force et recree un peer meme si ip_vpn existe deja.

Voir Provisioning VPN WireGuard.

3. Appel sur le "Redirecteur"

Une fois l'identifiant unique possédé, le service cœur de l'application, CmsPipelineService (src/lib/services/cmsPipeline.ts), s'active. Il exécute l'étape fetchRedirector. Cet appel n'est pas une redirection au sens HTTP du terme, mais l'appel à une API de résolution et configuration :

• Endpoint : ${PUBLIC_URL_REDIRECTOR}/v1/tvinterface/{uid}
• Rôle : Cette API relie l'identifiant matériel de l'écran à un contexte commercial et géographique.
• Retour : L'API retourne trois identifiants cruciaux : advertisingId (campagne de publicité et charte graphique associées), facilityId (établissement / hôtel de rattachement) et areaId (zone de l'établissement).

Ces données viennent peupler le redirectorStore.

4. Ciblage des appels API CMS et alimentation de l'interface

L'architecture de l'application repose sur la réactivité des stores Svelte. La mise à jour du redirectorStore entraîne une série d'appels API en cascade vers Directus (le CMS du projet) :

• L'identifiant facilityId déclenche le requêtage de l'établissement courant, mettant à jour le facilityStore.
• Parallèlement, l'identifiant advertisingId (src/lib/stores/advertisingStore.ts) lance la récupération de la configuration publicitaire (logotypes, couleurs du thème, contenus médias poussés sur l'écran). Les données obtenues alimentent l'advertisingStore et l'advertisingContentsStore.

L'interface Svelte, comme la page d'accueil (src/routes/+page.svelte), s'abonne à ces stores. Dès que les données du CMS sont reçues et validées par le pipeline, les composants se re-rendent avec la charte de l'établissement et les contenus publicitaires ciblés. Le démarrage complet est alors achevé.