GBGBridge ships two stub camera views —Documentation Index
Fetch the complete documentation index at: https://docs.go.gbgplc.com/llms.txt
Use this file to discover all available pages before exploring further.
StubDocumentCameraView and StubSelfieCameraView — that let you prove the bridge works end-to-end without installing the SmartCapture SDKs.
When to Use Stubs
- Early integration — You want to verify the bridge protocol, capability negotiation, and data flow before the SmartCapture SDKs are available or configured.
- CI / automated testing — Stubs work on Simulator (displaying placeholder images) without requiring camera hardware.
- Prototyping — You’re building the host app shell and want a capture flow that “just works” while you focus on other parts of the integration.
StubDocumentCameraView
Presents the rear camera on a real device, or a programmatically drawn placeholder document image on Simulator. Returns aDocumentCaptureResult containing the PNG-encoded image.
What you get
| Field | Value |
|---|---|
imageData | PNG-encoded photo from the rear camera (device) or placeholder image (Simulator) |
width / height | Pixel dimensions of the captured image |
mimeType | "image/png" |
What you don’t get
- Document edge detection and auto-crop
- Blur / glare / quality scoring
- Guided capture overlay with real-time feedback
- Auto-capture on frame quality threshold
StubSelfieCameraView
Presents the front camera on a real device, or a programmatically drawn face silhouette on Simulator. Returns aSelfieCaptureResult with the JPEG image and placeholder biometric blobs.
What you get
| Field | Value |
|---|---|
previewImageData | JPEG-encoded selfie from the front camera (device) or placeholder image (Simulator) |
width / height | Pixel dimensions of the captured image |
mimeType | "image/jpeg" |
encryptedBlob | Raw JPEG data (placeholder) |
unencryptedBlob | Raw JPEG data (placeholder) |
What you don’t get
- Liveness detection (active or passive)
- Face mesh / landmark analysis
- Encrypted biometric blobs that pass server-side validation
- Guided selfie overlay with positioning feedback
The
encryptedBlob and unencryptedBlob fields contain the raw JPEG image data as a stand-in. They are structurally valid (non-empty Data) so the bridge protocol works, but they will not pass liveness verification on the server. This is by design — the stubs exist to prove the integration, not to produce real biometric data.Simulator Support
On Simulator, there is no camera hardware. Both stub views automatically display programmatically drawn placeholder images — a passport-style document card forStubDocumentCameraView and a face silhouette for StubSelfieCameraView — with a shutter-style capture button. Tapping the shutter generates a synthetic image and returns it through the normal callback, so you can exercise the full capture flow in CI or on your Mac without a physical device.
Swapping Stubs for Real SDKs
The stub views are a drop-in replacement for the real SmartCapture views. The handler setup and bridge wiring stay the same — only the view insidefullScreenCover changes.
Before (stub)
After (real SDK)
- View type — Replace
StubDocumentCameraView/StubSelfieCameraViewwith your SDK-backed view. - Callback shape — The real SDK views may have different callback signatures (e.g., separate
onCapturedandonFailedcallbacks instead of a singleDocumentCaptureResult). Construct theDocumentCaptureResultorSelfieCaptureResultin the callback. - Nothing else changes — The handler on the typed slot, the
awaitCompletion()/complete()pattern, the bridge protocol, and thefullScreenCoverpresentation logic all stay the same.
Complete Example
A minimal SwiftUI view using both stub views:Next Steps
- Tutorial Part 2: Integrate Smart Capture SDKs — Step-by-step guide to replacing stubs with production SDKs
- Integration Checklist — End-to-end setup walkthrough
- Capability Handling Guide — How typed slots and custom capabilities work
- Embedding Guide — SwiftUI and UIKit integration patterns