Still maintained?

[cenumi]

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]

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

[mikolak]

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]

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]

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

[flukejones]

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

[mbabuglia]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

I'm interested in contributing also.

[arthurv]

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]

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]

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