[Proposal] Improve CameraView camera selection and preview startup behavior

[zhitaop]

Background

CameraView.SelectedCamera is currently a bindable property that can be set by developers.

It currently serves two purposes:

1. Switch the active camera while the CameraView is running.
2. Choose the initial camera that the CameraView should start with.

When SelectedCamera is set and the camera preview is already initialized/running, the preview is stopped and restarted with the newly selected camera.

Separately, CameraView also automatically starts the preview when loaded. If no camera is selected at startup, the SelectedCamera is set to the first available camera by default.

Issue

Because camera selection and preview startup are both automatic, preview startup can be triggered through multiple paths, and the order of those paths is not deterministic.

For example, consider a developer binding SelectedCamera to a view model property because they want the CameraView to start with a specific camera. Depending on timing, either of the following can happen:

Outcome 1: Correct camera, but unnecessary restart

1. CameraView starts automatically.
2. SelectedCamera binding has not been applied yet, so the first available camera is used.
3. Automatic startup completes with the first camera.
4. The SelectedCamera binding is applied.
5. The preview stops and restarts with the requested camera.

Issue: the final camera is correct, but the preview starts twice unnecessarily.

Outcome 2: State mismatch

1. CameraView starts automatically.
2. SelectedCamera binding has not been applied yet, so the first available camera is used.
3. The SelectedCamera binding is applied, while the initial automatic startup is still in progress.
4. Since the preview is not fully initialized yet, the expected restart does not happen.
5. Automatic startup completes with the first camera.

Issue: SelectedCamera is different from the camera actually used by the preview.

Root cause

The current design couples three concepts too tightly:

1. The developer’s desired camera.
2. The actual camera currently active.
3. The preview startup/switch lifecycle.

SelectedCamera is both an input and a reflection of state, while setting it can also trigger a camera restart. Combined with automatic startup, this creates timing-dependent behavior.

---

Proposal 1: Make active camera state read-only and make camera selection explicit

1. Make SelectedCamera read-only

Change SelectedCamera so that it is read-only and reflects the actual current active camera.

2. (Optional) Rename SelectedCamera

The name SelectedCamera may be ambiguous because it can still imply “the developer’s desired camera.”

A clearer name may be: ActiveCamera or CurrentCamera

3. Make camera selection an explicit operation through StartCameraPreview(...)

Add an overload that allows developers to explicitly start the preview with a specific camera:

Task StartCameraPreview(CameraInfo? cameraInfo, CancellationToken token = default);

Suggested behavior:

• If cameraInfo is provided, start the preview with that camera.
• If cameraInfo is null, use the current active camera or the default first available camera.
• If the preview is running with a different camera, switch and restart preview with the new camera.
• After a successful start or switch, update SelectedCamera / ActiveCamera.

4. Add AutoStart

Add an AutoStart property which defaults to true:

public bool AutoStart { get; set; } = true;

Suggested behavior:

• AutoStart = true: preserve current behavior - automatically start the camera preview using the first available camera.
• AutoStart = false: do not start automatically; developers need to explicitly call StartCameraPreview(cameraInfo).

This allows developers to choose the initial camera explicitly, while avoids unnecessary restarts.

cameraView.AutoStart = false;
await cameraView.StartCameraPreview(cameraInfo, cancellationToken);

Pros

• Separates state from operations.
• Makes the active camera property accurately reflect the camera actually in use.
• Avoids unnecessary stop/start cycles when selecting the initial camera.
• Makes camera switching explicit and easier to reason about.
• AutoStart = true preserves the existing default behavior.

Cons

• API breakage if SelectedCamera is made read-only. Existing XAML bindings to SelectedCamera as an input would need to change.
• Developers currently using SelectedCamera to switch cameras would need to use the new API.
• Requires a compatibility/deprecation strategy.

---

Proposal 2: Keep SelectedCamera settable, but remove automatic startup/default camera selection

Summary

• Keep SelectedCamera as a bindable property.

• Remove the behavior where CameraView automatically starts the preview and selects the first available camera.

• Developers would need to explicitly:

  1. Set SelectedCamera.
  2. Call StartCameraPreview().

• If SelectedCamera changes while preview is running, the preview switches camera.

Pros

• No major API shape breakage.
• SelectedCamera remains bindable and settable.
• Existing camera-switching logic through SelectedCamera can remain.

Cons

• Behavior change: developers must manually call StartCameraPreview() in all cases.
• Existing apps relying on automatic preview startup would need to be updated.
• Less convenient for simple use cases where developers just want to drop CameraView on a page and have it start.
• Changing SelectedCamera remains a property change with a native lifecycle side effect.
• Binding timing is less problematic, but property-driven camera switching can still be harder to reason about than an explicit method call.

---

Personally, I prefer proposal 1. Although it breaks existing API and requires more change from developer, it provides a clearer long-term API design. Feedback and alternative suggestions are also welcome!