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 <[email protected]> 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 <[email protected]> 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 [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 -- 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
