search

dotintent / FlutterBleLib

Bluetooth Low Energy library for Flutter with support for simulating peripherals
Apache License 2.0
531 stars 195 forks source link

Still maintained? #581

Open cenumi opened 3 years ago

cenumi commented 3 years ago

Got news from Twitter that Polidea was acquired by Snowflake on Feb 8th and will no longer offer software development services. Does it means we should switch to another plugin. link

DevNico commented 3 years ago

@mikolak Maybe you could just give us a quick update on that?

mikolak commented 3 years ago

Hi!

Yes, Polidea was acquired. Development here was halted some time ago due to time constraints. Maintaining will slow down a little, but we're already looking for a company to take it over and have a candidate. I wouldn't switch just yet. 🙂

Henge9 commented 3 years ago

Hi!

Yes, Polidea was acquired. Development here was halted some time ago due to time constraints. Maintaining will slow down a little, but we're already looking for a company to take it over and have a candidate. I wouldn't switch just yet. 🙂

Good news, thank you for taking care of us users.

maciej-szulc commented 3 years ago

Well, any information about updates to null safety? When can we expect ?

flukejones commented 3 years ago

I would think that Phillips would be a good candidate - https://pub.dev/publishers/meethue.com/packages. But they have their own

mbabuglia commented 3 years ago

I would think that Phillips would be a good candidate - https://pub.dev/publishers/meethue.com/packages. But they have their own

It says it uses Polidea's Android library under the hood...

CruelSamaritan commented 3 years ago

Sorry, I pass. Basically wasted a day trying to make it work correctly and eventually failed (one device being discovered, 2nd device occasionally, rest of them never while e.g. flutter blue has no issues with it (iOS, though it has other problems). All in all, I think it's too buggy and overcomplicated. Thanks for trying though...

okocsis commented 3 years ago

Well, any information about updates to null safety? When can we expect?

I've just made a pull request regarding this. I'd love for you to try my nullsafety branch:

586

but let's move this discussion to it's own issue I guess:

556

mbabuglia commented 3 years ago

Hello @mikolak . As I understand, Polidea won't be maintaining the Android/ios native libraries either? So, not only you need maintainers for the Flutter plugin but also for the underlying native libraries?

mikolak commented 3 years ago

@CruelSamaritan don't know what to tell you, I did a medium size project with this library in the beginning of the year and everything worked. 😉

@mbabuglia Yeah, that seems to be the case. I wasn't involved in maintaining those, so I don't know what's the status. RxAndroidBle is pretty stable and iOS part of FlutterBleLib runs on a severely outdated RxBluetoothKit for legacy reasons and should be ported to pure OS implementation anyway.

okocsis commented 3 years ago

and iOS part of FlutterBleLib runs on a severely outdated RxBluetoothKit for legacy reasons and should be ported to pure OS implementation anyway.

@mikolak I'm happy to land you guys a hand on that, as I'd also prefer a cleaner iOS API only implementation, the fewer dependency the better. We at Privatdoktor.hu (200k+ users) need this lib to be stable as it's a crucial component of our app. I'm not too keen on starting over from scratch with my own ble flutter adaptor...

Anyways I hope with the best of our knowledge together as a community on github we will succeed in maintaining this nice little lib no matter what! :) @mbabuglia @flukejones

@CruelSamaritan It's really funny you say that, cause I just dropped FlutterBlue. It was buggy as hell, and the code quality there is not even worth fixing. Not to mention it lacks crucial features regarding more recent pairing protocols. It's not maintained AT ALL! they don't even give a darn about PRs fixing actual issues there. Up until now -- till I got really fed up with it -- we used our own for of it real Shite!

mikolak commented 3 years ago

And we're happy to accept help! 🙂 It's a big time investment with several stages (or one, but even bigger). Work is here: https://github.com/Polidea/MultiPlatformBleAdapter/tree/master/iOS I'd like to:

  1. remove copied frameworks and make them cocapods dependencies (RxSwift, RxBluetoothKit)
  2. Drop RxBluetoothKit in favour of CoreBluetooth implementation, in either Swift or Obj-C.
  3. figure out whether Swift can be used at all or not (there were issues with ABI and supporting different Swift versions and the general opinion was that it'd be best to keep the implementation in pure Obj-C, but doing any fixes on Obj-C is a horror story for me)

And all this with keeping the current external contract, as there are two 3,5 libraries depending on it (react-native-ble-plx, FlutterBleLib, BLEmulator, react-native-blemulator [WIP]).

okocsis commented 3 years ago

doing any fixes on Obj-C is a horror story for me)

