-
Notifications
You must be signed in to change notification settings - Fork 440
feat(dialog) - Support picker mode for open dialog (#3030) #3034
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
base: v2
Are you sure you want to change the base?
Conversation
Package Changes Through 20193f6There are 4 changes which include dialog with minor, dialog-js with minor, updater with minor, updater-js with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
27c84df to
845795e
Compare
b1b6214 to
1407271
Compare
For iOS and Android, there are 2 distinct file picker dialogs, one for picking media and one for picking documents. Previously, the filters provided by the user would determing which picker would be displayed. However, this has led to undefined behavior when no filter was provided. To resolve this, we now provide a PickerMode (meant for iOS and eventually Android) to explicitly define which picker we want to display. Eventually, we may need to provide more explicit ways of filtering by MIME type or having specific modes for ImagePicker or VideoPicker for ease of use on mobile platforms. But for now, this is an initial implementation that allows specifying which UI would be preferable for a file picker on mobile platforms.
1407271 to
8e13e98
Compare
|
@onehumandev We have a couple of test failures due to Swift code which is targeting APIs > iOS 13. Note: We may be able to raise the minimum version since iOS 14+ is the default for Tauri applications created with Tauri CLI v2.8 and above. This is also used by the NFC plugin. |
@velocitysystems It looks like the NFC docs say that the min version is iOS 14, but actual declared min version is 13 . For this MR, what is the preferred option: bumping the min version to 14, or changing the current implementation to work with iOS 13? I don't mind either way, but I'd rather not make a significant change without getting a consensus. |
|
Thanks @onehumandev. To retain compatibility let's keep the minimum iOS version at 13; unless we have a very specific reason to bump the min SDK version. |
81a9d3d to
8e13e98
Compare
|
@lucasfernog @velocitysystems I've started working through making some changes to fix the compilation errors with iOS 13.0, and I wanted to make sure I understand the expectation for these plugins (especially for future work). Specifically: What defines the expected iOS deployment target for plugins? I see that the NFC plugin has some specific statements stating that the min version is 14, which would indicate that this is not standard. The reason I am asking about this is that I was unable to reproduce the compilation issue on this MR for iOS 13.0 until I locally changed the If that is expected, that is fine as well, and I can work with that :) I would then like to publish a separate MR to the docs or guidelines explaining how the expected min versions for plugins are determined (for both iOS and Android). I just want to make sure I understand if this is a defined expectation that all plugins support iOS 13.0 (and any higher deployment target is an exception), or if the deployment target is determined on a case-by-case basis. Thanks! Related discussion for NFC plugin: #1876 |
This. There's a baseline and individual plugins may increase that if needed. I think our baseline is still considered to be 13.0 in the plugins even if new projects now target 14.0 by default. Not sure if we consider this a breaking change so changing the baselines may have to wait till v3. |
For iOS and Android, there are 2 distinct file picker dialogs, one for picking media and one for picking documents.
Previously, the filters provided by the user when calling the
openmethod would determine which picker would be displayed.However, this has led to undefined behavior when no filter was provided.
To resolve this, we now provide a PickerMode (meant for iOS and eventually Android) to explicitly define which picker we want to display.
Eventually, we may need to provide more explicit ways of filtering by MIME type or having specific modes for ImagePicker or VideoPicker for ease of use on mobile platforms.
But for now, this is an initial implementation that allows specifying which UI would be preferable for a file picker on mobile platforms.
Related bug #3030