[image_picker] Update README for image_picker's retrieveLostData() to support multiple files

[reez12g]

issues fixed by this PR

• Update image_picker readme flutter#89722

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I listed at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[mvanbeusekom]

Hi @reez12g, thank you for the PR. Please make sure you update the CHANGELOG.md and pubspec.yaml files. Since the README is mostly read on pub.dev, updating the README.md is therefore considered a change that needs to be published and requires the patch number to be updated.

Also I feel the example code shown in the README is confusing and could be written in a better way (see comment).

[mvanbeusekom]

This example looks a bit confusing, as when dealing with multiple files it simply stores the list in the _imageFileList variable, while when dealing with a single file it is calling the _handleVideo() or _handleImage() method and updating the state (as per setState call). Seems these situations are handles very differently. Maybe you can update the code to a more simple example:

    if (response.files != null) {
      for(final XFile file in response.files) {
        _handleFile(file);  
      }
    } else {
      _handleError(response.exception);
    }

The above example simply shows how to handle lost data and leaves it to the implementing users to decide how to handle the files that are retrieved.

[reez12g]

@mvanbeusekom
Thank you so much for your very thoughtful comments!
The example you wrote was very clear.
I've taken it in as a commit!

[reez12g]

Hi @reez12g, thank you for the PR. Please make sure you update the CHANGELOG.md and pubspec.yaml files. Since the README is mostly read on pub.dev, updating the README.md is therefore considered a change that needs to be published and requires the patch number to be updated.

Also I feel the example code shown in the README is confusing and could be written in a better way (see comment).

Thanks for the comment! I'll check it out!

[reez12g]

Hi @reez12g, thank you for the PR. Please make sure you update the CHANGELOG.md and pubspec.yaml files. Since the README is mostly read on pub.dev, updating the README.md is therefore considered a change that needs to be published and requires the patch number to be updated.
Also I feel the example code shown in the README is confusing and could be written in a better way (see comment).

Thanks for the comment! I'll check it out!

I updated the CHANGELOG.md and pubspec.yaml.

[mvanbeusekom]

LGTM

[mvanbeusekom]

@reez12g could you maybe rebase your PR on the master branch in an attempt to fix the failing build steps?

[reez12g]

@mvanbeusekom

@reez12g could you maybe rebase your PR on the master branch in an attempt to fix the failing build steps?

It's done! Thank you very much.

However, the submit-queue is failing.
How can I solve this problem?

[reez12g]

@mvanbeusekom

@reez12g could you maybe rebase your PR on the master branch in an attempt to fix the failing build steps?

It's done! Thank you very much.

However, the submit-queue is failing.
How can I solve this problem?

@mvanbeusekom
I'm sorry.
I've been waiting for a while, and the builds all succeeded...!

[mvanbeusekom]

However, the submit-queue is failing.
How can I solve this problem?

Thank you for rebasing @reez12g, looking good now. The submit-queue step indicates if the code on the master branch currently is passing all CI tests. If it is not the submit-queue task will fail to prevent merging more code changes to an already faulty code base. In this case it looks like a flaky test is causing the problem and should pass when the build has re-run.

This is nothing related to your PR, I will add the wait for tree to go green label which will inform the Google Bot to automatically merge this PR when all is green.

[reez12g]

However, the submit-queue is failing.
How can I solve this problem?

Thank you for rebasing @reez12g, looking good now. The submit-queue step indicates if the code on the master branch currently is passing all CI tests. If it is not the submit-queue task will fail to prevent merging more code changes to an already faulty code base. In this case it looks like a flaky test is causing the problem and should pass when the build has re-run.

This is nothing related to your PR, I will add the wait for tree to go green label which will inform the Google Bot to automatically merge this PR when all is green.

I understand now!
Thank you so much for your kindness!

[ditman]

This was merged before a fix for our CI landed, so even though the change has been correctly pushed to pub.dev, a tag for this failed to publish into the repo. This is not a big deal, but I just wanted to let you know why this is red in master.

The fix for CI has landed (right after this commit), so from now on the release action should be able to publish and tag new plugins.

Apologies for the inconvenience!

[reez12g]

I understand! Thank you for taking the time to tell me!

[ditman]

Thanks again for the fix, keep them coming! 🙏