[flutter_blue] Add support for bluetooth communication

[jtmuller5]

There is an existing 3rd party plugin called flutter_blue that lets you communicate through bluetooth on Android and iOS. I think adding Tizen support to this plugin would make Tizen wearable apps significantly more valuable.

On a related note, is there any way to communicate between a wearable device and a mobile phone using Flutter for Tizen? I'd like to be able to communicate in real time across the devices (for example, tapping a button on the watch to play or pause a video on the phone.

Thanks for the Flutter support!

[swift-kim]

Yeah, the bluetooth support is indeed important for Tizen devices and we need to implement as soon as possible.

@flutter-tizen/maintainers @rookiejava Do we have any plans or on-going work for these items?

1. Generic bluetooth APIs (flutter_blue)
2. Samsung Accessory Protocol (SAP)

[rookiejava]

Thank you for reaching us! I think we can proceed within next month if there are no other issues. 😉

[bbrto21]

Is there any progress?

[swift-kim]

@bbrto21 Nope :/

[bbrto21]

Currently I am implementing geolocator, I think it is almost done.
if you don't mind, I have a plan to develop this plugin after finish work

[JRazek]

@bbrto21 Is there any progress. Would you mind if I started development on this plugin?

[bwikbs]

@JRazek
I guess @bbrto21 says ok becasue he is busy! 😄

[bbrto21]

@JRazek Ok
I couldn't do anything because of another task assigned to me :(

[NowLoadY]

I'm sorry to bother you@JRazek , but I want to know if the Bluetooth plugin has made any progress.
: )

[JRazek]

@NowLoadY Yes, I'm currently preparing a PR.

[NowLoadY]

@NowLoadY Yes, I'm currently preparing a PR.

I'm looking forward to it very much😍, because I'm planning to make a program that uses a watch to control the RC car. And I know nothing about how to write a flutter-tizen library.🥲
Thanks for your reply again！

[MrCsabaToth]

Please use https://github.com/boskokg/flutter_blue_plus as a base for support because the old flutter_blue plugin seems to be not maintained any more

[HakkyuKim]

@MrCsabaToth
Thanks for the info, we're aware that flutter_blue is not maintained and flutter_blue_plus is the successor of the project.

I'm working on other issues at the moment, I'll look into this once that's done.

[MrCsabaToth]

I'm working on other issues at the moment, I'll look into this once that's done.

I also have to add that there's no guarantee that at some point in future the boskosg fork won't be abandoned. But in case that would happen hopefully some other fork would become maintained and mainstream then. flutter_blue_plus has some unresolved issues on iOS, which doesn't affect me yet, I'm not sure if that's important from your perspective. But every plugin has issues and I guess flutter_blue_plus is the most widely tested today.

Also note that all (or most) of the Flutter Bluetooth plugins I saw were BLE only, so Bluetooth Low Energy / a.k.a. Bluetooth Smart only. If you need to support non BLE Bluetooth devices then you'll need to look for a different plugin.

I'm constantly surveying the Flutter Bluetooth plugin space (TrackMyIndoorWorkout/TrackMyIndoorWorkout#210).

There's a BLE plugin maintained by Phillips Hue: https://pub.dev/packages/flutter_reactive_ble I haven't ever tested it though. The question is if its main use-case is smart bulbs and smart home then how much it can handle higher data rates. It seems to be relatively popular, and maybe Phillips presence is a slight guarantee that it won't be abandoned. It is mobile only (Android + iOS) just like the boskosg flutter_blue_plus. There's also a third one I never tested: https://pub.dev/packages/flutter_ble_lib, that's also mobile only.

If you compare those three by popularity then don't look at the flutter_blue_plus's likes, but instead look at the https://github.com/boskokg/flutter_blue, because that has 700+ likes and the fork became official not too long ago, so people haven't migrated that much yet from the flutter_blue over to https://github.com/boskokg/flutter_blue_plus.

