-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Issues with Flutter Blue #264
Comments
I've updated this recommendation on the readme.
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 |
So I am running into issues with PhilipsHue/flutter_reactive_ble#728 So...I am going to start tackling these design issues in I've thought of a simple way to fix Design Issue 1: Timing: just wrap Design Issue 2: Error Handling & Design Issue 3: Inconsistency, I'll just tackle as-needed. |
Fixed Design Issue 1: 27a2a44 |
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 ? |
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 |
@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.
Anything specific? |
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.
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 |
I've been working on the Flutter Blue Plus codebase for a couple days now, and as I'm looking at the issues, it's clear that there are some major design issues with Flutter Blue.
Design Issue 1: Timing
Flutter Blue has some timing problems. See commits like this for reference: a85378b
Before this commit we would:
After this commit:
This fixes a big problem, missing results. But causes a new one, returning wrong results. If multiple callers call
read
at the same time, they'll all do step 1, and then start waiting on step 2. But which result will they get? Typically, the wrong one. They'll both just return the first result. The design of FlutterBlue with a shared channel for returning results means there is no simple fix for this.Design Issue 2: Error Handling
Overall, Flutter Blue was not designed with error handling front-of-mind.
This is clear with issues like #242, where an exception is missed because Flutter Blue code was just not written correctly. This bug has been fixed, but it makes it clear that Error Handling was not a major consideration, or strongly tested during development. I do not have faith in the error handling abilities of Flutter Blue.
Design Issue 3: Inconsistency
This is harder to write down, but there is lots of general sloppiness & inconsistency in the code. Duplicate variables in the Dart API. Inconsistency between returning streams or variables directly. Try/catch clauses that just log in native code. Code which was needlessly hard to read. etc.
It does not inspire confidence =)
future
These issues can of course be addressed -- It would just take quite a bit of development. Perhaps these can be addressed in the future.
flutter reactive blue
Do to these issues, and after reading the flutter_reactive_blue codebase, I am going to be switching my efforts to that repository.
Flutter Reactive BLE takes error handling very seriously:
Dart:
Swift:
Covering my own ass
If flutter_reactive_blue does not work out long term, there is of course still a chance I will return to this codebase. I'll give myself that out =) Though given these issues I would also consider writing my own ble driver instead / significantly rewriting Flutter Blue.
The text was updated successfully, but these errors were encountered: