fix: ensure user message after adding or editing a task is shown only once even after navigation #1047
Conversation
… once even after navigation
KahiloMassango
requested review from
JoseAlcerreca and
dturner
as code owners
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @KahiloMassango, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request resolves an issue where transient user feedback messages, such as confirmation of task creation or editing, would persist and reappear upon subsequent navigation within the application. By leveraging Android's SavedStateHandle, the changes ensure that these messages are properly managed and cleared after their initial display, significantly improving the user experience by preventing redundant notifications.
Highlights
- Persistent User Messages: Implemented a mechanism using SavedStateHandle to ensure user messages (e.g., "task added successfully") are displayed only once, even after navigation events.
- UI/ViewModel Separation: Refactored TasksScreen and TasksViewModel to centralize user message state management within the ViewModel, removing direct message parameters from the UI composable.
- Test Coverage: Added a new unit test to TasksViewModelTest to specifically verify that snackbar messages are cleared after being shown, preventing repeated displays.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request addresses issue #1046 by ensuring that user messages displayed after adding or editing a task are shown only once, even after navigation. This is achieved by using SavedStateHandle to persist and clear the message ID. The changes involve modifications to the TasksScreen, TasksViewModel, and TasksScreenTest files to handle the user message display logic correctly.
| LaunchedEffect(userMessageResultCode) { | ||
| if (userMessageResultCode != 0) { | ||
| viewModel.showEditResultMessage(userMessageResultCode) | ||
| } | ||
| } |
There was a problem hiding this comment.
The LaunchedEffect is now keyed by userMessageResultCode. Ensure that userMessageResultCode is properly updated and distinct to avoid unnecessary recompositions. If the same userMessageResultCode is emitted consecutively, the LaunchedEffect block will not be re-executed, which might lead to the message not being displayed if it was previously dismissed.
There was a problem hiding this comment.
The message will be displayed because the userMessageResultCode will be set to 0 after one message is displayed, then the next one will also be displayed because the code will be different from 0.
app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksScreen.kt
Show resolved
Hide resolved
...ndroidTest/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksScreenTest.kt
Show resolved
Hide resolved
This changes resolves #1046