site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com On Aug 5, 2007, at 11:49 PM, b00mer@mail386.com wrote: Jason, you should probably implement a data receive timer in your app, and if you don't receive any data and your timeout, then just close the connection on OBEXSession. OBEX doesn't really have a notion of timeouts, so there is no API that can help you there. you should do all Bluetooth from whatever thread the first Bluetooth command is send from. I suggest you stick with doing everything from the main thread if possible, you will have the most success doing it that way. jason _______________________________________________ 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... I did that and it works as expected. So, "automatic timeouts" are only possible using low-level BT connections? sorry for the late reply, I don't know how I missed this message. timeouts are only supplied by lower-level functions. the other app might just be waiting for something, and not sending you data. e.g. OBEX Browsing - the user is just staring at the directory, and not clicking anything. no data is sent in this case. choosing a timeout in this case is not relevant. thus, timeouts are left to an exercise to the user of the OBEX Session. Doing BT stuff single threaded is giving me problems though. Designing multi-threaded applications is much simpler. Are you sure I can't do it multi-threaded? you can do your app multi-threaded, just make sure you do ALL Bluetooth related activities on the first thread from which you call anything in the Bluetooth stack. Bluetooth is not threadsafe. we recommend you doing it from the main thread, especially if you are doing Bluetooth UI of any kind. This email sent to site_archiver@lists.apple.com