all UI calls need to be made on the main thread (this is an Appkit
restriction) and all Bluetooth calls need to be made on a single
thread. So This pretty much means that if you need to use Bluetooth
and UI on a thread, all the calls need to be made on the main thread.
Using the asyncronous APIs you will avoid blocking the UI for lengthy
operations (like connections).
Ok, understood. One point left in the dark is why could I not call [ IOBluetoothDevice pairedDevice ] in my BT thread ? (Sometimes it returns an empty array, or just one device...). Is this call kind of AppKit one so I have to use it into the AppKit thread ?
Also I would like to point out that trying to connect every 10
seconds is a very bad idea. The connection require the connecting
device to cover the 2.4Ghz band to find the counterpart which means
that you will disrupt AirPort networks. In general this is not that
bad because it does not happen that often (only when you connect) and
802.11 can recover by re-sending its packets, but if you try to
connect every 10 seconds you give very little room for the AirPort
network to recover. If you really need to "keep trying" I would
suggest attempts between 30 seconds to one minute (the longer the
interval, the better).
Understood too :-) I'll change it to 30s, I don't think users need immediate reconnection, I just have to find discrete visual way to show when bluetooth recovers. Thanks to you and others who help me -- Yann Bizeul - yann at tynsoe.org http://projects.tynsoe.org/ [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ bluetooth-dev mailing list | bluetooth-dev@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.