@mikolak speaking of Obj-C I'm your man, I've been using it professionally since 2010, and I know it seems odd but I do love it as this was my first serious language to master OO paradigm. I also use swift. It's no use mixing swift into an Obj-C project, although it might be worth making a Swift wrapper around it so it's more convenient to use from Swift. At one point it will make sense to redesign the code using pure swift as it has a way more expressive type system underneath the hood then Obj-C does, and we can turn it to our favour by creating an elegantly interfaced and implemented framework. See any of Mattt's work e.g. Alamofire vs its AFNetworking Obj-C counterpart the swift one is just objectively better implemented and cleaner by design. TL:DR

(I personally think flutter would be a better framework if it was implemented using swift -- yes it runs on android too, it's also a general programming language -- so is kotlin -- khm also a better choice then dart -- but here we go with a yet another JS-like language -- at least it's not JS...)

MoralCode commented 2 years ago

I had some comments on this in #613, but it also seems like there's already forks being published so it seems like the community has already got the perception that this codebase is unmaintained

okocsis commented 2 years ago

I had some comments on this in #613, but it also seems like there's already forks being published so it seems like the community has already got the perception that this codebase is unmaintained

yepp, I certainly did, so I do maintain my own fork of it. it works okay now on both android and iOS, didn't pay too much attention to meaningful errors and such as I've got stuff to develop on top of this.

MoralCode commented 2 years ago

Do you think it would be helpful to try and get everyone with their own forks to converge on using the same fork? Or at least get everyone in a gitter chat or something to see what people would want to contribute to/support?

okocsis commented 2 years ago

Do you think it would be helpful to try and get everyone with their own forks to converge on using the same fork? Or at least get everyone in a gitter chat or something to see what people would want to contribute to/support?

well, I do not know about others but my fork is quite detached from the original codebase now as I've completely rewritten the whole iOS codebase, and significantly changed the android one accordingly so that they share the same -- in my view -- enhanced interface, of the new iOS support lib. For instance, many things are now awaited and less stateful on services and characteristics. All that being said I'm 100% open to such a discussion. ;)

ozzy1873 commented 2 years ago

I'm interested in contributing also.

arthurv commented 2 years ago

Do you think it would be helpful to try and get everyone with their own forks to converge on using the same fork? Or at least get everyone in a gitter chat or something to see what people would want to contribute to/support?

well, I do not know about others but my fork is quite detached from the original codebase now as I've completely rewritten the whole iOS codebase, and significantly changed the android one accordingly so that they share the same -- in my view -- enhanced interface, of the new iOS support lib. For instance, many things are now awaited and less stateful on services and characteristics. All that being said I'm 100% open to such a discussion. ;)

Also interested in this fork. Do you have it on github?

MoralCode commented 2 years ago

the fork ive been using is https://pub.dev/packages/flutter_ble_lib_ios_15 (mentioned in the other issue that i linked earlier along with a couple alternatives). My only concern with having that act as a canonical community fork is that it doesnt appear to share its git history with this repo (i.e. the author created a brand new repo from some point in time of this repo).

Ive been considering taking the commits in that repo and rebasing them to share history with this repo, however this might not end up being sustailable as I wont be able to maintain something like this long term without help as I'm more of a user/contributor to these kinds of libraries than a maintainer.

That said Im happy to discuss things/contribute to a solution. If it helps I made a gitter chat at https://gitter.im/flutterbt/community to hopefully get the maintainers of some of these forks, as well as interested people like us together to figure out how to create a sustainable successor to this library

okocsis commented 2 years ago

Do you think it would be helpful to try and get everyone with their own forks to converge on using the same fork? Or at least get everyone in a gitter chat or something to see what people would want to contribute to/support?

well, I do not know about others but my fork is quite detached from the original codebase now as I've completely rewritten the whole iOS codebase, and significantly changed the android one accordingly so that they share the same -- in my view -- enhanced interface, of the new iOS support lib. For instance, many things are now awaited and less stateful on services and characteristics. All that being said I'm 100% open to such a discussion. ;)

Also interested in this fork. Do you have it on github?

@arthurv https://github.com/privatdoktor/FlutterBleLib/tree/privatdoktor