flutter_rust_bridge
flutter_rust_bridge copied to clipboard
Support for opaque boxed types
I have a pretty complex type that does not translate (and I don't want to) to flutter. Normally if I didn't have this amazing lib I'd keep a pointer on the Flutter side (as an integer) and call Rust methods passing the pointer and the args. I could not see anything on the docs about the opaque type technique I did before on Flutter. I came up with this idea which is a bit ugly but should work:
// Do not use this on Flutter side
struct ComplexType {
complex_type_1: ...,
complex_type_2: ...
//...
}
// Use this on the dart side
pub struct ComplexTypeOpaque {
inner: Box<dyn Any>
}
impl ComplexTypeOpaque {
fn do_something(&self, simple_supported_type_1: SimpleSupportedType1) {
//downcast inner into ComplexType, call stuff
}
}
Is there a better way currently?
Well, Box<dyn Any> won't work also
There's #293, but it's still WIP.
Personally I use object pools: https://github.com/fzyzcjy/flutter_rust_bridge/pull/333
P.S. #333 is already used in production in my app. It is WIP only because the users have to copy-and-paste those code into their own codebase currently - which is not that elegant so I do not merge PR
@fzyzcjy the opaque idea is very nice, would be nice to get it merged. I just tested. PS: didn't you get https://github.com/fzyzcjy/flutter_rust_bridge/pull/293#issuecomment-1169366921?
Cancelable tasks look great also, gonna take a try.
PS: which copy-paste code? The trait implementation?
@lattice0 The problem of opaque is that it is not safe currently, and challenging to make it completely safe. Surely we never want to ship code with memory bugs to users of Rust - such a safe language :)
PS: which copy-paste code? The trait implementation?
copy cancel_token.dart, cancel_token.rs etc
Ok, just understood. Personally I prefer opaque types as there's no handle search every time a function call is made. I don't know how this Opaque is implemented but I think it should be faster (even though it doesn't matter for most projects). I used to use handles before when I used my own handwritten implementations but started using opaque types after.
It would be nice to have both of them merged. I wish I could do it but I'm still learning how this lib works. Maybe in the future, but currently I'm gonna be stuck with the Opaque PR old version.
I also don't understand why cancel_token.rs cannot be in the dependency that is already included in the project, as well as the dart version.
Also, what are the safety concerns with opaque?
I wish I could do it but I'm still learning how this lib works. Maybe in the future
Take your time and looking forward to PR :)
I also don't understand why cancel_token.rs cannot be in the dependency that is already included in the project, as well as the dart version.
https://github.com/fzyzcjy/flutter_rust_bridge/pull/333#issuecomment-1037079219
Also, what are the safety concerns with opaque?
See my discussions at that PR
also /cc @Desdaemon
I tried to merge the new stuff into https://github.com/fzyzcjy/flutter_rust_bridge/pull/293 but couldn't make it work. I've ran into https://github.com/fzyzcjy/flutter_rust_bridge/issues/344 because my branch is old, but running:
flutter pub run build_runner build --delete-conflicting-outputs
gives
[INFO] Succeeded after 85ms with 0 outputs (0 actions)
so it does not change anything.
I'm learning how syn works and maybe I can help more, but currently I was unable to merge (wouldn't compile after carefully merging some conflicts in how I though it should work)
I think the only things missing for this lib to be perfect for my app are opaque types and methods
#293 is still not mature, and I am worried even if you can use it you will sometimes encounter very weird and hard-to-debug bugs because it is not safe yet.
If you are willing to contribute and finish that PR, feel free to discuss with @Desdaemon who made that great PR
Ok I was able to merge at least: https://github.com/lattice0/flutter_rust_bridge/tree/opaque-redux-merge
now gonna understand more of the lib and also which unsafety problems we have with this approach. Thank you all!
@lattice0 You are welcome and looking forward to your progress!
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.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.