Creating a dart-only library with a flutter library on top of it

[GregoryConrad]

Hello!

Many packages out today have a dart-only base, and then a flutter package built on top of it (think riverpod). I was wondering how that would look with flutter_rust_bridge, if possible.

Here is what I was thinking of making:

1. Low level dart-only package wrapping around a rust library (should be easy enough, will not support web)
2. Low level flutter package that depends on and re-exports dart-only package 1 and provides some flutter-only abstractions to make working with package 1 easier (will not support web)
3. High level dart-only package that depends on package 1 that makes it easier to work with in state management solutions (might support web, but not through rust)
4. High level flutter package that depends on packages 2 & 3 (essentially a combination of the 2). This one would be used by most end users (might support web, but not through rust)

Is this sort of setup possible (with all rust bindings exclusively in package 1)? How would this look amongst all packages? Any other caveats I should be aware of?

I am mostly wondering how package packages 2 & 3 would need to look. 1 & 4 should be trivial enough (I think?).

[fzyzcjy]

have a dart-only base, and then a flutter package built on top of it

Same in my internal app indeed.

As for web - flutter_rust_bridge does support web, so guess will not have trouble about that.

Is this sort of setup possible (with all rust bindings exclusively in package 1)?

Yes, works well in my internal app

For me, I combine 1+3 and 2+4, so there is only a dart package and a flutter package

[dinbtechit]

@GregoryConrad I had the exact same question. I am trying to build a "Dart only" library and use that library to build a flutter library on top of it.

I am glad to see that you got it successfully working on android, ios, and macOS. Are you able to post an example git repo with some step-by-step instructions on how you got it working? It would be massively helpful. 🙏🙏

[GregoryConrad]

@dinbtechit I got it working with every platform so far but web (web is still a TODO--need to see if I can get it working with WASI/wasmer-js hopefully, and if not, then the libc @coder0107git linked). I frankly think I could write a novel on everything I learned through the process--it was a lot more in depth than I was hoping to go. You will want a repo structure and tooling very similar to what I have in mimir for your project.

You can see my working implementation at https://github.com/gregoryconrad/mimir. I even threw CI integration tests in there (for every platform but android--the android reasoning is a bit complicated) so I know it is constantly working for all supported platforms. Here's a quick summary:

Note: my solution relies on distributing the binaries separately alongside a GitHub release. this is necessary because pub.dev has a hard 100mb upload limit, which my binaries would not fit into. This complicates things a lot, but I still got it working! Also, you are not supposed to upload binaries to pub.dev anyways, so I would recommend going with my approach.

Another note: I also set up my project to allow cross-compiling to all platforms from any platform, which is super convenient (except iOS/macOS have to be built on a Mac. I am using one though so I didn't bother researching into that area more). Take a look at my CONTRIBUTING.md to see system requirements for building. Also see my GitHub ci workflows to figure out how to build/publish releases automatically.

Apple platforms

After some research, it appeared that an XCFramework is the current recommended approach for distributing cross-platform/architecture libraries. I also use static libraries for iOS/macOS in the XCFramework since that seemed to be the best approach for the platforms. Thus, I made a build-apple.sh script that creates said XCFramework and zips it up. iOS/macOS use the exact same podspec file because of this, and thus I think it is the right approach. Take a look at packages/flutter_mimir/ios/flutter_mimir.podspec to see how it works!

Android

I compile all my android code into an .aar (which is actually just a .zip with a certain dir structure) which I then distribute thru GitHub release. Android was a bit unique since it directly references the file from my GitHub releases using an "ivy repository". For the other platforms, I download the binaries/XCFramework if they aren't already present and then process them. For android, this wouldn't be as simple. I can cover why in a future post but just know this decision was made with thought behind it. This is also why my CI cannot test android.
See build.gradle and the build-android.sh script to see more on how this works.

Windows/Linux

Thankfully, windows and linux are super super simple because they both use CMake and are fairly similar. Take a look at the CMakeLists.txt in windows/linux (they differ slightly). Also, see the build-other.sh script for how to cross compile to either platform and archive the results.
Note: Windows is only supported for the windows-x64 target right now, so you only need to build an x86_64 target for windows.

Sorry this write up is kind of brief/raw thoughts, but it should be enough to get you started. I am a bit time constrained right now, but maybe if there is interest I could PR this repo and add some documentation about the entire process there, because I think it could be super helpful so nobody would have to go thru the hours of platform-specific debugging and research I did...

[dinbtechit]

@GregoryConrad - omg! A massive thank you. This is very insightful!!!!! 🙏🙏🙏🙏

P.S You should totally write that novel hah. Also, that's an interesting database you got going there. Typo text search wow! 🙌

[GregoryConrad]

@dinbtechit I'll be working on #899 over the next several days and should have it done within a week or two. Should help you and others to get started.

[dinbtechit]

This is going to be super helpful!!! Thank you soo much. I am looking forward to it!!

[GregoryConrad]

Once #899 is merged, documentation should be available on this in the user guide!

[dinbtechit]

This documentation is a lifesafer. Found some minor issues tho.

In https://cjycode.com/flutter_rust_bridge/library/dart_only.html

There is a version mismatch - between pubspec.yaml and cargo.toml. This is causing compile errors in generated dart code, bridge_generated.io.dart unable to resolve type - WireSyncReturnStrut. This can be fixed by upgrading the frb dependency to 1.61.* in cargo.toml. However, we will also need to update the build.rs file as described below.

flutter_rust_bridge: ^1.61.0

 [build-dependencies]
 flutter_rust_bridge_codegen = "1.56.*"        <<---<< Update this to 1.61.*

 [dependencies]
 flutter_rust_bridge = "1.56.*"       <<---<< Update this to 1.61.*

To fix the above issues update the following in the initiation script -> documentation.

1. The following line in the script to fix the build.rs file:

   let raw_opts = RawOpts {
       rust_input: vec![RUST_INPUT.to_string()],
       dart_output: vec![DART_OUTPUT.to_string()],
       c_output: Some(vec![IOS_C_OUTPUT.to_string(), MACOS_C_OUTPUT.to_string()]),     <<---<<  replace this 
       c_output: Some(vec![IOS_C_OUTPUT.to_string()]),            <<---<<  with this 
       inline_rust: true,
       wasm: true,
       ..Default::default()
   };

2. And update the versions to 1.61.*

    [lib]
    crate-type = ["staticlib", "cdylib"]
   
    [build-dependencies]
    flutter_rust_bridge_codegen = "1.61.*"
   
    [dependencies]
    flutter_rust_bridge = "1.61.*"
    EOF

Now you can do cargo build without any errors.

[GregoryConrad]

A PR with those changes would be welcome! One thing to note: you won't be generating the C header for macOS anymore; you will need something like this at the bottom of build.rs:

    // Copy ios/ generated C files to macos/
    std::fs::copy(IOS_C_OUTPUT, MACOS_C_OUTPUT).unwrap();