SimpleBLE VS brainflow

BLE library for python without asyncio

I'm the creator of SimpleBLE, a cross-platform library to use Bluetooth on desktop environments (and hopefully mobile soon), and I'm currently looking into adding Kotlin bindings. I how how to write JNI wrappers as I've done so in the past, but I'm having trouble understanding what's the best way to set up a Gradle project for it to be consumed by 3rd party users, considering that the C++ backend can be compiled with multiple "flavors" based on the target OS.

I do have a request to enable cross-compiling support, so I think I might go for it relatively soon. For reference, this is the issue to track on this topic: https://github.com/OpenBluetoothToolbox/SimpleBLE/issues/98

I've received this request multiple times, so I think it's important enough to make sure it's part of the v0.6 release. I've made an issue to track this, feel free to follow: https://github.com/OpenBluetoothToolbox/SimpleBLE

Fixed the incorrect URLs. My bad on the usage docs, when I wrote this I was referring to the examples folder in the repo. I made it slightly better with some more specific guidance: https://github.com/OpenBluetoothToolbox/SimpleBLE/blob/main/docs/usage.rst

For over a year I've been working on a cross-platform Bluetooth library called SimpleBLE, specifically designed for use in desktop environments with a very simple API, allowing developers to easily integrate it into their projects without much effort.

I do have a few examples showing how to enable notifications and writing to a characteristic. If you have any questions please reach out, I'll gladly help!

About my current user base, I'd like to highlight we use SimpleBLE at my job, it has been integrated into BrainFlow, it is part of some new tools made by a large industrial automation company (whose name I cannot mention but rhymes with "Good product made by bees") and by a robot researcher in Germany.

BrainFlow provides a uniform SDK to work with biosensors with a primary focus on neurointerfaces. It provides SDK for Python, Java, C#, C++, Matlab, R, Julia and Rust. Core part of BrainFlow is written in C\C++ and all bindings call methods from dynamic library. User API is uniform for all supported devices and allows you to develop device agnostic applications.

Website

https://github.com/brainflow-dev/brainflow/blob/4.3.2/java-p... fails to close that InputStream, which leaks file handles every time that method is invoked. Even the javadoc shows the correct usage of wrapping the InputStream in a try-with-resources block https://docs.oracle.com/javase/8/docs/api/java/nio/file/File...

The line right above that one fails to check the return type for file.delete() as that is a _request_ to delete the file and may not succeed for any number of reasons that might interest the code. If the file fails to delete, it can be retried, or one can use file.renameTo to try and move the _name_ out of the way, even if the on-disk allocation still remains. Of course, one should similarly check the result of file.renameTo as it is also a request

Swallowing exceptions is a pet peeve of mine https://github.com/brainflow-dev/brainflow/blob/4.3.2/java-p... because (a) it doesn't even acknowledge that an exception occurred in the error message right below it, meaning if one wished to debug _why_ that error occurred, now one must either use a debugger or recompile to include that information. The method similarly does not disclose that the result may be null, and NullPointerExceptions are my other pet peeve since unless running on a bleeding edge JVM, the error message is always "NullPointerException: null" meaning it says absolutely nothing about what it was trying to do when it fell over

Kind of related to that, the javadoc for some of the further down methods say "throws WhateverError" but not _why_ or what influence the caller has over that outcome

That's as far as I looked before closing the tab and wondering if I should mention the file handle leak, since if you only found the repo, then telling you wouldn't accomplish anything. But if it was your repo, then raising your awareness might be helpful

Then, yes, of course I agree with the sibling comments that the code style is very, very distracting, but there's no way I would have bothered to comment in HN about code style since to each his/her own so long as I don't have to work in it :-)