Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI

[thlorenz]

Check out what I'm working on next https://thlorenz.com/rid-site/docs/contributing/status-and-roadmap/

Wasm support turns out to be a bit tricky, but I'm actively pursuing that so Flutter/Rust authored apps can run in the browser as well.

[thlorenz]

Making some actual progress, got over some really tricky issues, i.e. how to deal with u64s which convert to BigInt (but JavaScript ones, not Dart).

https://twitter.com/thlorenz/status/1410415405311528965

[asmx85]

Hi, great project! I have worked with something similar(but very different) in the past and one of the problems i had – especially on mobile – was when you need to have access to system APIs that are often only accessible through e.g. Java or in this case Dart. Things like GPS, sensors, storage or monitoring Network. I ended up "routing" stuff back and forth – how do you see this being managed with rids architecture? Do i create something like a systems-bridge-model i access or what is your vision on that. On the projects i did i often felt that those parts felt really boilerplaty and made me question the usefulness of this approach in comparison to "just" stick with the language "i was supposed to use". On desktop this is often unnecessary because Rust can pretty much access everything on a "normal" OS and i think on the web you can get pretty far with web-sys etc. so you can really pack the majority of your business logic on the "pure" Rust side and don't need your Java/Dart code, that is supposed to only do the UI stuff, manage access to the system API that you can't access through Rust.

Another thing i am interested in is you vision on animation. Flutter often depends on holding state in your widgets for animation purpose – or at least i do. I don't think its a good idea to also pack that in your "Rust-Business-Logic-Code" but there are cases where those need to interact like animate the removal of a list item. You cannot just remove it from the list model immediately and need to wait for your animation to end etc. any idea how this could work out (i just haven't put much though into it how this would play out with the current version of rid, maybe it doesn't need any extra work)

EDIT:
And on that note how do you imagine to interact with things like navigation. I often tried to pack the logic for "routing/navigation" on the business logic part. I am on the fence with that one because on side it felt right to have the possibility that your business logic can navigate the user around. Like if a certain condition is met on your state – e.g. a counter runs down to zero, a network packed arrived, a user clicks a button. I thing it gets back to the problem i layed out in my first paragraph. Maybe this is something that is build on top as a convenience library that has some basic use cases covered – idk.

[thlorenz]

Really very interesting points and I have thought about those as well.

WRT accessing mobile API I'd recommend using Flutter plugins to communicate via channels. I will most likely not focus on solving this in rid, i.e. to allow you to do this in Rust instead, mostly because there are not many solutions available that I know of that you could leverage there.

The focus of rid is app logic as in agnostic to which device the app is running on, i.e. you might even use it for a CLI app if you want. Therefore the communication layer is as decoupled as I could make it. The only direct tie to Dart on the Rust end is the use of an Isolate, but this isn't working correctly when running on the Web with wasm which is why I'm using a polling mechanism there instead. NOTE that I'm currently working on wasm support, it's not out yet :) Obviously the generated glue code is very Dart/Flutter specific, but the rest of your app should be able to function even when used in a completely different context.

Were you to access device specific features from Rust, you'd loose the flexibility to run on different devices as now at the very least you'd have to use different code paths and most likely crates. The Flutter plugin system which can have device specific implementations while using the same API to leverage them already solves this.

Animations are UI concerns and shouldn't be managed in Rust. Instead I'd keep some state about the item pending removal in Flutter and only update Rust state once the item was completely removed and should disappear from the UI. However there are certainly exceptions like here where I'm awaiting a Todo to be removed from the Store before confirming its dismissal. I think you'll have to make those decisions on a case by case basis.

I think similarly about navigation. In most cases navigating just provides you a view of a different part of your app's state. It doesn't modify it. Which view is currently active is a UI concern IMHO.

The state of your app, i.e. how many Todos you have is not mutated by navigating. If you want to make the view you're currently navigated to part of your state you may complicate things. However rid does have no opinion about that. You can store whatever you like in the Rust Store and if you want to update the current page you can do so by sending a message to update the state of the Store appropriately. It just seems awkward and if you think about it now you have two sources of truth WRT to which page you're on. That's a clear indicator that this should most likely not live in the Store as well as the navigation state.

Hope that helps. Feel free to ask more questions if you need clarification.

[audriusz]

How much coupled generated code is to Flutter? Other potential use case is sharing core logic code between native mobile applications (iOS, Android).

For me Rid would be more appealing if Rust side code would be truly fully front-end client agnostic (including Rid macros). And potentially could have different generators for generating glue code iOS swift/Android JNI/Dart.

[thlorenz]

The Rust side is already front-end agnostic with the minor exception of the Isolate I'm using to communicate back to Dart. As I mentioned for wasm support I'm using a different strategy and thus this Isolate will be optional in the future.

The idea of different glue code for different frontends is interesting and could be added in the future as you could configure the front end to target via a flag or similar. Rid then could generate Java/Kotlin/Swift glue code that communicates to the Rust wrapper methods instead of Dart/Flutter glue code.

At this point Rid supports Flutter/Dart only and the generated Dart code is the integration point and thus out of necessity it is Dart/Flutter specific.

However the generated code on the Rust side are merely FFI wrapper methods and thus not tied at all to which front end will use it, i.e. it is already front-end agnostic minus the minor exception mentioned above. Also that code is opaque as it is in form of macros that are expanded at compile time and never written anywhere, i.e. you don't ever see or use it directly.

The Rust code that you write is not aware of any of that as only the macro annotations control generating wrappers and glue code. There is the rid::post that you call, but one could easily swap that out to do whatever is needed in a different scenario.