-
Notifications
You must be signed in to change notification settings - Fork 258
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
Support for @Native #1849
Comments
Sure! Indeed when developing the initial version of v2, I do think about this. However, it was (and still is?) experimental. Therefore, I want to wait a little bit until it is stablized. Or, do you have reasons to do it now (I am happy to hear!)? There is no need to worry as an end user: This is just implementation details of flutter_rust_bridge, and when it is switched to the new API, users usually do not need to change things, and flutter_rust_bridge will just generate new code. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Is your feature request related to a problem? Please describe.
Darts (experimental) native assets feature abstracts away the resolution and loading of binaries. They can be resolved using an asset id with the new
@Native
API:flutter_rust_bridge
still usesDynamicLibrary
to load functions, which will not receive support for resolution of native assets, as described by dart-lang/sdk#49803 (comment).Describe the solution you'd like
Regarding the eventual goal of native assets being one of the main methods to bundle binaries, I propose to generate bindings using
@Native
instead ofDynamicLibrary
. Maybe first behind an experimental feature.Describe alternatives you've considered
There is currently no way to accurately resolve a shared library, bundled with native assets, in every scenario.
The text was updated successfully, but these errors were encountered: