Design Issues with Flutter Blue about flutter_blue_plus HOT 7 CLOSED

Fixed Design Issue 1: 27a2a44

from flutter_blue_plus.

@Sajonji I am still waiting on access to pub.dev. I don't plan to update it right away. I want to integrate & test the changes in my app fully. Feel free to pull master and let me know if you have issues. I have none so far.

@Nolence I totally agree. flutter_reactive_ble has way too many classes & unnecessary abstraction. The Swift code is incomprehensible. flutter_btleplug looks interesting. But needing a rust toolchain is way too much complexity IMO. Debugging and maintenance of a rust codebase would be pretty annoying. But hopefully it "just works".

I like the simplicity of flutter_blue, which is why I just plan to make improvements as needed.

Our team has experienced challenges with both flutter_blue(_plus) and flutter_reactive_ble.

Anything specific?

from flutter_blue_plus.

I've updated this recommendation on the readme.

"Flutter Blue is simple way to add BLE to any app, however flutter_reactive_ble is generally best for apps that need the highest reliability. See https://github.com/boskokg/flutter_blue_plus/issues/264"

Hopefully I'm not stepping on peoples feed with this recommendation. Just trying to help people write the best apps they can!

Edit: I fixed the timing issue and removed the warning / recommendation #266

from flutter_blue_plus.

So I am running into issues with flutter_reactive_ble as well 😩

PhilipsHue/flutter_reactive_ble#728
PhilipsHue/flutter_reactive_ble#385

So...I am going to start tackling these design issues in flutter_blue_plus.

I've thought of a simple way to fix Design Issue 1: Timing: just wrap read & write in a mutex so that simultaneous calls to read & write to the same characteristic are serialized. This is not ideal for perf - queueing reads & writes on the iOS/Android side would be faster, as opposed to on the dart side, but I imagine it will still be fast enough to hit maximum BLE bandwidth. And more importantly, it doesn't require a big rewrite.

Design Issue 2: Error Handling & Design Issue 3: Inconsistency, I'll just tackle as-needed.

from flutter_blue_plus.

Great to see progress on this library again !

@chipweinberger: do you have any idea if and, in case of yes, when you can update the pub dev packages with your changes ?

from flutter_blue_plus.

Our team has experienced challenges with both flutter_blue(_plus) and flutter_reactive_ble. While flutter_blue_plus offers a more understandable codebase, its capabilities are limited and it has been poorly kept up with in the past. On the other hand, flutter_reactive_ble is reliable for developing real-time and robust applications. I really like their API and the stream-based implementations were easy to use. However, some long-standing issues have remained unaddressed, which is understandable considering it's an open-source project.

Recently, I've been exploring flutter_btleplug as a potential final Bluetooth solution for our projects. Although still heavily under development, the necessary tooling is already in place, and the parent project btleplug has a large user base and a good maintainer.

Just some random thoughts I had lol sorry

from flutter_blue_plus.

Yeah, our issues have mostly come from connecting and disconnecting reliably (repeatedly) with flutter_blue(_plus). Another issue we ran into was auto fragmentation of packets. In flutter_blue that's mostly taken care of I think. In flutter_reactive_ble I don't think that happens based on some tests I ran on an older iphone and android device. Flutter_reactive_ble also doesn't have support for manually messing with a characteristic's descriptors which we would like for some odd pieces of hardware we have.

The Swift code is incomprehensible.

I think their code is a little funky too but tbh I think I prefer it compared to the Obj-C in flutter_blue which is really tough to read for me personally haha - just my personal preference

from flutter_blue_plus.