Cycle de vie et synchronisation

Objectif

Faire correspondre le contrat publié aux objets réellement actifs, y compris lors d'un changement de scène.

Enregistrement automatique

PulseBehaviour suit le cycle Unity :

• OnEnable appelle PulseRegistry.Register(this) ;
• OnDisable appelle PulseRegistry.Unregister(this).

Les objets instanciés dynamiquement sont donc découverts sans scan de scène. Un objet désactivé cesse immédiatement d'exposer ses bindings.

Surcharger OnEnable ou OnDisable

public sealed class SceneControls : PulseBehaviour
{
    protected override void OnEnable()
    {
        base.OnEnable();
        // Vos abonnements.
    }

    protected override void OnDisable()
    {
        // Vos désabonnements.
        base.OnDisable();
    }
}

Oublier base est une cause classique d'actions absentes ou de bindings qui restent enregistrés.

Moment de construction du schéma

Le schéma est produit :

1. lorsque PulseMDMClient reçoit la connexion ;
2. lorsqu'il reçoit un message SYNC.

Il contient les composants enregistrés à cet instant, ainsi que la valeur courante de chaque variable. L'activation ultérieure d'un PulseBehaviour met à jour le registre, mais ne déclenche pas seule un nouveau SCHEMA en 0.1.3.

Stratégie par type d'application

Scène unique

Activez les composants pilotables avant la connexion automatique. Le premier schéma sera complet.

Plusieurs scènes

Conservez le runtime Pulse dans une scène de bootstrap. Après le chargement et l'activation de la nouvelle scène, faites demander SYNC par le contrôleur. Il recevra le nouveau contrat complet.

Objets créés à la demande

Après leur création, demandez également SYNC. Après leur destruction, resynchronisez si le contrôleur doit retirer immédiatement leurs commandes de son interface.

Valeurs initiales et état vivant

Le getter d'une variable est lu pendant la construction du schéma. Cette valeur est un instantané. Avec le package 0.1.3 :

• SCHEMA donne l'état au moment de la synchronisation ;
• SET modifie une variable distante et renvoie un ACK ;
• une modification locale ultérieure n'est pas publiée automatiquement en DELTA.

Si votre produit exige un état temps réel, considérez cela comme une fonctionnalité à implémenter dans une future version du SDK ou un adaptateur explicitement versionné, pas comme un comportement implicite.

Ce que vous devez avoir à la fin

• Toutes les surcharges appellent les méthodes base.
• Le runtime Pulse n'est pas recréé à chaque scène.
• Un SYNC est demandé après les changements de bindings.
• Les getters sont sûrs à lire pendant la construction du schéma.
• Le produit distingue l'instantané SCHEMA du suivi temps réel absent en 0.1.3.

Étape suivante : tester et déboguer.