On Nov 12, 7:57 pm, BCS <[email protected]> wrote: > the official Bluetooth sample show the main UI calling a blocking > method because it is wrong ..
Well, if it is wrong, then what would be the proper solution? I have one that suits my application, but it is not very general. It works like this: The worker thread that is processing the InputStream blocks on every read() call. But after each read() call I will insert a check for any data the UI thread has set aside for output. If there is anything there, then I will write it out, signal the main UI thread that I have sent out that data, and then loop back to the blocking call on read(). The reason that this solution is not general is that it relies on the application being one where InputStream data is coming in regularly, regardless of data being sent out. Otherwise the worker thread might block indefinitely on the read() even though there is data waiting to be sent out on the OutputStream. Fortunately my application is not of this sort. The InputStream receives data every 100 msec., and my OutputStream data can afford to wait until the next completed read() to send out its data. I suppose a more general solution would be to create two separate threads - one for the InputStream and one for the OutputStream. Has anyone here ever taken that approach? (By the way, BCS, I am well aware that a chunk of code is not inherently in one thread or another, but in the example cited, it is clear that the write() method was called from main UI thread.) -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
