session-lifecycle

États de session de l'appareil, pause/reprise, surveillance de la disponibilité

npx skills add https://github.com/facebook/meta-wearables-dat-ios --skill session-lifecycle

Session Lifecycle (iOS)

Guide for managing device session states in DAT SDK integrations.

Overview

The DAT SDK runs work inside sessions. Meta glasses expose two experience types:

  • Device sessions — sustained access to device sensors and outputs
  • Transactions — short, system-owned interactions (notifications, "Hey Meta")

Your app observes session state changes — the device decides when to transition.

Session states

StateMeaningApp action
idleSession created but not startedCall start() when ready
startingSession is connecting to the deviceShow connecting state
startedSession active and ready for capabilitiesAdd or resume work
pausedTemporarily suspended by the deviceHold work, may resume
stoppingSession is cleaning upWait for terminal state
stoppedSession inactive and terminalFree resources, create a new session to restart

Observing session state

let session = try Wearables.shared.createSession(deviceSelector: AutoDeviceSelector(wearables: Wearables.shared))
try session.start()

Task {
    for await state in session.stateStream() {
        switch state {
        case .started:
            // Confirm UI shows session is live
        case .paused:
            // Keep connection, wait for started or stopped
        case .stopped:
            // Release resources, allow user to restart
        default:
            break
        }
    }
}

DeviceSession exposes both shapes: stateStream() / errorStream() as AsyncStream, and statePublisher / errorPublisher as listener-token Announcers. Pick one per call site; subscribe before calling start() so no initial transition is missed.

Session errors

errorStream() and errorPublisher emit DeviceSessionError. Handle .noEligibleDevice (no matching device yet), .sessionAlreadyExists, .capabilityAlreadyActive, the thermal/battery cases (.thermalCritical, .thermalEmergency, .peakPowerShutdown, .batteryCritical), and .datAppOnTheGlassesUpdateRequired, which is delivered as a one-shot event and should open Wearables.shared.openDATGlassesAppUpdate().

start() uses typed throws, so you can catch the specific case:

do throws(DeviceSessionError) {
    try session.start()
} catch .datAppOnTheGlassesUpdateRequired {
    showGlassesAppUpdatePrompt()
} catch {
    showError(error.localizedDescription)
}

Stream state transitions

A Stream is a capability attached to a started DeviceSession:

stopped → waitingForDevice → starting → streaming → paused → stopped
guard let camera = try session.addCamera(config: StreamConfiguration()) else { return }
let stream = camera.stream

let token = stream.statePublisher.listen { state in
    Task { @MainActor in
        // React to state changes
    }
}

Common transitions

The device changes session state when:

  • User performs a system gesture that opens another experience
  • Another app starts a device session
  • User removes or folds the glasses (Bluetooth disconnects)
  • User removes the app from Meta AI companion app
  • Connectivity between companion app and glasses drops

Pause and resume

When a session is paused:

  • The device keeps the connection alive
  • Streams stop delivering data
  • The device may resume by returning to started

Your app should not attempt to restart while paused — wait for started or stopped.

Device availability

Monitor device availability to know when sessions can start:

Task {
    for await deviceIds in Wearables.shared.devicesStream() {
        // deviceIds is [DeviceIdentifier]; resolve details with deviceForIdentifier(_:)
    }
}

A DeviceSelector also reports availability directly. AutoDeviceSelector and SpecificDeviceSelector both expose activeDevice and activeDeviceStream(), which yields nil when no eligible device is available:

let selector = AutoDeviceSelector(wearables: Wearables.shared)
Task {
    for await deviceId in selector.activeDeviceStream() {
        hasActiveDevice = deviceId != nil
    }
}

Key behaviors:

  • Closing hinges disconnects Bluetooth → forces stopped
  • Opening hinges restores Bluetooth but does not restart sessions
  • Start a new session after the device becomes available again

Implementation checklist

  • Handle all relevant session states (started, paused, stopped)
  • Monitor device availability before starting work
  • Release resources only after stopped
  • Don't infer transition causes — rely only on observable state
  • Don't restart during paused — wait for system to resume or stop

Links

Plus de skills de facebook

gc-safe-coding
facebook
Pour l'explication complète et la justification, voir doc/GCSafeCoding.md .
app-review-prep
facebook
Préparez une application Meta pour l'App Review — vérifie le statut actuel, les exigences restantes, les privilèges accordés et l'historique de soumission. À utiliser avant de soumettre une application…
api-health
facebook
Surveillez la santé de l'API d'une application Meta — vérifiez les limites de débit, le volume d'appels et les dépréciations d'API. Utilisez-le pour diagnostiquer la limitation, planifier la capacité ou vous préparer à une version d'API…
debug-webhooks
facebook
Résolvez les problèmes de webhook pour une application Meta — inspectez les abonnements actifs, identifiez les erreurs de configuration et envoyez des charges utiles de test pour vérifier la livraison. Utilisez lorsque…
api-integration
facebook
Guider un développeur dans la mise en place d'une intégration d'API Meta de A à Z — découvrir les bonnes API, récupérer les guides de configuration, les exigences d'authentification,…
webhook-setup
facebook
Configurer des webhooks pour une application Meta de bout en bout — découvrir les sujets disponibles, s'abonner aux champs, et vérifier avec une charge utile de test. À utiliser lors de la configuration de webhooks pour…
test-ui
facebook
Test du système d'interface utilisateur (PanelUI, ScreenSpace) par rapport à l'exemple poke à l'aide de l'interface en ligne de commande iwsdk.
flags
facebook
Inspecter et comparer les états des feature flags entre les canaux de publication React. Afficher tous les flags entre les canaux (www, www-modern, canary, next, experimental, variantes rn) ou comparer des canaux spécifiques avec --diff. Les formats de sortie incluent la vue tableau par défaut, l'export CSV et le regroupement par état de nettoyage. Les états des flags sont indiqués par des symboles : activé (✅), désactivé (❌), test de variante (🧪), profilage uniquement (📊). Piège courant : les flags __VARIANT__ sont testés dans les deux états sur www ; utilisez --diff pour repérer les différences significatives...