-
Notifications
You must be signed in to change notification settings - Fork 28.9k
Add CupertinoPicker
ticking sound
#170641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I am not sure about tests on the platform side, I haven't found any existing sound or haptic tests for iOS for instance. Maybe I haven't looked hard enough :) |
0b2ea23
to
3230d95
Compare
3230d95
to
4b18fec
Compare
Compiling the engine was an adventure :) |
4b18fec
to
47cbed8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM on Android since this is a no-op
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi! I'm a grad student working on a research project about using large language models to automate code review. Based on your commit 47cbed8 and the changes in engine/src/flutter/shell/platform/android/io/flutter/embedding/engine/systemchannels/PlatformChannel.java, my tool generated this comment:
- Add a check at the beginning of the
fromValue
method to throw anIllegalArgumentException
ifencodedName
is null. - Ensure that the
encodedName
forTICK
is defined somewhere in the codebase. IfTICK
does not have a correspondingencodedName
, it could lead to issues when trying to retrieve it using thefromValue
method. - It is crucial to have unit tests that cover the new
TICK
value. Ensure that there are tests that validate the retrieval ofTICK
using thefromValue
method, as well as tests that confirm the behavior when an invalidencodedName
is provided. - Ensure that the
fromValue
method correctly returnsSoundType.TICK
for the input"SystemSoundType.tick"
. Also, include tests to verify that it throws aNoSuchFieldException
for invalid inputs. - Add a test to verify that
SoundType.TICK
is present in the enum and has the correct associated string value. - Add tests for edge cases, such as passing
null
or an empty string to thefromValue
method, to ensure proper handling. - The
fromValue
method iterates over all enum values to find a match. IfSoundType
is expected to grow significantly, consider using aMap<String, SoundType>
to store the mappings of encoded names to enum values for O(1) lookup time. This would improve the efficiency of thefromValue
method.
As part of my research, I'm trying to understand how useful these comments are in real-world development. If you have a moment, I'd be super grateful if you could quickly reply to these two yes/no questions:
- Does this comment provide suggestions from a dimension you hadn’t considered?
-
- Do you find this comment helpful?
Thanks a lot for your time and feedback! And sorry again if this message is a bother.
Hi @dcq01! Maybe the reviewers of this PR will have different opinions, but I usually don't feel that reviewing individual commits is particularly useful, since a commit (at least in my workflow) is not a self-contained piece of work. I usually expect reviews to work over the whole PR to see all changes in context of other changes. As for the actual comments, I feel like for such a small change all the suggested tests are a bit overkill. Some of them (like 2 and 5) are strange, since I have never seen a test that tests if a member of an enum is in the enum. Overall, in my opinion, not that useful. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general LGTM with some minor comments. Thank you for working on this!
This PR adds a ticking sound to the
CupertinoPicker
on iOS.Fixes #37329
Pre-launch Checklist
///
).