uno
uno copied to clipboard
unoplatform
StorageFileHelper - Add GetFilesInDirectoryAsync
GitHub Issue (If applicable): closes #
PR Type
What kind of change does this PR introduce?
- Feature
What is the current behavior?
The StorageFileHelper just have one method for Determines if an asset or resource exists within application package. But could be a nice feature to retrieves the paths of files within a directory.
What is the new behavior?
So this PR is for allow to retrieves the paths of files within a directory based on a specified filter for file extensions (If null, all files in the directory are considered.) And the result is an array of strings containing the paths of the filtered files within the directory.
PR Checklist
Please check if your PR fulfills the following requirements:
- [ ] Docs have been added/updated which fit documentation template (for bug fixes / features)
- [x] Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
- [ ] Validated PR
Screenshots Compare Test Runresults. - [ ] Contains NO breaking changes
- [ ] Associated with an issue (GitHub or internal) and uses the automatic close keywords.
- [x] Commits must be following the Conventional Commits specification.
Other information
Internal Issue (If applicable):
@nickrandolph Can you confirm if you agree with the code? @jeromelaban Can you take a look and comment or direct someone?
🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-16341/index.html
🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-16341/index.html
@jeromelaban one of the questions we had here is whether we can make StorageFileHelper public. We need to access it, so we can either make it public or internal, with internals access granted to the appropriate library. Thoughts?
@jeromelaban one of the questions we had here is whether we can make StorageFileHelper public. We need to access it, so we can either make it public or internal, with internals access granted to the appropriate library. Thoughts?
I think public is preferable even if it is not intended for usage by users, as we can then more easily avoid making unintended breaking changes when we were to adjust naming some other first-party library depends on for example
@jeromelaban one of the questions we had here is whether we can make StorageFileHelper public. We need to access it, so we can either make it public or internal, with internals access granted to the appropriate library. Thoughts?
What do you need from storage helper?
