Look into use the new Dart / Flutter FFI under development about go-flutter HOT 18 CLOSED

First, from the following Cpp code:

// filename: hello_world.cpp
#include<iostream>
#include<stdio.h>

extern "C" {
   void helloWorld() {
      std::cout<<"Hello World !"<<std::endl;
   }
}

I've compiled it:

# mac (.dylib)
g++ -dynamiclib -o ./libHelloWorld.dylib ./hello_world.cpp

# Linux (.so)  if Android, have to compile for arm64 or arm
g++ -shared  -fPIC -o ./libHelloWorld.so ./hello_world.cpp

# windows (.dll) (using TDM-GCC-64, GCC 5.1.0)
g++ -shared -o HelloWorld.dll .\hello_world.cpp

Secondly I've thrown the .dll | .so | .dylib into the go/assets directory.

Lastly using the following main_desktop.dart file

import 'package:flutter/foundation.dart'
    show debugDefaultTargetPlatformOverride;
import 'package:flutter/material.dart';

import "dart:ffi" as ffi;
import 'dart:io' show Platform;
import "package:path/path.dart" show join;
import 'dart:io';

ffi.DynamicLibrary _dlopenPlatformSpecific(String name, {String path}) {
  String fullPath = _platformPath(name, path: path);
  return ffi.DynamicLibrary.open(fullPath);
}

String _platformPath(String name, {String path = ''}) {
  if (Platform.isMacOS) return path + "lib" + name + ".dylib";
  if (Platform.isLinux || Platform.isAndroid)
    return path + "lib" + name + ".so";
  if (Platform.isWindows) return path + name + ".dll";
  throw Exception("Platform not implemented");
}

void main() {
  final libHelloWorld = _dlopenPlatformSpecific('HelloWorld',
      path: join(
        Directory(Platform.resolvedExecutable).parent.path,
        'assets/',
      ));
  final helloWorld = libHelloWorld
      .lookupFunction<ffi.Void Function(), void Function()>("helloWorld");
  helloWorld();

  debugDefaultTargetPlatformOverride = TargetPlatform.fuchsia;
  runApp(MaterialApp(home: Scaffold(body: Text("FFI!"))));
}

I call the shared lib from a flutter app (hover run) and get in the terminal output:

Hello World !

Putting the shared lib into the into the go/build/intermediates/linux (or darwin/windows) directory allows it to be persistent across hover run, the shared lib will be placed into go/build/outputs/linux/ by the hover tool-chain.

The path to the shared lib in dart Directory(Platform.resolvedExecutable).parent.path correspond to the generated assets directory.

from go-flutter.

I'll keep this issue open as a reminder.

from go-flutter.

Some examples: https://github.com/mjohnsullivan/ffi

from go-flutter.

i think that its a long way of btw. But still keep in mind long term i guess.
Pity they did not just use Protobufs i feed since so many language support it.
Maybe worth thinking about for Plugin architecture maybe

from go-flutter.

They recently released an alpha preview for developers to test.

dart-lang/sdk#34452 (comment)

from go-flutter.

Flutter Dart FFI has now landed in Master

This means you can write Flutter Plugins in golang, and compile them as a shard lib as c.
So you have none of the speed / Perf issues on Mobile. I noticed that in the last few days Android studio has NDK side by side support also.
On Desktop, you can hook in easily with the exact same shared lib cross compiled.
On Embedded, you can use Flutter and golang.
On Flutter Web, you can compile to WASM to provide a plugin, however this has not been stated by the team, but it is the likely technical roadmap IHMO.

The opportunity is that go-flutter can be the go to place for golang programmers that want to use Flutter, and by embracing the Official Flutter Desktop using FFI we have no performance issues.
We still have the best of both worlds on Desktop in that you code your plugin once and it runs on all Desktops.
Hover and that tooling can maybe transition to allow using both the GO-Flutter and the Flutter Desktop ways of doing things.

But in the end the FFI means no speed slow downs and Same code for plugins everywhere, so its going to be the way forward.

I think there are a few good libraries around to make it easy to take a golang lib and generate the golang code with the "import c" and the header lib. Gotta do some more research.
But we could use that in go-flutter to make it easy for golang programmers to keep using go-flutter since they are interested in FLutter with golang.

I hope that this is welcomed and not seen as undermining the efforts here.
Go-flutter helped me alot and Its still early days for FFI and there will be breakages with FFI still.
But we could start down this road now if we wanted to.

LINKS:

Official Example: https://github.com/dart-lang/sdk/blob/master/samples/ffi/sqlite/README.md

Use golang shared libs with Dart FFI and flutter-desktop.
Watching: https://github.com/dart-lang/sdk/projects/13

Watching: https://github.com/asyncapi/parser/blob/master/cparser/cparser.go

• For go embedded with FLutter

FFI Forum:
https://groups.google.com/forum/#!topic/dart-ffi/eYuAHy-zoC4

Mongo DB Realm using Dart FFI
https://github.com/nhachicha/realm-dart-ffi