If desktop support is important to you (maybe desktop Linux support is closer to a Tizen support, or you just want to look at how it's done for Linux), then https://github.com/woodemi/quick_blue has desktop support. The Linux support essentially revolves around BlueZ.

[HakkyuKim]

Thanks for sharing your detailed survey!

It's unfortunate that there's not yet a "go to" bluetooth plugin for Flutter comapred to audio plugins like just_audio or audioplayers.

Also note that all (or most) of the Flutter Bluetooth plugins I saw were BLE only, so Bluetooth Low Energy / a.k.a. Bluetooth Smart only. If you need to support non BLE Bluetooth devices then you'll need to look for a different plugin.

Recent devices more or less support BLE along with classic Bluetooth, this is especially true for embedded devices where battery is important (except TV but it does support BLE to communicate with other battery operated embedded devices). Tizen devices support BLE protocol hence the current bluetooth plugin interfaces in the Flutter ecosystem is sufficient for our case.

There's a BLE plugin maintained by Phillips Hue: https://pub.dev/packages/flutter_reactive_ble ...

I've recently discovered flutter_reactive_ble here but haven't looked closely yet. I'm not sure implementations would have changed when the plugin focuses on smart bulbs and smart home since it would internally just use BLE APIs provided by Android and iOS frameworks, but I would have to look into it.

There's also a third one I never tested: https://pub.dev/packages/flutter_ble_lib ...

I haven't heard of flutter_ble_lib, but this plugin seems abandoned (the latest release was 20 months ago). I did check quick_blue a while back, but it didn't seem to be actively maintained.

If desktop support is important to you (maybe desktop Linux support is closer to a Tizen support, or you just want to look at how it's done for Linux), then https://github.com/woodemi/quick_blue has desktop support.

Directly using the Linux plugin for Tizen devices is an option if every API used internally doesn't rely on hardware modules. Tizen have its own version of bluetooth API and I can't guarantee that those APIs are all built on top of Linux's basic bluetooth stack, it would be safe to implement a Tizen plugin that uses its own bluetooth API.

With the current information, I would consider supporting either flutter_blue_plus or flutter_reactive_ble for Tizen.

[HakkyuKim]

I've tried implementing bluetooth with ffi and tizen_interop, it doesn't seem to work when dart has to register callbacks to C code:

[E] ../../third_party/dart/runtime/vm/runtime_entry.cc: 3766: error: Cannot invoke native callback outside an isolate.
version=2.18.0 (stable) (Fri Aug 26 10:22:54 2022 +0000) on "linux_arm64"
pid=5585, thread=5585, isolate_group=(nil)((nil)), isolate=(nil)((nil))
isolate_instructions=0, vm_instructions=7f6767b400
[E]   pc 0x0000007f677b5360 fp 0x0000007fcbf31c50 /proc/self/fd/26/lib/libflutter_engine.so+0x9a4360
-- End of DumpStackTrace
onSigabrt called

According to here, dart does not support function calls when C runs that function outside of the main thread.

[MrCsabaToth]

I've tried implementing bluetooth with ffi and tizen_interop, it doesn't seem to work when dart has to register callbacks to C code:

[E] ../../third_party/dart/runtime/vm/runtime_entry.cc: 3766: error: Cannot invoke native callback outside an isolate.
version=2.18.0 (stable) (Fri Aug 26 10:22:54 2022 +0000) on "linux_arm64"
pid=5585, thread=5585, isolate_group=(nil)((nil)), isolate=(nil)((nil))
isolate_instructions=0, vm_instructions=7f6767b400
[E]   pc 0x0000007f677b5360 fp 0x0000007fcbf31c50 /proc/self/fd/26/lib/libflutter_engine.so+0x9a4360
-- End of DumpStackTrace
onSigabrt called

According to here, dart does not support function calls when C runs that function outside of the main thread.

From what I read what that issue says is that the thread which calls back should be the same thread. In case of that issue the original thread was the main thread, that's why the calling back thread has to be also main. But if the 1st thread is not main the calling back thread could be also that different thread. I don't have time to inspect this in more detail now. Other bluetooth ffi plugins exist, such as https://github.com/woodemi/quick_blue Linux support, so I'd peek into how they implement.

[swift-kim]

@HakkyuKim It's a well known issue. flutter-tizen/tizen_interop#10

In case of that issue the original thread was the main thread, that's why the calling back thread has to be also main.

Note: The original thread is a UI thread. https://github.com/flutter/flutter/wiki/The-Engine-architecture#ui-task-runner

[HakkyuKim]

@MrCsabaToth
I've posted the issue so I could share with other maintainers of the project, but thanks of keeping track with the issue :)

It could be that Linux's bluetooth functions and registered callbacks runs on a single thread. Some Tizen's API run callbacks on a second thread and that seems to be the issue here.

[swift-kim]

I'm going to implement flutter_reactive_ble instead of flutter_blue_plus, because flutter_blue_plus lacks a stable platform interface and can only be implemented implicitly via message channel + protobuf, which is subject to change at any time without guarantee of backward compatibility.

I'll open a PR in this repo as soon as PhilipsHue/flutter_reactive_ble#688 is published.

[MrCsabaToth]

Maybe I'm wrong but don't Flutter Reactive BLE use ProtoBufs as well? https://github.com/PhilipsHue/flutter_reactive_ble/tree/master/packages/reactive_ble_mobile/protos

Regardless: thanks for the work

[swift-kim]

@MrCsabaToth Its mobile implementation (reactive_ble_mobile) is based on protobuf but the platform interface itself (reactive_ble_platform_interface) has nothing to do with protobuf. I used platform channels to implement the platform interface for Tizen.

[MrCsabaToth]

@MrCsabaToth Its mobile implementation (reactive_ble_mobile) is based on protobuf but the platform interface itself (reactive_ble_platform_interface) has nothing to do with protobuf. I used platform channels to implement the platform interface for Tizen.

I see! Cool!

[swift-kim]

Unfortunately the flutter_reactive_ble project is dead. There's no maintainer for the repo. No code review for 4 months. Nobody cares about open issues.

[MrCsabaToth]

Sorry to hear. I was hopeful that since Phillips is behind it due to Phillips Hue, it won't get to that point. Let's hope a maintainer will pop up and it'll be active again. Because the only other viable project is flutter_blue_plus which sprung up from the quasi abandoned flutter_blue but flutter_blue_plus has now a ton of outstanding PR as well lately. The Dart 3.0 changes will cause a "purge" where it'll be clear which projects have the resources to upgrade. Same thing with upgrading form the older method channels plugin interface and be able to be federated / FFI.

[swift-kim]

@MrCsabaToth Thank you for showing your interest! I hope flutter_blue_plus will migrate to the federated architecture soon so that we can implement its platform interface for Tizen.

[swift-kim]

https://github.com/search?q=repo%3Aboskokg%2Fflutter_blue_plus+protobuf&type=commits

Looks like flutter_blue_plus has recently migrated from protobuf to a pure method channel-based implementation so we can now extend the plugin for Tizen by implicitly implementing its interface. The interface still doesn't follow semantic versioning so hopefully the plugin should migrate to the federated architecture to ensure there's no sudden API break.

[JMaroz]

@swift-kim is there any news? When we can expect a release?

[swift-kim]

The author of flutter_blue_plus has explicitly mentioned that he will not migrate the plugin to federated. It will be quite a maintenance burden for us to track the method channel API changes if we implement the plugin without a stable platform interface.

I don't think I'll have time to implement this for a while, but maybe someone else will. Please feel free to contribute if anyone is interested (you can either reuse some code from #542 or write it from scratch).

[chipweinberger]

Hi, maintainer of flutter_blue_plus here.

Correct, I don't want the extra complexity of federated.

But the method channel interface will be very stable going forward. The library has stabilized a lot. I think it would be viable to fork flutter_blue_plus and just implement a new platform using the platform channel only.

with all the work i've put into it, flutter_blue_plus is clearly, by far, the best BLE library for flutter.

I've pretty much ran out of ways to improve it.