Add PeripheralID trait and use it in api

[ColonelThirtyTwo]

Currently, the api submodule uses one type from the platform submodule: PeripheralID. If an external crate wanted to implement the API for a custom backend, they would be stuck with the platform's opaque PeripheralID and be unable to use their own.

With this patch, the peripheral ID type is now an associated type of the Peripheral. CentralEvent also now has a generic argument for the peripheral ID type.

This adds a PeripheralID trait, which is mostly just to combine the supertraits like Clone, Send, Sync, etc into a more usable trait.

[ColonelThirtyTwo]

Check failures are from clippy issues with the existing Android code.

[qdot]

Ok, so, gonna hold this past our next release because it's an API surface change and we've already got a ton of large changes coming in.

Also, I'm... kinda curious what custom backend is needed? While I'm certainly not against custom backends, just haven't heard of anyone wanting to build one out so far.

[ColonelThirtyTwo]

Also, I'm... kinda curious what custom backend is needed? While I'm certainly not against custom backends, just haven't heard of anyone wanting to build one out so far.

At the time, the existing Android backend uses an old version of the jni crate that was incompatible with my project, and I wasn't a huge fan of how much Java support code that it needed, so I had opted to write my own.

My backend is still a bit of a WIP, and I noticed just now that the crate has updated the jni crate, so it's less of an issue now.

[qdot]

Yeah, finally landed the jni-rs 0.22 update. It was... a lot, even with agentic help.

If you've got ideas about the java backend, I'm definitely happy to hear them. See this blog post on some of the history there: https://nonpolynomial.com/2023/10/30/how-to-beg-borrow-steal-your-way-to-a-cross-platform-bluetooth-le-library/

Right now our QA for it is mostly "I ship an app that uses this with 10k+ MAU but I'm also basically a single developer with 2 android phones to test on". Our crash rates there still trend > 1% (But usually not above the 1.1% bad behavior line anymore), all around bluetooth issues, so I'd like to get that shored up.

[ColonelThirtyTwo]

even with agentic help.

Gah...

If you've got ideas about the java backend, I'm definitely happy to hear them.

My backend is mostly using JNI 0.22's bind_java_type macro to make bindings to Android's bluetooth stack. The only java code needed then is things that need to be subclassed, such as the *Callbacks.

I haven't really tested it beyond connecting to one device and reading/writing GATT characteristics, and the Android BLE API seems really fragile.

[tternes]

I haven't really tested it beyond connecting to one device and reading/writing GATT characteristics, and the Android BLE API seems really fragile.

Do you have this on an accessible fork, @ColonelThirtyTwo? I'd be very interested in reviewing and testing. I've had similar interest in attempting to replace the Android implementation in this library, as it's the biggest source of crashes in our application right now.

We have a pretty extensive automated testing fixture with hardware in the loop for our product.

I have a handful of patches I'm overdue to submit to this repo + jni based on multi-day durability tests we run across a fleet of devices.