Skip to content
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

Find Alternative to SweetBlue #101

Closed
jrtberlin opened this issue Feb 10, 2020 · 5 comments · Fixed by #127
Closed

Find Alternative to SweetBlue #101

jrtberlin opened this issue Feb 10, 2020 · 5 comments · Fixed by #127

Comments

@jrtberlin
Copy link
Member

SweetBlue, the BLE library we use, is deprecated.
SweetBlue v3 is expensive, proprietary and closed source.
Although the code has some entertaining value (unnecessary code, code styling issues, deprecated APIs all over the place,...) I don't have any sentimental thoughts about it and we should replace it.

We have the following options:

  • Search for a maintained library with a similar feature set (I haven't found one yet)
  • Write and maintain our own library (a lot of work)
  • Fork the library and maintain it (headaches and entertaining code reviews included)
  • Use the native Android BLE stack (not a great option)

I think the best option would be to write a new library that uses the same interface to make it a 'drop-in' replacement.

@jrtberlin
Copy link
Member Author

It seems like RxAndroidBle could be a replacement. However, the interface design and the scope of the lib differ from SweetBlue and changes scattered through AsteroidOSSync are necessary.

@FlorentRevest
Copy link
Member

This looks great! I guess that no matter what lib we find we will have to change code scattered through AsteroidOSSync.

@jrtberlin
Copy link
Member Author

My idea would be to implement our own BleManager with a similar interface and call the new library from there. This would have the benefit that we could keep the maintenance low with future changes to ble libraries and modularize the project a bit more.

@FlorentRevest
Copy link
Member

Mhhh, I wonder if this would be the right abstraction... Maybe it is. Otherwise, SynchronizationService was meant to be an abstraction for the rest of the source code, I'm not sure whether we really ever managed to achieve this but well... :)

@jrtberlin
Copy link
Member Author

I think Nordics BLE library might be a better fit for our application architecture. But we would have to find our own solution or another lib for device scanning.

@MagneFire MagneFire added this to Proposed in AsteroidOS 2.0 Sep 18, 2020
@MagneFire MagneFire moved this from Proposed to In progress in AsteroidOS 2.0 Dec 1, 2020
@jrtberlin jrtberlin linked a pull request Apr 28, 2021 that will close this issue
AsteroidOS 2.0 automation moved this from In progress to Done May 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

2 participants