Choice of low level implementation

[david-sackstein]

Thanks adabru for this project. I have a question about your choice of the WinRT for your low level implementation. Is there any reason why you did not use the apis in C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um\bluetoothleapis.h? (as in https://github.com/DerekGn/WinBle) ? Will they not work in Unity? Thanks

[adabru]

Hi David, my "choice" was led by trial-and-error. I looked for a C# API first, then I downloaded the microsoft sample, which contained the c++-winrt version additionally to the C#-UWP version. So I took the natural step and grabbed the winrt version. I didn't step onto the api you mention.

But regarding your question: I guess the api will work equally well. I think every c++ dll works in Unity. Maybe the win32 version will even be a little bit more stable than the winrt version. I read about winrt that it may have some instabilities and while I was dealing with it, it didn't feel as robust as it could be. But i didn't experience any issues without workaround yet.

Another thought that comes to my mind is the migration path to the UWP platform, or to a potential future .NET 5 ble api. I guess it's easier to rewrite c++-winrt code to .NET code (almost 1:1 mapping) than it is to translate win32 api. But that only applies if you're not using another library for UWP alltogether.

[david-sackstein]

Hi adabru, Thanks for your response. If I prefer to avoid UWP which API would you recommend I use? I am concerned about the version issues with UWP. (WinRT is also requires UWP, right?) Also, what are the differences between the code in the Microsoft example you quoted and this project? Thanks

[adabru]

If I prefer to avoid UWP which API would you recommend I use?

Yes, WinRT requires UWP on the platform. This is my first time using bluetooth, I don't have any other experiences and didn't research any other API. What might interest you is the third party provider https://www.btframework.com, s/he is also active on stackoverflow. There is nothing else that comes to my mind.

Also, what are the differences between the code in the Microsoft example you quoted and this project?

I copied and adapted the code from the Microsoft winrt version into the dll. The additions are:

• Own caching for uwp devices, services and characteristics because WIndows threw errors when accessing them too often.
• Polling with synchronisation primitives as I had problems with calling/marshalling C# callbacks from the C++ code, i.e. the Unity Editor crashed or freezed. Still, if call the blocking variants from Unity Editor's main thread, the program freezes.
• Buffering of data. I had also problems marshalling memory between C# and C++ so the code copies data in the dll functions when needed.

That's it actually. I don't have much experience marshalling. If it were done so that callbacks and memory would be shareable without crashing afterwards, half of the code could be avoided.