Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support integrating with C/C++ in plugin framework #7053

Open
jtrunick opened this issue Nov 28, 2016 · 157 comments

Comments

@jtrunick
Copy link

commented Nov 28, 2016

It would be nice to have an example of calling C/C++ code, or at least how to build native code along with a Flutter app. This may purely a Gradle question, but its not clear to someone that's not an expert on Gradle (for example, me), how to pull this off.


Admin comment: Please see dart-lang/sdk#34452 for current status and additional information

@chinmaygarde

This comment has been minimized.

Copy link
Member

commented Nov 30, 2016

@jason-simmons knows the most about Gradle. Once we have an .so, I can definitely help getting it loaded.

@jtrunick

This comment has been minimized.

Copy link
Author

commented Dec 2, 2016

I did find that under buildSrc there is another property for setting the gradle build version. After updating to 2.2.2 I've progressed, and was able to verify the .so loads, and is callable from Java.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2016

Presumably we would also need to add a C API for sending HostMessages from C/C++ code to Dart.

@jtrunick

This comment has been minimized.

Copy link
Author

commented Dec 6, 2016

Yes please. I have a suspicion that the C->Java callback may not be cheap.

@mit-mit mit-mit added the p: framework label Feb 2, 2017

@mit-mit mit-mit changed the title C/C++ Example Support integrating with C/C++ in plugin framework Feb 2, 2017

@mit-mit mit-mit added this to the 4: Make shippers happy milestone Feb 2, 2017

@ijustlovemath

This comment has been minimized.

Copy link

commented May 20, 2017

Any update on this? Considering Flutter for building a cross platform app that calls C++ code compiled into a shared library, and this is the only major stopping point.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

commented May 21, 2017

This is possible today (and @jtrunick did so in his shipping app), but you have to bounce through Java or Obj-C first.

i.e. you can use https://flutter.io/platform-channels/ to talk from Dart to Obj-C/Java and then from Obj-C/Java call into your C++ code. This bug covers adding more direct support for this, and potentially avoiding the Obj-C/Java passthrough.

@timotheecour

This comment has been minimized.

Copy link

commented Sep 20, 2017

Since Dart VM is implemented in C++ shouldn't there be an easier (if less safe) way to call C shared libraries directly (say via dlopen) ? How much change would be required for basic (unsafe/experimental) support?

Is something like this: https://www.dartlang.org/articles/dart-vm/native-extensions available on android or ios?

@mehmetf

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2017

We have heard this requirement from a couple of Google apps:

  • One such app wrote their own C++ libraries for operating the camera to reduce latency. These libraries are platform specific and optimized to work as quickly as possible. Invoking these libraries with the lowest possible latency is critical for such apps. Forcing them to go through PlatformChannel + JNI will not achieve that on Android.

  • There are advanced mobile teams out there who write business logic components in C++ to be able to share it between their Android and iOS implementations. Flutter supporting direct integration with those libraries would further cement its position of being the best cross-platform framework out there.

I don't think this is a must have. However, this is one area that Flutter can further differentiate itself from other cross-platform solutions.

@Hixie

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2017

One such app wrote their own C++ libraries for operating the camera to reduce latency. [...] Forcing them to go through PlatformChannel + JNI will not achieve that on Android.

What was their solution on Android for getting from C++ to Java and back?

@chinmaygarde

This comment has been minimized.

Copy link
Member

commented Oct 2, 2017

If it is really necessary, we can allow Dart native extensions on the mobile platforms. Right now, we don't expose the symbols in dart_api.h. We will need to decide on the following before we can flip the switch:

  • Figure out how to make the AOT compiler aware of Dart code whose sole entry point is from a method that may not be in the main Flutter engine dynamic library. Otherwise, the tree shaking pass may get rid of the code.
  • Provide guidance on building and packaging native extensions (Gradle & Xcode for Android & iOS respectively).
  • Provide some ABI stability guarantees for the routines in dart_api.h. Though it is mostly stable, I believe it is still evolving to account for the various modes.

