Skip to main content
Poll 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
The real manager does all of the following:
  • 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
If you are building a React app, use this lifecycle layer under your components instead of duplicating polling logic in the page.

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
You don’t need both if your use case is simple. The real app uses both because 5-second polling alone feels too slow for connect/disconnect edges.

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 disconnected listener.
  • Callbacks can throw. Wrap your onAppear logic in try/catch — otherwise one bad camera kills the discovery loop.
  • Don’t poll too fast. The real app uses 5s. /api/cameras can itself take several seconds because the server performs a fresh discovery scan.
  • Do not assume one negative connected:false means 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 in example_swift_app/Sources/AlphaCameraExample/AppCoordinator.swift.