MVVM Refactor Phase 1: App shell, Settings and Home - #49
kara-melvin wants to merge 16 commits into
Conversation
…hot message as state helper).
…e DI bindings in GlobalApp.kt. This wraps both prefs files (settings/project_mesh_prefs) and exposes StateFlows from prefs with single-writer setters.
…s. Removed redundant coroutine calls/navigation code. Tested on 1 physical device.
…nActivity still uses its old state). AppViewModel is the first consumer of StateViewModel.
…now route through SettingsRepository setters, Home collects deviceName and the server-restart toast lives in a temporary Settings-composable. MainActivity's setContent block is rewritten onto AppViewModel with collectAsStateWithLifeCycle, deep-link parsing and LocalUtil.applyLocale. Device test works.
…server restarts. Toasts are migrated to userMessage state. SettingsScreen drops all 6 callbacks and collects our new immutable state. AppNavHost's Settings composable collapses to SettingsScreen().
…sly from SettingsRepository before launching.
…el. This left AppViewModel with no userMessage producer. We pulled out the dead code.
…Model + 4 loose stateflows. deviceName and concurrency_supported now mirror SettingsRepository. HomeScreen loses its deviceName param, StartHomeScreen loses its viewModel default param
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
To my understanding, this is just a more uniform way for each screen to work with its corresponding ViewModel, so the screens shouldn't be changed to any extent that would affect my audit? |
|
I agree with Tomas, this seems like a uniform communication between each screen and its ViewModel, with a UIState and public entry points. The only thing that I see that affects audit/design work is the small change on line 63 in BottomNavHost.kt that changed the label pixel size from 7.5 to 10.5. |
|
Based off the fact that seemingly the home and settings screen will be affected the most, its still safe to say the the app will work similarly as the old one, at least from the outside point of view. I see that Kara's addition of SettingsRepository fixes data managment, and how the structure of the program was shifted though SettingsScreenViewModel. The app should still behave like the old version, since none of the changes would signal the user that things did in fact change yes? |
|
Observation: doesn't seem to change any UI/behavior on my end, just confirms the app is still on SharedPreferences for now. |
5 participants
Migrates the app shell (AppViewModel), SettingsScreen, and HomeScreen to the new StateViewModel
single-immutable-state pattern.base class and UserMessage (one-shot messages as state)