Saturday, November 12, 2011

[android-developers] Re: Does this Bluetooth call execute in the UI thread?

the official Bluetooth sample show the main UI calling a blocking 
method because it is wrong ~ I went through a not-dis-similar issue
with an experienced code engineer with a lifetime of writing code
trying to explain to a musician from euro trying to get a midi device
coded - a "thread" is a path of exec and other than a few system
issues around security and reliability has ( usually ) almost no
effect on what happens or how and why it happens = the sooner you can
call start() on a thread and let it run the sooner the "main()" thread
can release

if you block it you throw ANR = simple / factual / real

there are several issues that get too convoluted to figure out in a
simple discussion group post but I got it working after a while ~ this
android thing already has a major portion of what is hard to figure
out already boiler-plated in with an event-handler implemented as
interfaces

maybe not here ~ fast read looks like:

BluetoothAdapter.getDefaultAdapter()

which would be in a run method of a class you write then you just do
Thread yourClassObject dot start() on it which sets it running and do
everything in the code of that class and let "main()" return ....

a "thread" is actually an instruction pointer in the cpu ~ not the
code you are looking at -the code only describes a path of exec for
the instruction pointer to follow
On Nov 12, 5:15 pm, Kristopher Micinski <krismicin...@gmail.com>
wrote:
> I don't remember offhand, but the code might just be like that, it's
> supposed to be a simple example.  There's an easy way to find out.
> Take your debugger, put a breakpoint on that line of the code and find
> out what thread you're in!
>
> kris
>
>
>
>
>
>
>
> On Sat, Nov 12, 2011 at 11:20 AM, RLScott <fixthatpi...@yahoo.com> wrote:
> > I am trying to understand the Bluetooth example given in the Android
> > Developer docs and I am wondering about this issue:
>
> > The example shows a "ConnectedThread" class which extends the standard
> > Thread class.  There is a custom constructor and a run() method which
> > executes in the newly-created thread, managing the input stream.  But
> > this ConnectedThread class also exposes another method - write(byte[]
> > bytes), which is supposed to be called from the main UI thread.  But
> > doesn't the code in this methods actually execute in the main UI
> > thread?  If so, then why does write(byte[] bytes) look like this:
>
> >    /* Call this from the main Activity to send data to the remote
> > device */
> >    public void write(byte[] bytes) {
> >        try {
> >            mmOutStream.write(bytes);
> >        } catch (IOException e) { }
> >    }
>
> > and are told that mmOutStream.write() is a blocking call.  So why does
> > the official Bluetooth sample show the main UI calling a blocking
> > method, unless this code is somehow executed by the worker thread.
> > But I thought that only the code within the run() method is executed
> > in the worker thread.  Can someone clear up this confusion for me?
>
> > --
> > 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

--
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

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate