site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=RluJnj3w9CdBHm16yuuZVnaNUYt5QIYTKGKDOy9ahTU=; b=t4AYqnpgzxScemctmiVEuTcgwkuSTxCx5AzQIgYMZXEYCq4ibJF1yMQ35u4IzYQ2tL ZxTCVLa3YzIjsiWtMNIR2zp8H76JgbSXxShAarPiR/c3ajsg5PzdTfxSPL19Kt0Yi1rK LnfV0siX3cgi9ggLhLRdCg3gs/kCMqXOB53o4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ALHk7nzjjo4aZvLqUn8AHY1Ag6OesQDxwEPF4ndQttiYe0xHk8XVR2WROXGUAilfmk FehT5Wb7qDefTNluAg9dT13dNEIKhIf4In7H4jhrEC77pOEgO7b803DcFQVYFjpxOr2b huKyguQPrKUSg5Atqx89nsgQoTfG3BiclHVZ8=

I knocked all the code down to the single UI thread and I rediscovered why I need multiple threads. My Obj-C objects give KVC semantics to the bluetooth device. A getter is waiting on a thread signal for the arrival of requested data. The requested data will never arrive since the single thread is in a blocked state. I also now have to turn the bluetooth scanner off to open a connection to a discovered device!

I see. Note that if your getter method blocks until the Bluetooth operation is complete, your UI will also be blocked. So if the Bluetooth operation takes too long, you'll get the beachball. Perhaps your getter could initiate the Bluetooth operation, and in the meantime return a cached object? If a cached object isn't available or you want to update the property's value, return a default value for the property, and initiate a "Loading..." spinner in the UI. Once the current state of the property is available, it updates the property which in turn updates the UI, and hides the loading spinner. For a snappy user experience, I'd try to avoid blocking in a getter method.

I don't see how to do the bluetooth communications in another process be non-trivial. Is there a simple approach to that?

I implemented a simple custom protocol over Unix pipes, allowing the parent to direct the child in performing some simple Bluetooth operations. It certainly wasn't fun to implement, but from what you've said so far, I think handling the Bluetooth operations in the same process will work fine in your case if you structure it right.

My next factoring will be to but the UI thread into a secondary thread, and let bluetooth own the main. Hopefully that will work.

I hate the be the bearer of bad news, but UI code generally needs to remain on the main thread, too. See: http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Multit... _______________________________________________ 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... This email sent to site_archiver@lists.apple.com