So far, the platforms channels mechanism seems to have been adequate for the simpler use cases.

@mehmetf

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2017

What was their solution on Android for getting from C++ to Java and back?

I have not looked deeply into their use case. It seemed that they have written all the bits that need very low-latency communication in C++. I will ask whether they use any JNI for performance-critical use cases (my gut feeling is no).

It really depends on what we can do on Flutter side. If we can supply an interop that's significantly faster than JNI, it would be a big win for these teams. They can shrink their C++ codebase and shift more to the app side. If our interop performance is comparable to JNI then I don't see a big win here. They could probably continue what they are doing now and use PlatformChannel.

This is about giving such teams an extra reason to switch to Flutter. I have not heard of this being a blocker, so prioritize accordingly.

@Hixie

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2017

If I understand what you're saying correctly, you're saying current solutions are to have all the logic (camera+UI) in C++ with minimal logic in Java, and the desire is to move the UI part of this logic to Dart, without losing the low-latency UI<->camera interactivity.

@Hixie

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2017

Can you talk about what their threading situation is like? Do they just have the one thread for camera+UI?

@sethladd sethladd referenced this issue Oct 3, 2017
@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2017

@chinmaygarde might move us closer to solving this with his current work on the embedder API.

@binoypatel

This comment has been minimized.

Copy link

commented Nov 11, 2017

+1

@WoodyGuo

This comment has been minimized.

Copy link

commented Dec 28, 2017

Any progress with this issue?

We've already been using djinni to share logics across different platforms. It would be great if we can have interop between Dart and C++, rather than having to go back and forth through Java/Objc-C.

@loint

This comment has been minimized.

Copy link

commented Jan 23, 2018

If Dart can integrate with C/C++ I think it's a great idea for mobile to re-use a ton of native library and no need binding to a specific platform using JNI or Objective C++.

@nielsenko

This comment has been minimized.

Copy link

commented Mar 1, 2018

Have you considered https://github.com/mono/CppSharp? They already have the parsing and AST in place for c++, as well as support for multiple target languages. Perhaps you could create a Dart generator for CppSharp?

@ikangming2017

This comment has been minimized.

Copy link

commented May 16, 2019

How can I add c++ code on Flutter app?

@archanpaul

This comment has been minimized.

Copy link

commented May 17, 2019

How can I add c++ code on Flutter app?

I guess right now only option is to take C++ -> JNI (for Android) -> PlatformChannel way till we have more elegant way to do the same!!

@prsolucoes

This comment has been minimized.

Copy link

commented May 18, 2019

