Bluetooth Error Detection and Handling Strategy
site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com I hope I'm not rambling too much -- it's a friday after all ;-) Thanks Joe K. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.a... Out of curiosity, what would constitute a good error handling strategy for Apple's Bluetooth api? This is my first ever work with wireless devices, and I cannot immediately find much literature to answer such a question. For instance, how should I detect when the connection to a device has unexpectedly disconnected? Would it make sense to poll a device's - isConnected: and a channel's -isOpen: methods before performing any operation, and possibly also poll from a timer just so I can keep abreast of any changes? I guess this question could be further broken down into: how effective are these methods, and how efficient are they -- will they accurately tell me of any state changes and are they timely? When a broadband connection disappears, does IOBluetooth know about it immediately? And/or do I rely on the delegate methods -- say of IOBluetoothRFCOMMChannel -- for instance will -rfcommChannelClosed: be invoked when a device disappears? My device collects data, and the client app will write configuration commands to it, and then kind of lazily poll it's buffers for available incoming data -- basically our collection needs to be near real time and the collection rate is variable, so to implement some kind of handshake would tax our hardware. This strategy gets mucked up when the connection unexpectedly closes. I've also observed the following behavior: sometimes on open channel async or write async, I will never get the completion callback -- I gather the device is in some kind of bad state (turned off or out of range etc) at the time, but there's no way to report this to my client. I've implemented timeouts on all my operations, but I've then just sat around and waited for the completion for 10 minutes with no luck! So maybe my next question (or is it a feature request?) would be along the lines of: having gotten a timeout but no completion, is there a way I can programmatically cancel an open or write? (Or any other async operation). I currently just close the channel and close the connection and just pray that the completions don't arrive afterwards. This email sent to site_archiver@lists.apple.com
participants (1)
-
Joseph Kelly