[image_picker] Handle limit: 1 in pickMultiImage and pickMultipleMedia gracefully#11825
[image_picker] Handle limit: 1 in pickMultiImage and pickMultipleMedia gracefully#11825yashas-hm wants to merge 11 commits into
Conversation
…into fix/issue-187347-limit-1-error
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates ImagePicker to delegate to single-item pickers (pickImage and pickMedia) when pickMultiImage or pickMultipleMedia is called with a limit of 1, preventing an ArgumentError since multi-image selection requires a limit of at least 2. The changes include corresponding unit tests and a CHANGELOG update. The reviewer recommends updating the CHANGELOG entry to explicitly mention the fix for pickMultipleMedia alongside pickMultiImage.
Thanks for the contribution! You’ve checked boxes in the PR checklist above that are not reflected in this PR, so I’m assuming this is a work in progress and am marking it as a Draft. Please review the checklist, updating the PR as appropriate, and when the state of the PR as posted reflects the checklist please feel free to mark it as ready for review. |
|
@stuartmorgan-g Thank you for the review! I've bumped the version in pubspec.yaml to 1.2.3 to reflect the bug fix. The ## NEXT section in CHANGELOG.md is intentional, I followed the repository convention of leaving the placeholder for maintainers to replace at release time. Please let me know if anything else needs to be addressed. |
There was a problem hiding this comment.
Code Review
This pull request updates image_picker to delegate to single-item pickers (pickImage and pickMedia) when limit is set to 1 in pickMultiImage and pickMultipleMedia, preventing ArgumentError exceptions. It also updates the corresponding tests and bumps the package version. Feedback suggests refactoring the raw futures and ternary operators in the new delegation logic to use async/await and collection if for better alignment with Dart idioms.
I am having trouble creating individual review comments. Click here to see my feedback.
packages/image_picker/image_picker/lib/image_picker.dart (135-146)
According to Effective Dart, it is preferred to use async/await over raw futures and .then(). Additionally, using collection if is more idiomatic in Dart than ternary operators for conditional list elements.
}) async {
// limit: 1 would fail MultiImagePickerOptions validation (requires >= 2),
// so delegate to pickImage which already handles single-image selection.
if (limit == 1) {
final XFile? image = await pickImage(
source: ImageSource.gallery,
maxWidth: maxWidth,
maxHeight: maxHeight,
imageQuality: imageQuality,
requestFullMetadata: requestFullMetadata,
);
return <XFile>[if (image != null) image];
}
References
- Effective Dart: Prefer async/await over using raw futures, and prefer using collection literals with if rather than conditional operators when building collections. (link)
packages/image_picker/image_picker/lib/image_picker.dart (263-273)
According to Effective Dart, it is preferred to use async/await over raw futures and .then(). Additionally, using collection if is more idiomatic in Dart than ternary operators for conditional list elements.
}) async {
// limit: 1 would fail MediaOptions validation (requires >= 2),
// so delegate to pickMedia which already handles single-item selection.
if (limit == 1) {
final XFile? media = await pickMedia(
maxWidth: maxWidth,
maxHeight: maxHeight,
imageQuality: imageQuality,
requestFullMetadata: requestFullMetadata,
);
return <XFile>[if (media != null) media];
}
References
- Effective Dart: Prefer async/await over using raw futures, and prefer using collection literals with if rather than conditional operators when building collections. (link)
Could you let me know which specific part of the documentation led you believe that you should not change the version in the changelog, so that we can clarify that? |
Apologies, I got confused between the require version change and doesn't require version change. Updated the Changelog. |
This doesn't answer my question. Also, are you saying that you previously thought that the PR was version exempt, but then changed the version number in the pubspec.yaml anyway? As I asked above, please provide the specific parts of the docs that led you to these conclusions. |
|
I'm a first-time contributor to the repo and misread the documentation. There was no specific part that explicitly said to leave ## NEXT; it was an error in my understanding of the wording. The changelog and version have since been updated correctly. Sorry for the unclear responses! The PR is not version exempt as it fixes a bug that needs to be published on pub.dev |
I understand that. My goal is to find out what wording you misunderstood, because without knowing what wording is hard to understand, it's very hard to improve that wording. Yesterday, you read the documentation and concluded that there was a "repository convention of leaving the placeholder for maintainers to replace at release time". That's the opposite of what we want the docs are intended to convey, so clearly something in the docs is unclear. It would be very helpful if you could explain what unclear wording led to that conclusion. |
There was a problem hiding this comment.
Code Review
This pull request updates pickMultiImage and pickMultipleMedia in image_picker.dart to delegate to single-item pickers when limit is exactly 1, preventing validation errors from the platform interface. It also updates the package version to 1.2.3 and adds corresponding unit tests. The review feedback suggests explicitly validating that limit is at least 1 in both methods to avoid misleading error messages when a limit less than 1 is provided.
| // limit: 1 would fail MultiImagePickerOptions validation (requires >= 2), | ||
| // so delegate to pickImage which already handles single-image selection. | ||
| if (limit == 1) { |
There was a problem hiding this comment.
When limit is less than 1 (e.g., 0 or negative), the validation falls through to MultiImagePickerOptions.createAndValidate, which throws an ArgumentError stating that the limit cannot be lower than 2. Since limit: 1 is now supported, this error message is misleading. Explicitly validating that limit is at least 1 in the facade provides a more accurate error message.
| // limit: 1 would fail MultiImagePickerOptions validation (requires >= 2), | |
| // so delegate to pickImage which already handles single-image selection. | |
| if (limit == 1) { | |
| if (limit != null && limit < 1) { | |
| throw ArgumentError.value(limit, 'limit', 'cannot be lower than 1'); | |
| } | |
| // limit: 1 would fail MultiImagePickerOptions validation (requires >= 2), | |
| // so delegate to pickImage which already handles single-image selection. | |
| if (limit == 1) { |
| // limit: 1 would fail MediaOptions validation (requires >= 2), | ||
| // so delegate to pickMedia which already handles single-item selection. | ||
| if (limit == 1) { |
There was a problem hiding this comment.
When limit is less than 1 (e.g., 0 or negative), the validation falls through to MediaOptions.createAndValidate, which throws an ArgumentError stating that the limit cannot be lower than 2. Since limit: 1 is now supported, this error message is misleading. Explicitly validating that limit is at least 1 in the facade provides a more accurate error message.
| // limit: 1 would fail MediaOptions validation (requires >= 2), | |
| // so delegate to pickMedia which already handles single-item selection. | |
| if (limit == 1) { | |
| if (limit != null && limit < 1) { | |
| throw ArgumentError.value(limit, 'limit', 'cannot be lower than 1'); | |
| } | |
| // limit: 1 would fail MediaOptions validation (requires >= 2), | |
| // so delegate to pickMedia which already handles single-item selection. | |
| if (limit == 1) { |
2 participants
Summary
Fixes flutter/flutter#187347
pickMultiImage(limit: 1)andpickMultipleMedia(limit: 1)previouslythrew:
because
MultiImagePickerOptionsandMediaOptionsin the platforminterface both reject
limit < 2.Fix
When
limit == 1, the facade now delegates to the equivalentsingle-item picker instead of forwarding to the platform:
pickMultiImage(limit: 1)→ delegates topickImage(source: ImageSource.gallery, ...)pickMultipleMedia(limit: 1)→ delegates topickMedia(...)The result is wrapped in a single-element list, or an empty list if the
user cancelled.
limit <= 0still throws as before.Why the facade, not the platform interface
The
limit < 2guard inMultiImagePickerOptionsandMediaOptionsexists because the underlying platform multi-picker APIs genuinely do not
support selecting exactly one item, they require at least two. Relaxing
the validation in the platform interface would push the burden onto every
platform implementation to handle a case their native API may not
support, risking silent misbehaviour on some platforms.
The facade (
image_picker) is the right place for this: it already ownsthe user-facing API contract and can transparently route
limit: 1tothe well-tested single-item pickers without touching any platform code.
Tests
limit: 1delegates togetImageFromSourcewithImageSource.gallery(pickMultiImage)limit: 1delegates togetMediawithallowMultiple: false(pickMultipleMedia)limit: 0andlimit: -1still throwArgumentErrorPre-Review Checklist
[shared_preferences]///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Closes flutter/flutter#187347
Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2