[Feature]: Web Bluetooth Support

[diegobes]

FlutterBluePlus Version

all

Flutter Version

all

What OS?

All

OS Version

Supported Chrome

Bluetooth Module

any

What is your feature request?

With Chrome ( behind flag ) supporting Web Bluetooth standard, This can be a great addition for Flutter Web Development.

If anyone is interested please let me know

Logs

Chrome Web BLE support:
https://developer.chrome.com/docs/capabilities/bluetooth?hl=en

Web Bluetooth W3C Spec:
https://webbluetoothcg.github.io/web-bluetooth/

[chipweinberger]

feel free to open a PR!

[chipweinberger]

Just some thoughts. To keep all the platform code similar, we should simulate the API of a platform channel, even though we don't actually need one.

in _invokeMethod

if (Platform.isWeb) {
    out = await FlutterBluePlusWeb.invokeMethod(method, arguments);
} else {
    out = await _methodChannel.invokeMethod(method, arguments);
}

in _initFlutterBluePlus

if (Platform.isWeb) {
    FlutterBluePlusWeb.setMethodCallHandler(_methodCallHandler);
} else {
    _methodChannel.setMethodCallHandler(_methodCallHandler);
}

[chipweinberger]

I've started on web support: master...feature/web-bluetooth-support

I implemented startScan. It should be pretty straightforward to implement the rest, if someone wants to.

[tnc1997]

I implemented startScan. It should be pretty straightforward to implement the rest, if someone wants to.

Hi @chipweinberger, thank you for your work on this package!

I hope you don't mind, I have implemented the web platform, based on your initial branch.

What is the recommended approach for testing the web implementation?

[chipweinberger]

thats awesome. No recommended approach. Just try to test everything :)

[chipweinberger]

your code looks good. I think stopScan should be a no-op, not unsupported.

also, please update the readme. etc.

[tnc1997]

your code looks good. I think stopScan should be a no-op, not unsupported.

also, please update the readme. etc.

Thank you for your feedback, I have refactored stopScan to be a no-op, and also updated the readme.

[chipweinberger]

@tnc1997 recently created a PR for Web: #964

However, FBP plans to remain Android/iOS/Mac only for the foreseeable future.

If you'd like to add web support, please do it via wrapper (example: https://pub.dev/packages/flutter_blue_plus_windows).

I'll keep this issue open until someone creates a wrapper for Web.

[tnc1997]

An in development fork of Flutter Blue Plus that supports web using a platform interface is available here.

Please note that this unofficial fork is not endorsed by Chip Weinberger and is supported on a best efforts basis.

I would like to thank Chip Weinberger for their ongoing work on the existing Android/iOS/macOS package.

[yaing11]

Hello @chipweinberger . Thank you for your work on this plugin. Do you have plans to add platform_interface to your plugin? If you want to remain Anroid/iOS/Mac support , no problems. Just add platform interface, please, as it did our friend @tnc1997 .

[chipweinberger]

@yaing11 , this repo will never support other platforms or a platform interface. It's just not a good use of my time. Sorry.

But I encourage you to create & maintain your own flutter_blue_plus_web repo, and I'll link to it.

You could even create your own flutter_blue_universal package with platform_interface support, and use flutter_blue_plus for your android/iOS/macOS implementation.

[yaing11]

Ohhh, @chipweinberger. It's a pity, but you won't spent your time. Let me create PR where I will add platform interface to your plugin and you still continue support ONLY 3 platform as you want. It's modern solution and Google recommends to use platform interface in a plugin develoment.

[chipweinberger]

thanks,

but please create your own pub.dev package and add the platform interface to your package. You can call it flutter_blue_universal perhaps

I will not add a platform interface to this package.

Why? I don't want to maintain it as each platform evolves.

[yaing11]

You could even create your own platform_interface, and use this repo as your android/iOS/macOS implementation.

I've already created but it needs to sync with your repo each time. It's not good. My app supports 6 platforms - android,ios, macos, linux, web, windows,

[yaing11]

Why? I don't want to maintain it as each platform evolves.

@chipweinberger You will maintain only your platforms , but with platform_interface. There is no need to maintain platform_interface because it's created only once....

[tnc1997]

