User Story
As a Pyrycode mobile user whose QR scan succeeded, I want a connecting-feedback state during the handshake, so I have explicit feedback that pairing is in flight rather than wondering if the tap registered.
Context
Figma node 32:20 (Scanner — Connecting state variant) doesn't exist in code today. The current fake-pair flow in ScannerScreen.kt transitions instantly to ChannelList with no intermediate state. When the real CameraX + relay handshake lands in Phase 4 there's a real connecting window, so pre-building the visual now decouples Figma-fidelity work from network integration. Phase 1.5 Figma-anchored catchup wave, sibling to #61 (Scanner Denied).
Acceptance Criteria
Technical Notes
Scope discipline:
- Single new file alongside
ScannerScreen.kt and ScannerDeniedScreen.kt. Do NOT wire into MainActivity's NavHost in this ticket — real connecting transitions arrive with CameraX in Phase 4.
- Mirror
ScannerScreen.kt (95 LOC) and ScannerDeniedScreen.kt (168 LOC) for Surface, systemBarsPadding, and PyrycodeMobileTheme preview wrapping conventions.
Rendering pointers:
- Compose's built-in
CircularProgressIndicator (indeterminate variant) supplies the 270° open-arc ring natively. The Figma file's hand-built 3-cubic-Bézier path is a Figma-API workaround and does not need to be replicated in Compose.
- Use the M3 typography roles the Figma binds (verify via
get_design_context, do not guess).
Size Estimate
S — single file, ~60–100 production LOC: M3 layout (Surface + Column + indicator + two text lines) wrapped in light/dark previews. No Canvas illustration, no data layer, no navigation, no DI changes.
Figma
https://www.figma.com/design/g2HIq2UyPhslEoHRokQmHG?node-id=32-20
User Story
As a Pyrycode mobile user whose QR scan succeeded, I want a connecting-feedback state during the handshake, so I have explicit feedback that pairing is in flight rather than wondering if the tap registered.
Context
Figma node
32:20(Scanner — Connecting state variant) doesn't exist in code today. The current fake-pair flow inScannerScreen.kttransitions instantly to ChannelList with no intermediate state. When the real CameraX + relay handshake lands in Phase 4 there's a real connecting window, so pre-building the visual now decouples Figma-fidelity work from network integration. Phase 1.5 Figma-anchored catchup wave, sibling to #61 (Scanner Denied).Acceptance Criteria
app/src/main/java/de/pyryco/mobile/ui/onboarding/renders the Connecting state from Figma node32:20: indeterminate circular progress, headline copy, and the server address the user just paired with32:20and uses an M3 typography role (no hardcodedTextStyle)FontFamilyusing the typography role Figma binds (architect verifies viaget_design_context)MaterialTheme.colorScheme.*— zero hardcoded color literals@Previewcomposables for light and dark variants visually match the Figma screenshot side-by-sideTechnical Notes
Scope discipline:
ScannerScreen.ktandScannerDeniedScreen.kt. Do NOT wire intoMainActivity's NavHost in this ticket — real connecting transitions arrive with CameraX in Phase 4.ScannerScreen.kt(95 LOC) andScannerDeniedScreen.kt(168 LOC) forSurface,systemBarsPadding, andPyrycodeMobileThemepreview wrapping conventions.Rendering pointers:
CircularProgressIndicator(indeterminate variant) supplies the 270° open-arc ring natively. The Figma file's hand-built 3-cubic-Bézier path is a Figma-API workaround and does not need to be replicated in Compose.get_design_context, do not guess).Size Estimate
S — single file, ~60–100 production LOC: M3 layout (Surface + Column + indicator + two text lines) wrapped in light/dark previews. No Canvas illustration, no data layer, no navigation, no DI changes.
Figma
https://www.figma.com/design/g2HIq2UyPhslEoHRokQmHG?node-id=32-20