flutter_ble_lib deprecated

[albo1337]

Hello, I get following error:

The plugin flutter_ble_lib uses a deprecated version of the Android embedding.
To avoid unexpected runtime failures, or future build failures, try to see if this plugin supports the Android V2 embedding. Otherwise, consider removing it since a future release of Flutter will remove these deprecated APIs.
If you are plugin author, take a look at the docs for migrating the plugin to the V2 embedding

Could you fix this?

Best regards

[albo1337]

Actually on xCode 13.0 the app is not able to build. I have to change code in MultiPlatformBLE Lib that the app is building. Could you please provide us with a new version?

EDIT: following classes have to be edited:

MultiplatformBleAdapter>RxCBDesciptor line 43: add ! after descriptor.characteristic -> descriptor.characteristic!
MultiplatformBleAdapter>RestoredState line 68: add ! after $0.service.peripheral -> $0.service.peripheral!
MultiplatformBleAdapter>RxCBChareacteristic line 59: add ! after characteristic.service -> characteristic.service!

[adnsawas]

I am facing the same issue. The change proposed by @albo1337 works locally on my machine but this causes issues in our build pipeline. Please advise.

[sutogan4ik]

wasted

[albo1337]

I am facing the same issue. The change proposed by @albo1337 works locally on my machine but this causes issues in our build pipeline. Please advise.

My workaround is only, if you build locally. This fix has to be made by the owner of this project...

[ShahanAhmedDev]

Have any of you gentlemen tried another package instead of this one? I'd be really glad if you could share it with us.

[albo1337]

I have. Unfortunately there isn't a lib published, where we could achieve same results as with this lib. https://pub.dev/packages/flutter_reactive_ble this one could be interesting for you maybe

[MoralCode]

this package is not even null safe.

it appears the current dev branch supports it courtesy of #586, just hasn't been released to pub.dev yet

[ride4sun]

is the null safety and embedding problem fixed on the dev branch? If yes how stable is it? Any recommendations.
If yes I would create a branch on my public github and maintain it.

Well, if all that is true the owner should just create a new version anyway!!!

[MoralCode]

Disclaimer: I'm just a highly motivated contributor with an exciting project that depends on a lot of these fixes being published on pub.dev

I have been exclusively using the dev branch and have until now had no problems with regard to null safety.

In the future i anticipate having issues because pub.dev wont let me publish my own package with git or path dependencies and this null safe version needs to be on pub.dev for me to avoid this problem.

That said, I believe I am still seeing warnings about the deprecated android embedding as the OP of this issue mentions, even on the dev branch. It hasnt been a hard problem for me yet, but it probably will when support is removed as flutter promises in their warning.

I have been in brief contact with someone at withintent/dotintent and it seems like they still intend to maintain the library, so I'd like to avoid publishing a fork if I can at all avoid it. There also seem to be enough potentially viable ideas i've had for solutions where I'm confident that a hard fork should not be necessary.

TL;DR

If you need null safety, using the develop branch should provide that feature fine (at least in my experience).

The android embedding does not appear to have a currently open PR, so it seems to me like one needs to be created.

As far as getting all this on pub.dev, I'll keep seeing what i can do on that front. In case people are super motivated to help, my email address shouldn't be hard to find from my GH account. I may also try and set up a gitter chat if theres a ton of people interested in continuing to contribute to/support this library.

slightly unrelated: i also think blemulator needs a PR to support null safety as well, but thats probably a different issue entirely

[MrCsabaToth]

I'd just rather move to a library which is maintained and not in an abandoned state.
I found https://pub.dev/packages/flutter_reactive_ble is well maintained, but I haven't migrated to it yet.
https://pub.dev/packages/flutter_blue is neglected as well, although that has a community fork too https://github.com/pauldemarco/flutter_blue/issues/929#issuecomment-930759129

The state of Flutter BLE libraries may look good from a 1 mile glance but looking closely it's pretty neglected and a let down. I put faith now in https://pub.dev/packages/flutter_reactive_ble but I need time to migrate.

