> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment