[HACK][Woo POS] PR 4/5: Integrate card reader connection into WooPos screens #15072
Conversation
Generated by 🚫 Danger |
📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.
|
kidinov
changed the title
kidinov
changed the title
|
📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## woomob-1854-pr3-dialog-viewmodel #15072 +/- ##
===================================================================
Coverage 38.17% 38.18%
- Complexity 10361 10364 +3
===================================================================
Files 2173 2173
Lines 124570 124600 +30
Branches 17247 17251 +4
===================================================================
+ Hits 47560 47575 +15
- Misses 72204 72219 +15
Partials 4806 4806 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
kidinov
added
status: do not merge
kidinov
changed the title
There was a problem hiding this comment.
Pull request overview
This PR integrates card reader connection and update dialogs into WooPos screens, moving from direct facade calls to an event-driven architecture using dialog states and parent-child event communication.
Key changes:
- Connection and update operations now trigger dialog events instead of direct facade calls
- Settings and Home screens show card reader connection/update dialogs via state management
- Toolbar and totals ViewModels use connection controller for disconnect operations
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| WooPosSettingsHardwareCardReaderViewModelTest.kt | Updated tests to verify connection/update events are sent instead of direct facade calls; added controller factory mock |
| WooPosTotalsViewModelTest.kt | Updated test to verify connection dialog event is sent when reader connection is needed |
| WooPosHomeFloatingToolbarViewModelTest.kt | Updated tests to verify connection dialog events and controller disconnect usage; added controller factory mock |
| WooPosSettingsHardwareCardReaderViewModel.kt | Changed connect/update to send events; disconnect now uses controller; added controller factory dependency |
| WooPosSettingsViewModel.kt | Added handlers for card reader connection/update dialog events from child components |
| WooPosSettingsState.kt | Added CardReaderConnectionDialog and CardReaderUpdateDialog dialog states |
| WooPosSettingsScreen.kt | Added UI integration to show card reader connection and update dialogs based on state |
| WooPosTotalsViewModel.kt | Changed connect reader click to send dialog event instead of calling facade |
| WooPosHomeFloatingToolbarViewModel.kt | Changed connection to send dialog event; disconnect now uses controller; added controller factory dependency |
| WooPosHomeViewModel.kt | Added handler for ShowCardReaderConnectionDialog event and dismiss event |
| WooPosHomeUIEvent.kt | Added DismissCardReaderConnectionDialog event |
| WooPosHomeState.kt | Added CardReaderConnectionDialog dialog state |
| WooPosHomeScreen.kt | Added UI integration to show card reader connection dialog based on state |
| WooPosHomeChildToParentCommunication.kt | Added ShowCardReaderConnectionDialog event and SettingsEvent variants for connection/update dialogs |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| private val controller: WooPosCardReaderConnectionController by lazy { | ||
| controllerFactory.create(viewModelScope) | ||
| } |
There was a problem hiding this comment.
The controller is initialized lazily but only used for the disconnect operation. This means the controller won't be created until the first disconnect call, which could lead to unexpected behavior if other controller lifecycle management is expected. Consider either initializing it eagerly in the init block or documenting why lazy initialization is appropriate here.
| private val controller: WooPosCardReaderConnectionController by lazy { | |
| controllerFactory.create(viewModelScope) | |
| } | |
| private val controller: WooPosCardReaderConnectionController = controllerFactory.create(viewModelScope) |
| fun onDisconnectClicked() { | ||
| viewModelScope.launch { | ||
| cardReaderFacade.disconnectFromReader() | ||
| controller.disconnect() | ||
| } |
There was a problem hiding this comment.
The onDisconnectClicked method now uses controller.disconnect instead of cardReaderFacade.disconnectFromReader, but there is no test coverage for this functionality. Consider adding a test case to verify that controller.disconnect is called when onDisconnectClicked is invoked, similar to how the toolbar ViewModel tests verify disconnect behavior.
| private val controller: WooPosCardReaderConnectionController by lazy { | ||
| controllerFactory.create(viewModelScope) | ||
| } |
There was a problem hiding this comment.
The controller is initialized lazily but only used for the disconnect operation. This means the controller won't be created until the first disconnect call, which could lead to unexpected behavior if other controller lifecycle management is expected. Consider either initializing it eagerly in the init block or documenting why lazy initialization is appropriate here.
| private val controller: WooPosCardReaderConnectionController by lazy { | |
| controllerFactory.create(viewModelScope) | |
| } | |
| private val controller: WooPosCardReaderConnectionController = | |
| controllerFactory.create(viewModelScope) |
WOOMOB-1854
Description
Wire up the card reader connection dialog into WooPos screens:
Test Steps
RELEASE-NOTES.txtif necessary. Use the "[Internal]" label for non-user-facing changes.