Moving from Plugin.BluetoothLE to Shiny.BluetoothLE

[munkii]

I am finally getting around to moving from the obsolete Plugin.BluetoothLE to Shiny.BluetoothLE. Are there any notes about moving from Plugin.BluetoothLE to Shiny.BluetoothLe?

I've removed my inital issues as I'm happy mapping old func to new for AdapterStatus (I did try and use markdown strikethrough rather than delete but that did not work)

Whilst I seem to have things working now I'm still interested if there was any post on moving from one library to the other.

Thanks

[aritchie]

Are there any notes about moving from Plugin.BluetoothLE to Shiny.BluetoothLe?
Nope. There isn't a huge API difference in any case. Generally speaking, I build stuff. I help sponsors and answer the quick questions. Docs are bonus

[munkii]

Fair enough, just thought I'd ask :-)

[munkii]

I can ask this seperately if you prefer.

We used to Subscribe to CrossBleAdapter.Current.WhenStatusChanged and flag if for instance the user turned off BT whilst we were on a page that was expecting to use it.

I've looked in the Shiny.BluetoothLE.Extensions and can't see anything similar. Is it no longer possible to see that event happening?

[aritchie]

Here is fine. So, that method no longer exists for a number of reasons:

• It doesn't work in the background well and can be lead to issues if you don't unhook it. The question is, when do you unhook it if you always to monitor it? How do you prevent multiple hooks, etc
• Most of the time, you're answering the problem the same way, with a notification
• To turn off BLE, you have to go to the background anyhow
• Whenever you start the main BLE scan operations, the library always runs RequestAccess anyhow
• The management of device status change has always existed in the IBleDelegate and continues to do so. You can dependency inject into it (ie. notifications) & not worry about (un)hooking.

Hopefully that answers the question fully

[munkii]

We don't do any bluetooth in the background, the user has to be on a "Capture" page. When that page we loads we were hooking and then unhooking.

As all our BT work is with the app foreground we've never had the need to pop up a notifcation like for instance the Tile app does.

I'll take a look using the BleDelegate and sending a local notifcation.

[aritchie]

Fair about the bg operations in the background. What I mean by "background" in the scenario of hardware availability, they have to leave your app to shut off bluetooth. It will trick a background operation. There were many cases that the WhenStatusChanged would simply fail or lead to downstream issues. RequestAccess needs to be done almost every time anyhow and provides a holistic approach to everything to hardware & permission availability.

Give the delegate a try and let me know. I'm happy to revisit this if you've got recommendations.

[rostopira]

Could you provide example, on how to use IBleDelegate?

[aritchie]

https://github.com/shinyorg/shiny/blob/master/samples/Sample.Maui/BleClient/MyBleDelegate.cs