BLE peripheral connect / disconnect detection

[mightypanda]

Hello to everybody,

I am trying to use Shiny on an Androd Xamarin Forms app just for:

• enumerating already connected BLE peripherals when the app starts
• receive connect / disconnect notifications of BLE devices connecting to the OS

I do not need to actively Connect() to a device, since it is a speaker/mic that is already paired with Android and auto-connects without problems.
So my first approach was to enumerate connected devices (to the OS) in a polling low-frequency task, but it seems i never get any peripherals.

var ble = ShinyHost.Resolve<IBleManager>();
ble.GetConnectedPeripherals().Subscribe(peripherals =>
	{
		foreach (var p in peripherals)
		{
			// it's lonely here...
		}
	});

It seems that it would return only peripherals "connected through the app" ?

The in resorted to using a BleDelegate, initialized at startups, that correctly receives OnConnect() callbacks.
I am able to detect if the device auto-connects while the app is already opened now, but i don't know how to detect disconnection, since the subscription to the WhenDisconnected() is received in a strange way and never when there is a real disconnection.

public override async Task OnConnected(IPeripheral peripheral)
{
            peripheral.WhenDisconnected().Subscribe(device =>
		{
			// happens at the beginning, after OnConnect(), but not when device is really disconnected.
		});	
}

Documentation couldn't help and I cannot find samples for the first approach, that would be the best I think, handling both cases when the devices are already connected when the app is started, or just auto-connect later.

Thank you!

[aritchie]

the subscription to the WhenDisconnected() is received in a strange way and never when there is a real disconnection.
You cannot keep memory resident things like this in delegates as they will often be lost if the app fully backgrounds again. This is why Shiny uses the delegates instead of events. I'm not sure what you mean in terms of weird beyond the fact that it may not fire in the background?

It seems that it would return only peripherals "connected through the app" ?
This is the way the platforms behave and this is documented on the intellisense of the interface. There isn't much I can do about this one. There isn't a way to read/detect a "connected" device unless you connect with your app.

I can look into adding an OnDisconnected event to the delegate in a future version.

[mightypanda]

Thank you @aritchie

Let me detail what happens:

1. I never connect esplicitly to the device (Bose Frames glasses with audio and microphone), they are already paired and connect to the phone automatically when switched on
2. I get the OnConnect() event with the right device, but its status is Disconnected.
3. If i subscribe to that peripheral's WhenDisconnected() event it gets fired someway, but usually just right after the connection (and with Disconnected status)

I would only care about OnConnect() and OnDisconnect() (if the delegate had that event) since it seems to catch the event even if not done inside my app.
Doesn't this conflict with the standard behaviour you described?

Thank you

[aritchie]

I can only return what the platform gives me. If those events are firing and giving that status, that's what the OS is giving me.

I'll be honest, I won't be in a hurry to add anything around this because it will only really behave this way on Android and the events weren't really meant to be used this way.

[mightypanda]

Absolutely makes sense @aritchie, it is pointless to fight the OS.

Could you just point me at the possible implementation of the OnDisconnect() event in the source code?
Thank you.