[MrCsabaToth]

because pub.dev wont let me publish my own package

I don't understand this. Why couldn't you publish you own package???

[MoralCode]

because pub.dev wont let me publish my own package

I don't understand this. Why couldn't you publish you own package???

What I meant by this was: i cant publish a package which is based on/depends on/requires FlutterBleLib because pub.dev doesnt allow git or path dependencies in published packages. So given that I want the package im making to be null safe, the null safe version of FlutterBleLib needs to be on pub.dev before I am able to publish.

[MoralCode]

I'd just rather move to a library which is maintained and not in an abandoned state.

Based on a brief email exchange as a result of filling out the "contact us" form on withintent.com (the people behind the dotintent GH org), its my understanding that they plan to continue maintaining it. I suspect that there are issues outside of their control that may be contributing to the situation.

If youre considering moving away, It may be worth dropping them a note to inquire for yourself as to the status of the project.

[MrCsabaToth]

What I meant by this was: i cant publish a package which is based on/depends on/requires FlutterBleLib because pub.dev doesnt allow git or path dependencies in published packages. So given that I want the package im making to be null safe, the null safe version of FlutterBleLib needs to be on pub.dev before I am able to publish.

If you have a fork which is null safe then it should not depend on the FlutterBleLib, since it's the fork of FlutterBleLib itself. Just release it in another name. Possibly I don't get your problem still. I looked in the yaml and FlutterBleLib does not depend on any core package or anything, so if your repo is truly a fork... then you should be able to just simply establish a package. (Of course possibly different class path and stuff).

[MrCsabaToth]

Regarding V2 embedding: I upgraded one of my dependencies out of desperation and it was harder than I originally thought. Not a walk in the park. Not impossible either though, especially to the owner or people who are familiar with the source.

[MoralCode]

If you have a fork which is null safe then it should not depend on the FlutterBleLib, since it's the fork of FlutterBleLib itself. Just release it in another name. Possibly I don't get your problem still. I looked in the yaml and FlutterBleLib does not depend on any core package or anything, so if your repo is truly a fork... then you should be able to just simply establish a package. (Of course possibly different class path and stuff).

The project that I'm referring to is not a fork of this one, its just a separate project - like yours - that requires bluetooth communication but isnt a bluetooth library itself.

[ozzy1873]

I am using this fork: flutter_ble_lib_ios_15. It is null safe but it does not support Android API 31. The dev responds to issues, but he does not have much time. Does anyone here have enough Android experience to make a PR to fix Android API 31?

[MrCsabaToth]

I am using this fork: flutter_ble_lib_ios_15. It is null safe but it does not support Android API 31. The dev responds to issues, but he does not have much time. Does anyone here have enough Android experience to make a PR to fix Android API 31?

I think it can be done by analyzing other mentioned Flutter BLE packages who have the compatibility with newer API levels, what I don't have is time.

[mbabuglia]

I was using this library in production but after issues started piling, I moved to flutter_reactive_ble. It is mandatined by Phillips so seems the way to go.

The APIS are not identical, there are some differences regarding connection/disconnection, but nothing big. One developer can implement the migration in a week / two weeks top.

[ozzy1873]

I just noticed this other bluetooth plugin: flutter_blue_elves. The source code looks simple and easy to maintain with no other dependencies. Does anyone have any experience with it?

[MrCsabaToth]

I just noticed this other bluetooth plugin: flutter_blue_elves. The source code looks simple and easy to maintain with no other dependencies. Does anyone have any experience with it?

I saw that plugin too, but just looking at the README makes me cringe. The example source code indentation is totally off, and that scares me about the plugin itself. Simplicity is nice in general, but if you get to a serious app questions arise such as: connecting to multiple devices at the same time, background service / isolates and then complexity increases. The sweet spot to me is something which covers a lot of features, mature and well tested and also well maintained. Good documentation and nice API is a must I don't even mention.