Hi @yaing11, it's great to see your interest in a platform_interface for flutter_blue_plus.

You may be interested in the previous discussion that we had in this Pull Request for context.

[chipweinberger]

platform_interface because it's created only once

That's not really true. Every year the BLE APIs change slightly, and the platform interface needs to change too. For example, iOS 17 added autoconnect support, which gets passed to the platform now. Android changed how FINE_LOCATION permission works, which also needs to be passed. If I added web, linux, and windows, the platform interface will be constantly changing. It's just not a responsibility I want, or will be good at keeping up to date.

Which is why I recommend you create your own package.

[yaing11]

I've already created but it needs to sync with your repo each time. It's not good. My app supports 6 platforms - android,ios, macos, linux, web, windows,

@chipweinberger as I wrote my app supports 6 platforms, but for android, ios, macos i want to use your solution because it's very good and if we have platform interface we will have more clean solution.

[chipweinberger]

@chipweinberger as I wrote my app supports 6 platforms, but for android, ios, macos i want to use your solution because it's very good and if we have platform interface we will have more clean solution.

I understand. I recommend you create a new package flutter_blue_universal, and I'll link to it in my readme. Perhaps @tnc1997 would help too.

If it becomes popular, everyone can migrate to it.

[yaing11]

.....................and the platform interface needs to change too. For example, iOS

@tnc1997 many thanks that you joined to our discussion. Do you agree with what @chipweinberger wrote ?

[tnc1997]

Perhaps @tnc1997 would help too.

You are welcome to use this unofficial fork of Flutter Blue Plus that supports additional platforms using a platform interface and is supported on a best efforts basis.

[chipweinberger]

@tnc1997 , wow! your fork has come a long way! You really ought to give it a proper new name!

[tnc1997]

Do you agree with what @chipweinberger wrote?

In theory the platform interface wouldn't need to change if a platform specific implementation changes, however it would need to change if an interface method changes (for example if fields are added/removed to/from a request model).

[chipweinberger]

@tnc1997 , if you give it a new name (so it's easier to distinguish), I'll link to it in the FBP readme.

[tnc1997]

@tnc1997 , if you give it a new name (so it's easier to refer to), I'll link to it in the FBP readme.

Thank you very much for your kind words, it currently uses the same name so that developers only need to update the dependencies in their pubspec.yaml file, without having to modify all the import statements throughout their application.

[chipweinberger]

Fair point. What about just a more distinguished repo & package name? You could still use FlutterBluePlus as your api entrypoint for users.

flutter_blue_plus_universal

[tnc1997]

flutter_blue_plus_universal

That would still require developers to update all the import statements throughout their application with the different package name (flutter_blue_plus_universal).

One of the aims of the fork is that developers can use it as a drop-in replacement whilst making the minimum amount of changes to their application as possible.

[chipweinberger]

True. It's your fork so do what you wish.

But IMO that's rather trivial. Just make it clear in your README. For example (from flutter_blue_plus_windows):

I'd love to link to your implementation. I just don't want it to complicate what "flutter_blue_plus" refers to. IMO needs a proper name. Users will appreciate having an easier name to refer to, too.

[chipweinberger]

On second thought, I think i'll link to it regardless. But I strongly encourage a proper new name. Don't you want to submit it to pub.dev? It can't use the same name then.

[tnc1997]

Ultimately it would be great one day in the future to merge the fork into this repository and obsolete the fork but I very much appreciate that you would prefer to keep them separate for the time being.

[yaing11]

@chipweinberger Do you think it's a clean solution???

Obviously it's bad solution and any plugin without platform interface is not scalable. My app supports 6 platforms. If your plugin had platform interface i would add only 1 line to the code of my app. This

You have to agree with me it's very clean and scalable solution.

But now i have to add import statement for each new platform. It's not a good solution.

Please, take a look at most popular plugins in flutter https://pub.dev/packages?q=sdk%3Aflutter&sort=popularity.

Each of them has platform interface. For, example, shared_preferences

or url_launcher

All of these plugins are at the top with for more than 1M downloads.

[chipweinberger]

@yaing11 of course, you're right.

You should use @tnc1997 's fork!!

Eventually the goal is to merge. Once it's stable and well tested by many people.