Remove Central and simpify/unify API

[twyatt]

Decouples components from Central paradigm (Central has been removed).

API was simplified and unified by making the following changes:

• MacOS target holds an internal CentralManager
• Android target uses AndroidX startup to register an Initializer (and obtain application Context)

Scanner is no longer scoped, so Peripheral remains the only Coroutine scoped component. This allows library consumers more flexibility about the lifecycle of the various components.

Updated README can be viewed here.

[QuantumRand]

Is the intention that all advertising peripherals will be in the flow, and filtering is done after they've been scanned? (as opposed to passing a filter to the scanner itself, like it is traditionally done in Android?)

[twyatt]

For now, yes, all filtering is to be done at the Flow level. Not ideal, but good enough for MVP.

The plan is to add additional configuration support to Scanner (follow the builder pattern), similar to how Json works in kotlinx.serialization.

So, for platforms that support it, filtering could be done at the scanner level via an API similar to:

val scanner = Scanner {
    services = arrayOf(...)
    priority = Low
}

See also: #22

[QuantumRand]

This only works because we're targeting js().browser() correct? Supporting non-browser based JS environments would require a different approach, right?

[twyatt]

Oh. Good point. I don't believe this will work for Node.js.
Looks like Noble library does it via some kind of Node.js bindings mechanism.

https://github.com/noble/noble/blob/c4cd18a7a429bb832f6c4ca793be3faf9af884e9/lib/webbluetooth/bindings.js#L28-L45

...something to look into in the future. Tracking via #25.

[twyatt]

Complete with the exact name match on the interface.

🤦 I'm not sure what I was doing wrong, but when I tried this earlier it wasn't compiling. Seems to be working now, this was my preferred approach. So, I'm glad it seems to be working now. 😄

[Phoenix7351]

This is the same implementation as the Android version's Peripheral implementation. I haven't seen much expected/actual implementations. Is it possible for disparate platforms to share implementations?

[twyatt]

In this particular case. The bluetoothDevice property name is the same on both platforms, but the type is the platform specific type for each platform, so being able to have this as a single function in common is not possible unless the BluetoothDevice is defined as expect/actual.

Unfortunately, since the platforms diverge a bit in their representation of the underlying bluetooth device, it's probably better to have this function duplicated than deal with the potential complexity of trying to unify the bluetooth device platform representations.