dat-conventions
Kotlin-Muster, DatResult, Sitzungs- und Capability-Konventionen für die DAT SDK Android-Entwicklung
npx skills add https://github.com/facebook/meta-wearables-dat-android --skill dat-conventionsDAT SDK Conventions (Android)
Quick Reference
| Task | Command |
|---|---|
| Build app | ./gradlew assembleDebug |
| Run tests | ./gradlew test |
| Install app | ./gradlew installDebug |
| Lint app | ./gradlew lint |
Architecture
The SDK is organized into four public modules:
- mwdat-core: Registration, permissions, devices, and session creation
- mwdat-camera: Camera capability, video frames, and photo capture
- mwdat-display: Display capability, display UI components, icons, images, buttons, and video
- mwdat-mockdevice: MockDeviceKit for testing without hardware
Initialization and session setup
DeviceSession.start() is fire-and-forget and returns Unit; capabilities can only be attached once the session reports DeviceSessionState.STARTED.
Wearables.initialize(context)
Wearables.createSession(AutoDeviceSelector()).fold(
onSuccess = { session ->
lifecycleScope.launch {
session.state.collect { state ->
if (state == DeviceSessionState.STARTED) {
session.addCamera(StreamConfiguration()).fold(
onSuccess = { camera ->
camera.stream.start().onFailure { error, _ ->
showError(error.description)
}
},
onFailure = { error, _ -> showError(error.description) },
)
}
}
}
lifecycleScope.launch {
session.errors.collect { error -> showError(error.description) }
}
session.start()
},
onFailure = { error, _ -> showError(error.description) },
)
Kotlin patterns
- Use
DatResult<T, E>for typed success and failure handling - Prefer
fold,onSuccess, and the two-parameteronFailure { error, cause -> }overload, which hands you the typedDatErrorwith adescription getOrElse { }receives a rawThrowable, not a typedDatError, so it cannot readerror.description- Observe state with
StateFlowandFlow - Create a
DeviceSessionfirst, then attach capabilities such asCameraorDisplayafter it reachesSTARTED - Keep frame handling off the main thread when doing heavier processing
Error handling
Wearables.checkPermissionStatus(Permission.CAMERA)
.onSuccess { status -> /* handle status */ }
.onFailure { error, _ -> /* handle error */ }
Avoid getOrThrow() in user-facing samples. Surface typed errors from DatResult instead.
Naming conventions
| Type | Purpose | Example |
|---|---|---|
DeviceSession | Device connection lifecycle | Wearables.createSession(...) |
Camera | Camera capability on a session | session.addCamera(...) |
Stream | Video stream from a camera | camera.stream |
Display | Display capability on a session | session.addDisplay(...) |
*Selector | Device targeting | AutoDeviceSelector, SpecificDeviceSelector |
*Error | Typed failure surface | DeviceSessionError, StreamError, CaptureError |
Key types
Wearables— SDK entry pointDeviceSession— lifecycle for an interaction with a linked deviceCamera— camera capability attached to a sessionStream— video stream accessed throughcamera.streamDisplay— display capability attached to a sessionStreamConfiguration— video quality, frame rate, and compression configurationMockDeviceKit— simulated device environment for testing
Live docs search
If your editor supports remote MCP servers, connect https://mcp.developer.meta.com/wearables and use search_dat_docs for current DAT setup, session lifecycle, camera streaming, MockDeviceKit, permissions, and exact API symbols. This public docs server does not require authentication; do not configure tokens, OAuth, or custom authorization headers for it.
See the dat-docs-mcp skill for client setup and troubleshooting. Use llms.txt when your tool only supports static reference context.
Testing with MockDeviceKit
val mockDeviceKit = MockDeviceKit.getInstance(context)
mockDeviceKit.enable()
mockDeviceKit.pairGlasses(GlassesModel.RAYBAN_META).fold(
onSuccess = { device -> onMockDevicePaired(device) },
onFailure = { error, _ -> showError(error.description) },
)
Use MockDeviceKit to drive registration, device availability, streaming media, and permission scenarios without physical hardware.
Common pitfalls
- Do not call SDK APIs before
Wearables.initialize(context) - Do not call
addCamera(...)oraddDisplay()immediately aftersession.start(); wait forDeviceSessionState.STARTED - Do not assume a session implies streaming or display access; capabilities are attached separately
- Do not ignore
DatResultfailures fromcreateSession,start,addCamera,addDisplay, orcapturePhoto - Do not reuse terminally stopped sessions, cameras, or streams