Closed bltavares closed 4 years ago
Note: The dart:ffi library is in beta, and breaking API changes might still happen.
Using the feature requires a Flutter 1.10.x dev channel build. To switch to the dev channel and upload the latest dev version, do the following
I got it compiled with FFI linking after being able to setup my android env.
I'm getting signal aborted on Rust:
2020-02-09 23:14:46.531 12329-12370/com.example.colmeia_native_example D/eglCodecCommon: setVertexArrayObject: set vao to 0 (0) 1 0
2020-02-09 23:15:08.030 12329-12400/com.example.colmeia_native_example A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 12400 (async-std/execu), pid 12329 (_native_example)
This seems to be caused when the app blocks the UI thread. Investigating what could be done from Dart side instead of going to Java JNI
The error happens when it panics.
We can request information and open sockets correctly, but it panics somewhere inside colmeia.
Logging has been added for android to debug.
Panic through FFI is undefined, and should not happen. We must have a catch_unwind
to avoid panics.
iOS is working, now it needs to fix the socket panicking when running (socket closes, tries to write, when it tries to write to itself).
For posterity:
or 64-bit and iPhone OS applications, there is a linker bug that prevents -ObjC from loading objects files from static libraries that contain only categories and no classes. The workaround is to use the -all_load or -force_load flags.
-all_load forces the linker to load all object files from every archive it sees, even those without Objective-C code. -force_load is available in Xcode 3.2 and later. It allows finer grain control of archive loading. Each -force_load option must be followed by a path to an archive, and every object file in that archive will be loaded.
It should happen on the desktop as well.
Tracking issue to make it easier to package pre-built binaries on Flutter: https://github.com/flutter/flutter/issues/33227
Flutter Desktop plugin is only stable for Mac apps. Windows and Linux are possible, but things could change. It should be as viable as any tho
I would like to test if it is possible to ship a embedded Dat engine into a mobile app.
Talking to friends, I've learned that iOS does not ship with any
exec
-like API, so it would not be viable to ship a binary there.After taking a look on Dart FFI, I'm considering testing it directly with FFI. The effort to build a Flutter + binary application seems to be on the same league as pushing a Flutter + ffi sample.
This test intends to do the following:
Left as another PR in the future:
The steps of evolving this sample would be, IMO: