Unwrap ProfilesDesign

[Goooler]

Refs #119.

[Copilot]

Pull request overview

This PR continues the “split Design to @Composable + ViewModel” refactor (Issue #119) by removing the ProfilesDesign abstraction and migrating the Profiles feature to a Compose screen driven by a dedicated ProfilesViewModel.

Changes:

• Introduce ProfilesViewModel to own Profiles UI state, lifecycle-driven fetching, and one-shot UI events.
• Refactor ProfilesScreen into a ViewModel-backed composable (and rename the pure UI portion to ProfilesContent).
• Simplify ProfilesActivity from DesignActivity coroutine/event loop into a plain BaseActivity hosting Compose content.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
app/src/main/kotlin/com/github/kr328/clash/profile/vm/ProfilesViewModel.kt	New ViewModel managing profile list state, update actions, and snackbar/navigation events.
app/src/main/kotlin/com/github/kr328/clash/profile/ui/ProfilesScreen.kt	Replaces ProfilesDesign with ProfilesScreen + ProfilesContent, adds snackbar handling and lifecycle observer wiring.
app/src/main/kotlin/com/github/kr328/clash/profile/ProfilesActivity.kt	Converts to Compose setContent hosting ProfilesScreen, removing the old DesignActivity loop.

Comments suppressed due to low confidence (2)

app/src/main/kotlin/com/github/kr328/clash/profile/ui/ProfilesScreen.kt:93

• showSnackbar(...) is called directly inside LaunchedEffect(eventState) and consumeEvent() is executed only after the snackbar suspends/finishes. If the activity is recreated (e.g., rotation) while the snackbar is showing, the ViewModel survives and eventState may still be ShowMessage/ShowEditableMessage, causing the snackbar/navigation to be replayed. Consider consuming/resetting the event before awaiting showSnackbar, or launching showSnackbar in a separate coroutine (as done in MainScreen) so the event is cleared immediately.
  app/src/main/kotlin/com/github/kr328/clash/profile/ui/ProfilesScreen.kt:271
• The profile row is made clickable while the RadioButton has onClick = null, so TalkBack/keyboard users won’t get proper radio-button semantics (selected state + role) for the whole row. In this repo, radio/checkbox rows use Modifier.selectable(..., role = Role.RadioButton) / toggleable(..., role = Role.Checkbox) (e.g. ProxyDesign.kt and AccessControlScreen.kt). Consider switching the row modifier to selectable with selected = profile.active and role = Role.RadioButton, and wire the click through consistently.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (3)

app/src/main/kotlin/com/github/kr328/clash/profile/ui/ProfilesScreen.kt:92

• SnackbarHostState.showSnackbar(...) is a suspending call; handling it directly inside LaunchedEffect means viewModel.consumeEvent() won’t run until the snackbar completes. This can leave the event “stuck” across recompositions/config changes and can delay processing subsequent events. Consider launching the snackbar in a separate coroutine (or consuming the event before awaiting the snackbar) similar to how MainScreen handles long snackbars.
  app/src/main/kotlin/com/github/kr328/clash/profile/ui/ProfilesScreen.kt:99
• In the editable snackbar branch, showSnackbar(...) suspends while waiting for user action/dismissal, so the consumeEvent() call after the when is delayed. This can cause the ShowEditableMessage event to be re-handled after a configuration change and can block newer events from being handled promptly. Consider consuming the event immediately and running the snackbar interaction in a child coroutine (keeping event.uuid captured locally).
  app/src/main/kotlin/com/github/kr328/clash/profile/ui/ProfilesScreen.kt:124
• ProfilesContent uses MihomoScaffold, which already supports a snackbarHost slot. Placing SnackbarHost outside the scaffold (aligned manually in a wrapping Box) can lead to inconsistent insets/positioning and duplicates the layout pattern used elsewhere (e.g., LogcatContent passes snackbarHost into MihomoScaffold). Consider threading a snackbarHost lambda into ProfilesContent and passing it to MihomoScaffold instead of overlaying it here.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.