I can think, a lot of people dont get it on that thread thing which
you clearly seem to grasp,... anyway you write "code" for any data the
UI thread has set aside for output and just put that right after the
read ( where ever you put that ) and so it is like:
Thread WorkerThread( Object referenceToWhereItAllStarted){
// now you can drive the UI from the WorkerThread ..
Object UIThing = referenceToWhereItAllStarted; //
All you have to do to implement the "two thread" solution is go read
enough "bouncing balls" demo code until one is not propagating
blunders like "double checked locking" and it is even possible to have
both threads driving the same exact code with nothing more than
storage class synchronized
Everybody give Barrier as the canonical Thread Demo but that is not
how my mind works ~ barriers are true evil cloaked in code
you write a few checks and if code does not "complete" in some
reasonable time then doSomethingElse(); ( or just runs in a loop on
boolean done )
doSomethingElse(); does not have to be exit - you can write handlers
for that state to suit both your code style as well as customer/
application constraints
a lot of people would not be able to sync() on new
Thread(this).start();
my suggestion for what you have described is not to do waits on 100ms
but rather just do checks on the style of
if
( time dot now )
<
( time + wait )
{return;}
else { doSomething();}
you usually get the timecheck backwards but they have it right in the
Timer classes you just have to give yourself dozens of times coding it
and not think you got it right until you cannot prove your code wrong
for the code you are describing the os / system should have effective
wrappers around all the driver code such that it runs correctly and if
not trying to fix it results in good guesses that end up with weekend
calls or whole company in ruination
if you have crash-boxes you can test to destruction on it you are way
ahead of the unlucky ...
On Nov 12, 8:24 pm, RLScott <fixthatpi...@yahoo.com> wrote:
> On Nov 12, 7:57 pm, BCS <fa829...@gmail.com> 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 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