Re: Device Pairing Re-revisited
Re: Device Pairing Re-revisited
- Subject: Re: Device Pairing Re-revisited
- From: Alexander Traud <email@hidden>
- Date: Tue, 07 Feb 2006 23:39:57 +0100
I am not Apple, however I think I can answer this one, too...
> must all devices be made known to the Mac via the Bluetooth Setup Assistant
> in order to use them
No.
> if so, is there a programatic way to avoid this nastiness?
If the Bluetooth service needs authentication, than a pairing is requires.
Since Mac OS X v10.4.3 since can be done programmatically without the Apple
Bluetooth Assistant. Again: It depends on the security setting of the remote
Bluetooth device, if a pairing is required. Again: This can be done
programmatically, however you should consider to use the inquiry user
interface in the BluetoothUI package which does the same on your request -
although it has worse interfaceÝ than the Apple Bluetooth Assistant.
ÝWhy is a Bluetooth passkey shown as bullets here. Does this still happen in
Mac OS X v10.4? Anyway, this is the way it was in previous versions.
> I'm seeing that I am unable to open RFCOMM channels on certain of our
> bluetooth devices
The resulting error code should have been quite informative for such a
case...
> do I rely on the delegate methods -- say of IOBluetoothRFCOMMChannel -- for
> instance will -rfcommChannelClosed: be invoked when a device disappears?
In case you did not get any answer to this one, my two cents:
I am quite happy with the *events* of the callbacks when it comes to channel
closing. Not sure what you are talking about. There should be *no* polling
with Bluetooth. You could poll on a cable link, but I would not poll on a
Layer 2 secured link like Bluetooth if you have access to its API like on
the Mac.
If the device is in range and closes the connection correctly (shut down,
turning off), it is quite immediately. If the device is out of range, the
event fires reasonable. There is no way to get the information more soon - I
doubt that even an additional layer 2 protocol on the link will be faster.
However, I am not sure if this meets your requirements. "Near real time" -
what is this? ;-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden