Adapt IOBluetooth bindings to net10 and other versions

[darkhz]

Hello @peterfoot ,

This is a suggestion more than an issue, in the hope that it would help others work with IOBluetooth APIs more easily.

Instead of relying on the old Xamarin.Mac and Xamarin.MacCatalyst build targets, we can now directly use the macios project with the appropriate workload and the most supported macos build target (for example net10-macos, net9-maccatalyst).

Since no official IOBluetooth bindings exist yet, we can use your bindings, albeit with slight modifications, as I have done separately here (ApiDefinitions) and here (StructsAndEnums).

Then, all that remains is to add a linker argument in your IOBluetooth.csproj (or in the topmost csproj) as done here, and compile. The bindings are usable after this.

Please refer to the project for all the implementation and binding usages.

I would be willing to work with you to create a better IOBluetooth API, like how other bindings are nicely done and provided in the Macios project.

Other issues of the same type:
#376 #322 #276 #20

[peterfoot]

Thanks, the intention has been to migrate it to .NET from Xamarin for a while but unfortunately I've not had the time. I'd be grateful for any help to get it updated to build for .NET 9.0 or 10.0. Thanks for the reference, I'll take a look at your project as suggested.
I agree about improving the API to be more .NET friendly, it is a big API but it would be good to get the serial parts stable and cleanly wrapped and this would open up the functionality of InTheHand.Net.Bluetooth on macOS. Eventually it would be good to fully support all the SDP and Hands-free APIs too.

[darkhz]

@peterfoot thanks for the reply.

I will admit that the codebase is largely uncommented (and slightly unorganised), so if you have any questions do let me know.

Also do let me know if you're ready to work on this, I am available anytime and will be glad to help out.

[peterfoot]

Thanks, I've started work and updated the project files to .NET 10 and made necessary changes to the other files to get the two projects to build - IOBluetooth and IOBluetoothUI. Next I will move on to the sample project so that I can get an app using the libraries to run to ensure that it is correct. Then further work can be done on reworking some APIs. I've put all of this work in a separate branch for now "iobluetooth". If there are problems you see there or things you would like to change/improve please feel free to raise a PR against that branch. Once it is stable and working I can look at merging that into the main branch and produce pre-release versions of the NuGet packages.

[darkhz]

@peterfoot sounds good.

I did take a brief look at the iobluetooth branch, and I wanted to point out that perhaps "NativeLibrary" may not work when using with the full path to the IOBluetooth framework, specifically here, since specifying the full path may cause clang to search for a framework binary. I vaguely remember it not working when I tried it last time. That's why I suggested passing the linker arguments directly.

I will try testing the branch and let you know.

[peterfoot]

@darkhz thanks, I've added the linker arguments and also reworked the sample application to test calling a couple of APIs and it is working when debugging locally which is reassuring. The storyboard in the sample isn't currently working, probably because I renamed the project from a template but I can at least use IOBluetooth.BluetoothDevice.PairedDevices and enumerate through the devices and their properties

[darkhz]

@peterfoot that's great news.

You may probably know all this, but I am writing these things that I found during my testing, so that it helps whoever reads this comment.

IOBluetooth

Most IOBluetooth APIs require the main dispatch queue to be running (i.e. an NSApplication/CFRunLoop/NSRunLoop etc.). This should probably be documented for the users of 32feet, since some use it in command-line applications.

The IOBluetooth APIs are still to this day, largely buggy and sparsely documented.

For example:

• "-[IOBluetoothDevice pairedDevices]" will sometimes return duplicate devices, so perhaps collecting the result in a separate list and removing duplicates may be necessary.

• Checking to see if a IOBluetoothDevice object is null or not (and by that extension, checking whether a device exists or not) will not work, since an IOBluetoothDevice object is never null even if an invalid address is supplied. You will have to additionally call "pairedDevices" and check if the device actually exists.

• Pairing is also buggy, in the sense that pairing a device for the first time will work, but repairing the same device again won't work. You will have to switch the adapter off and on for repairing to happen (Switching the adapter's power state seems to fix some things in IOBluetooth, actually).

• For opening a connection to a device, use this method instead of the classic "openConnection" method without parameters, to make it work on Tahoe. For closing a connection, use the same "closeConnection" method, but note that it mostly doesn't block until disconnection, you will have to poll connection state separately.

(There are workarounds for most of these examples, but it will involve calling private APIs, for starters.)

General notes

• In C# when using macios, do not import CoreBluetooth, since macios will append the CoreBluetooth and IOBluetooth headers to the resulting objective-c bindings (via bgen) and that will conflict with the custom IOBluetooth bindings.

There are probably more things that I have to add, I will do so later.

Also, if you could point out where exactly I can contribute, that would be a good starting point for me.

[peterfoot]

@darkhz thanks, there is a lot of useful information here. I've not encountered the duplicate device issue in my limited testing, but this could be built into the partial BluetoothDevice class currently in Extras.cs. This should probably be renamed as the contents are just for BluetoothDevice currently, and for other classes separate files can be used. Similarly the current monolithic ApiDefinition.cs could be broken down into smaller files.
Wrapping the OpenConnection method or CloseConnection seems like a useful addition. I haven't looked into the pairing code yet.