I created a project called ezored (http://ezored.com). Will be nice if i can pass complex objects to Flutter without need convert to other thing, since it is already in java and objc. Anyone can use ezored to generate the SDK (or download prebuilt) to test Flutter integration between native and Dart. It has requests, parsing, crud using database and lot of things in demo SDK already implemented.

I search in flutter groups but don't have any way to pass the objects and list of objects to Flutter direct.

Thanks in any help.

@sjindel-google sjindel-google self-assigned this May 20, 2019

@fzyzcjy

This comment has been minimized.

Copy link

commented May 21, 2019

Any new progress? It seems that more than 2.5 years have passed...

@dcharkes

This comment has been minimized.

Copy link

commented May 21, 2019

@fzyzcjy we're working on it. We've released an early preview. See dart-lang/sdk#34452 (comment) on how to get involved.

Since this early preview we've added support for Intel 32, Arm 64, and Arm 32. These platforms are not yet released on stable or dev, they are only available on the master branch of the Dart sdk. Progress is being tracked here.

@fzyzcjy

This comment has been minimized.

Copy link

commented May 22, 2019

@dcharkes So happy to hear that! Thanks for your great work!

@Stone2517

This comment has been minimized.

Copy link

commented May 27, 2019

Any Progress?

@mit-mit

This comment has been minimized.

Copy link
Member

commented May 27, 2019

For status updates and additional information, please see dart-lang/sdk#34452. The top-most comment there has the most recent update.

@Hixie Hixie modified the milestones: May 2019, December 2019 May 28, 2019

@luca992

This comment has been minimized.

Copy link

commented May 29, 2019

When using flutter to create a web app, will using ffi with a c library be possible?

@mit-mit

This comment has been minimized.

Copy link
Member

commented May 29, 2019

When using flutter to create a web app, will using ffi with a c library be possible?

That is not likely. Theoretically longer-term it could be supported using WebAssembly, but that is not something we are currently working on.

@buuug7

This comment has been minimized.

Copy link

commented Jul 22, 2019

@mit-mit really ?

@nic-hartley

This comment has been minimized.

Copy link

commented Jul 29, 2019

When using flutter to create a web app, will using ffi with a c library be possible?

That is not likely. Theoretically longer-term it could be supported using WebAssembly, but that is not something we are currently working on.

Why would it require WebAssembly? If you can ask people to rebuild to WebAssembly in the future, you can ask them to rebuild to ASM.js now.

@sjindel-google

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

@nic-hartley It's good idea, but the challenge is not how to compile the native code, it's in creating the bridge between Dart (compiled as JS) and the native code, whatever form it takes.

The native FFI is very low-level for performance reasons and cannot easily be translated into asm.js or WebAssembly.

@sjindel-google

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

To clarify, I mean that our implementation is very low-level -- it's certainly an interesting feature, but it would take considerable work to deliver.

@microcai

This comment has been minimized.

Copy link

commented Aug 7, 2019

flutter is only a toy until it supports c++

@MarkIngramUK

This comment has been minimized.

Copy link

commented Aug 9, 2019

I've come here to echo the same points by others, that until Flutter can easily interop with C++ (with no bridge library, and no performance penalty) it will never be adopted by large scale applications with investments in existing native libraries, or applications where performance is the highest priority.

@Hixie

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

I'll note that even React Native uses a bridge currently, so it appears that Flutter is actually ahead-of-the-curve in terms of trying to implement a FFI.

Integration with C++ is trivial on iOS with AppKit. That's what we should be comparing against, not React Native.

@MarkIngramUK

This comment has been minimized.

Copy link

commented Aug 11, 2019

UWP & C++ is trivial too.

@atsushieno

This comment has been minimized.

Copy link

commented Aug 12, 2019

I'm in general for "support Dart FFI effort" party too, though...

Xamarin might be a more appropriate comparison than UWP, but Xamarin's cross platform views weren't nearly as customizable as Flutter's and often required a lot of native code to get looking decent.

This is not true. Unlike Flutter, Xamarin has platform bindings to native API (i.e. Xamarin.iOS and Xamarin.Android), and it's easy for app developers to write platform-specific implementation in its own language (C#/.NET). This issue is about language feature and should not be mixed with UI widget API design.

There is a lot of native API uses, but no native code invocation, where Flutter would be on the same boat (although Xamarin does not require writing Java or ObjC there, with no reflection hack in app code). For native code, even at Xamarin.Android itself (one of the backend platform backends) the use of native code is very little, and app developers write no native code.

And unlike React Native or Xamarin, Flutter is to provide its complete framework, so it is entirely fair point of view that we compare the entire Flutter framework with things like AppKit.

@vladest

This comment has been minimized.

Copy link

commented Aug 12, 2019

its weird that noone even mention Qt framework which is far ahead everything else regarding C++ integration

@srmanc

This comment has been minimized.

Copy link

commented Aug 12, 2019

@vladest

This comment has been minimized.

Copy link

commented Aug 12, 2019

Qt is C++ and QML (JS engine)
What license? LGPL? GPL? what is wrong with it?

@rmtmckenzie

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

First off IANAL, but as I understand it most of Qt is LGPL (the IDE etc are GPL), which means that it has language that while not expressly forbidding static linking, makes it difficult to do while still adhering to the licence if your application is closed-source.

Technically, if you use only LGPL and provide your object files (and probably instructions) so that users could potentially re-link against a different version of the library, you're satisfying the requirements of the LGPL. But I'm pretty sure the Qt Company doesn't advertise that fact, so the common conception is that you can't deploy static libraries which means you can't get your app released on the app store without paying their extortionate licensing fees. And I may be wrong about providing object files, that's just my understanding of it, and I don't know if any companies are doing that.

Android is easier because it does allow dynamically loaded libraries which are more explicitly allowed under the LGPL, but in all honestly static linking would probably be preferable there too to keep the app size down which means running into the same issue.

@MarkIngramUK

This comment has been minimized.

Copy link

commented Aug 12, 2019

Hi @cpboyd , I think I'm looking at this from the opposite direction. We already have apps built on platform specific UI frameworks, where each platform allows us to utilise our vast collection of existing C++ libraries. I understand Flutter is cross-platform, which is great, but unless I can actually use it (with my existing code), then I'm better off just sticking with non-cross-platform UI. The only sticking point comes when a future OS (e.g. Fuchsia) requires the use of Flutter & Dart, but doesn't allow for this use-case. In that case it's likely to be ignored by anyone with large existing codebases.

I guess I'm not sure whether Flutter / Dart are being designed with "web" apps (i.e. where backends are on the web) in mind, or serious consideration is being given to the needs of professional desktop application developers. Ultimately decisions like this can affect the number of, and quality of, many applications on an app store. If I can write a high quality professional app for iOS using UIKit, utilising millions of lines of existing code, but I can't (with near-zero performance cost) if I'm developing for Fuchsia / Flutter / Dart, then that would be an OS & platform that I wouldn't develop for.

The aim of my posts is not to compare Flutter to other cross-platform or non-cross-platform libraries, it's to highlight use cases that are important to a subset of developers.

The Dart FFI is interesting, from the very brief read of the sqllite example, it looks similar to C# with PInvoke, but unfortunately that's not suitable for C++, as either nearly every type you deal with would need wrapping, or you would have to write some fully generic type-less interface system to wrap the C++. Neither of those are particularly appealing when you compare it to the ease of the following Obj-C class:

#include <mylib/mytype.h>
@implementation MyView
{
    MyLib::MyType *_pMyType;
}
@end

Or UWP with C++/WinRT:

#include <mylib/mytype.h>
class MyUserControl : public UserControl
{
    MyLib::MyType *_pMyType;
};

Thanks :-)

