GET /api/cameras to detect USB hot-plug events, auto-connect new cameras, and reconnect if one drops. The Alpha Camera REST server enumerates cameras every time you call /api/cameras, so regular polling is the idiomatic way to track physical state.
When to use
- Your app should handle USB cable unplug/replug gracefully
- You want to auto-connect the first camera that appears
- You’re running 24/7 and need resilience against transient disconnects
- You want to track multiple cameras and react when one drops
When NOT to use
- One-shot scripts — just call
list()once, grab the first camera, proceed - Apps where the user explicitly picks the camera from a list — polling only helps if state is changing
TypeScript
The real Next.js example collapses polling + SSE + reconnect into one small lifecycle class:example_app/src/lib/camera-manager.ts
Complete recipe
Why this is the right TypeScript shape
- polling alone is too slow for good connect/disconnect UX
- SSE alone is not enough to recover newly reappeared cameras
- reconnect timing belongs in one place, not spread across React components
- polls
GET /api/cameras - keeps diffed camera state
- opens a global SSE stream for connect/disconnect edges
- opens per-camera event streams on demand
- waits for SSE-connected confirmation after
connect() - retries reconnect with capped backoff
Python
Complete recipe
Usage — auto-connect first camera
Swift
Complete recipe
Usage
Combining with SSE for best UX
Polling catches hot-plug events within the poll interval (5s in the real macOS app). SSE reports disconnects instantly. Ideal pattern:- Polling — detects new cameras and performs eventual consistency / recovery
- SSE
connected— fast-paths connect completion so the UI does not wait for the next 5s poll - SSE
disconnected— instant teardown when a camera drops mid-session
Common pitfalls
- Polling alone is not enough for good UX. The real app combines 5s discovery polling with short-lived SSE listeners around connect and a long-lived
disconnectedlistener. - Callbacks can throw. Wrap your
onAppearlogic in try/catch — otherwise one bad camera kills the discovery loop. - Don’t poll too fast. The real app uses 5s.
/api/camerascan itself take several seconds because the server performs a fresh discovery scan. - Do not assume one negative
connected:falsemeans dropped. The real app requires two consecutive negative polls because the camera may transiently report not-connected during post-connect setup. - Skip discovery during transfers if your app can. The example app suppresses camera-list polling while SD downloads are active because the SDK serializes those operations per camera.
Verified against
The Swift section mirrors the connection/discovery lifecycle inexample_swift_app/Sources/AlphaCameraExample/AppCoordinator.swift.
