[Feature]: develop new CoreBluetooth & AndroidBluetooth packages

[chipweinberger]

What is your feature request?

Linux & Web are very clean, because they use their own Dart wrappers before FBP.

I think we should follow the same approach, and make clean packages for CoreBluetooth for Darwin and AndroidBluetooth for Android.

These would be written as if FBP doesn't even exist, and would just faithfully expose every detail of CoreBluetooth and Android Bluetooth to Dart.

[chipweinberger]

@ekuleshov @tnc1997

Can I interest you in this work? We could get to delete a lot of ugly code!

[ekuleshov]

@ekuleshov @tnc1997

Can I interest you in this work? We could get to delete a lot of ugly code!

What's the idea?

[chipweinberger]

Basically, develop the equivalent of WinBle and BlueZ but for darwin (CoreBluetooth) and android (AndroidBluetooth).

As a very nice bonus, if users ever want to do something special, they could just call, for example:

await AndroidBluetooth.startRssiUpdates(device, interval: 1s);

that way they can use FBP where needed, but still access the full options of the OS at any time.

[ekuleshov]

Personally I think winble is a horrible idea... Not really sure what would this solve other than exposing some low level static helpers. But you could expose them in the current code too.

Imho making a new style ffi bindings for each platform to avoid platform channels would be a better investment.

[chipweinberger]

Imho making a new style ffi bindings for each platform to avoid platform channels would be a better investment.

Sure! That would be an implementation detail of CoreBluetooth or AndroidBluetooth. They could be implemented in any way.

[chipweinberger]

exposing some low level static helpers.

Not just static functions. You could access the devices, send BLE writes, do L2CAP directly and avoid GATT overhead, do anything really. All you need are the remoteIds.

[ekuleshov]

Not just static functions. You could access the devices, send BLE writes, do L2CAP directly and avoid GATT overhead, do anything really. All you need are the remoteIds.

What's stopping current platform plugins do that?

[chipweinberger]

You and I both know nothing is "stopping" the current code from doing that. No need to be annoying.

IMO would be cleaner. I don't want to clutter FBP with tons of platform specific code.

But if you are not interested, it's fine. I just wanted to ask. No need to debate all the merits.

[ekuleshov]

But if you are not interested, it's fine. I just wanted to ask. No need to debate all the merits.

Didn't mean to be annoying. Just not sure what another layer of abstraction would buy.

The BlueZ is somewhat different, as it is a platform level-service on Linux and Dart's plugin is simply a wrapper for it.

[chipweinberger]

My bad, sometimes tone is hard to read.

Just not sure what another layer of abstraction would buy.

Cleaner code, IMO. I like the web & linux code more than Android & iOS.

Being able to expose platform specific code without touching FBP is just a plus. Especially now that we have the platform interface, it's pretty clunky to add lots of platform specific code IMO.

[ekuleshov]

I always took it as an inheriting complexity of these platforms. So, I hope the new FFI plugins approach would help.

• https://docs.flutter.dev/platform-integration/android/c-interop
• https://codelabs.developers.google.com/codelabs/flutter-ffigen#0
• [path_provider] Convert iOS/macOS to FFI package flutter/packages#9762

[chipweinberger]

Ya I like the idea, especially for Darwin.

For Android there isn't a C api for Bluetooth, so you'd need glue code from C to Java. Probably more trouble than its worth, but worth looking into.

You'd also need to check if FFI can handle the callbacks. I'm not sure what thread they run on.

[ekuleshov]

For Android there isn't a C api for Bluetooth, so you'd need glue code from C to Java. Probably more trouble than its worth, but worth looking into.

I gave a bad example for Android... The Dart team is cooking some new stuff. I'd suggest to keep an eye on those activities and see how things unfold for platform plugins. They will be converting them to new architecture

• https://github.com/dart-lang/native/tree/main/pkgs/jnigen/example

[wadetb]

Just wanted to add 2c to this ticket from a user perspective - having spent much of the past two weeks fighting to make BLE work "well" using flutter_blue_plus and other packages- first on Linux and then on Android.

When choosing a cross platform framework like Flutter one of the greatest risks is loss of "native" qualities, being able to make the apps work just as well as the native ones - and platform APIs like BLE and MIDI are prime examples.

While abstractions like flutter_ble_plus are super helpful to get started, there is always a fear they're not following some 'low level best practice' for any given target platform, due to the constraints and preferences of the cross-platform abstraction that they choose to provide.

In my case, I started on Linux and struggled to make my device (an Adafruit Feather ESP32S3) connect consistently with FBP - it scans fine but fails to transfer data consistently via the UART service. I fought with it for quite a while, then tried UniversalBle, similar but different issues, then tried Bleak via Python - which worked perfectly and strongly encouraged me to abandon Flutter. Then I had an "aha" moment and tried deploying to my Android phone, and FBP started working perfectly. Unfortunately my UART data rates are still terrible, ~1KB/s while the Adafruit Bluefruit Connect app easily hits 10x that, and I don't yet know why - so I have put FBP into my local_packages so I can play around with the Java code and try to find the root case. (And maybe I'll go back and try to work out what's going wrong on Linux as well). This kind of difficulty unfortunately leads to a lot of "package shopping", maybe UniversalBle works better? Or maybe reactive_ble? Or one of the other 9 packages?

The point of explaining this story is that if I could easily dive down past your abstraction into the platform layer, I'd have the assurance that I can test whether the issues I'm encountering on a given platform are:

1. Due to choices / shortcomings in FBP's abstraction
2. My own code logic bug
3. Some fundamental misunderstanding of BLE's or the hardware's capabilities.

And where there is some platform API that isn't exposed yet, not having to fork FBP and maintain a local branch would be really nice.

It seems like the the stuff the Dart team is building could really help to address this issue by making standardized and convenient ways to access native platform APIs from Dart. If this happens then "abstraction" APIs like FBP could become a lot simpler (less code to bind) and better choices (less risk of missing platform functionality).