@Hixie @MarkIngramUK Neither of those are cross-platform, which was my point.
AppKit is Apple-only, while UWP is Windows-only.
Perhaps if Flutter had used Swift or C# instead of Dart, then we'd already have the same level of support, but that's an entirely different argument.
Xamarin might be a more appropriate comparison than UWP, but Xamarin's cross platform views weren't nearly as customizable as Flutter's and often required a lot of native code to get looking decent.
My suggestion still remains: If you want to use Flutter with C++, you should participate in the Dart team's FFI preview and help improve support for all of us 😃

@cpboyd

This comment has been minimized.

Copy link

commented Aug 12, 2019

This issue is about language feature and should not be mixed with UI widget API design.

@atsushieno Sure, and that's why this discussion would be more productive on the Dart FFI forum... Flutter is the framework. Dart is the language.

Neither of those are particularly appealing when you compare it to the ease of the following Obj-C class:

@MarkIngramUK I'm sure that's exactly the kind of feedback that the Dart team would love to see over at https://groups.google.com/forum/#!forum/dart-ffi

@prsolucoes

This comment has been minimized.

Copy link

commented Aug 12, 2019

I have a project called ezored (https://ezored.com) that is a C++ bootstrap project for SDKs and applications in C++. We are using in mobile projects (android and iOS). Im waiting for FFI be finished to create a project that will use the default SDK into flutter.

We don't have any problems with C++ and the time of dev new features are reduced, since the SDK has the same code into all platforms, as you can see in the default implementation (poco project, openssl, sqlite, specific platform code integrated with bridge code etc).

In my option this is the best way:

  • iOS and Android with C++ backend (ezored)
  • Flutter and C++ as backend

Feel free to add a start to the project :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.