This would mean we can use Google Official Flutter Desktop, because the Desktop Plugins API can hook into the golang shared lib.

Example of many languages hooking into golang shared lib.
https://github.com/vladimirvivien/go-cshared-examples

from go-flutter.

FFI looks very promising.

Sadly I don't have the time to take an in-depth look into it now.
I'm focusing on bug-fixes and standardization with the FDE at the moment.

If @gedw99 or anyone else is interested in FFI, please submit a PR, @GeertJohan, and I will be happy to review it!

from go-flutter.

At first I want to say I'm new to go-flutter, but I know that the project exists for some time.
I'm very used to the "official" desktop embedder, but as I was exploring the project I saw that it implements much more than the "official" embedder. That's why I'm so interested in it.

If I understood it correctly it should be possible to compile the go plugins to shared libraries and use them using the new dart FFI? Then it would be possible to use them even with the "official" embedder right?

I'm not sure why we need to compile the plugins for mobile, because almost all plugins are only for mobile yet and this project has the focus on desktop and it's plugins extend the existing plugins for mobile to desktop.

from go-flutter.

@jld3103 as my last comment said, I have no idea how dart FFI works.
My basic understanding is that the dart plugins can be made from native C source code through a binding layer.

If I understood it correctly it should be possible to compile the go plugins to shared libraries and use them using the new dart FFI?

Yes I thinks it's right, but at the moment only C/C++ integration is possible. Just to clarify, plugin made to work on dart:ffi aren't the same as flutter plugin, dart:ffi plugin by pass the flutter layer and talk directly to the dart-runtime.

Then it would be possible to use them even with the "official" embedder right?

Not sure if it's possible, but yes, from my understanding the dart:ffi has nothing to do with the flutter framework.

I'm repeating myself, but, I have absolutely no plan to work on dart:ffi support for go-flutter, it's too young at the moment.

from go-flutter.

https://github.com/dart-lang/sdk/projects/13

Looks like much more work in Dart FFI to make it less verbose to write code. Great to see this getting attention

from go-flutter.

fantastic example @Drakirus

Makes me wonder how much parity we get between Desktop and mobile now.
The Hello world example c and dart code is almost identical for Desktop and Mobile.
https://github.com/dart-lang/samples/blob/master/ffi/hello_world/c/hello.c
https://github.com/dart-lang/samples/blob/master/ffi/hello_world/hello.dart

So much easier than the current way where we write a ton of boilerplate platform channels code.
Great for very high performance critical code.

But it would be great to write these plugs in golang on Desktop and Mobile too.
All the databases written on golang like BoltDB and other golang libraries can be reused across Dekstop, mobile and even JS (https://dart.dev/web/js-interop) using gopherjs.
This is a great example. https://git.sr.ht/~eliasnaur/scatter/tree/master/cmd/scatter
So need to get the gomobile and golang code compiling.

For Desktop it should be easy:
CGO_ENABLED=1 GOOS=darwin go build -o libhelloworld.dylib -buildmode=c-shared helloworld

For Mobiles we need to match this:
https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI

from go-flutter.

Putting the shared lib into the into the go/assets directory allows it to be persistent across hover run, the shared lib will be placed into go/build/outputs/linux/assets by the hover tool-chain.

@pchampio Your setup works fine for including dynamic libraries intended to be used with FFI. But, is there any way to include assets splitted by the platform? In your solution, .so, .dll, and .dylib will all be bundled with all platforms. Any workaround for that?

from go-flutter.

If you are using a go-flutter plugin you can put the compiled library in the dlib folder (symlinks also work). Then run hover plugins get (you have to do it every time you update the compiled library) to copy the libraries to your project. Then on every run/build the library is copied from the project to the output folder so only the one for the platform you are building for/running on is copied to the output.

from go-flutter.

@pchampio maybe we should add an example for that? I already created such an project with ffi and would only need to modify minor things

from go-flutter.

@davidmartos96 The project go/build/intermediates/$OS folder has this purpose!

@jld3103 I'm still not fixed with how the plugin dlib folder work.
Sure, you can create a demo, it might no be necessary to go as far as building a plugin.
I'm sure a example with a Makefile would be fine.

from go-flutter.

@jld3103 Thanks for the response! Yes I tried using a plugin, but with my current project setup I think it won't work. I am placing custom plugins in a folder called go-plugins at the root of the git repo, so when fetching such local plugin with the dynamic libraries, it fails because it tries to fetch it from remote. Maybe that is a bug in the hover plugins get flow?
Also, wouldn't the need of calling every time plugins get be a bit error prone?

@pchampio Does that mean I can include the intermediates folder in my git repo? Or should it be ignored?

from go-flutter.

@jld3103 I'm still not fixed with how the plugin dlib folder work. #311

@davidmartos96 yep, go/build/intermediates/$OS is what you are looking for.

from go-flutter.

Please check #498
For a golang FFI example.

from go-flutter.