Re: Android / threading ...

On 14/09/12 18:21, Michael Meeks wrote:
> Hi there,
>
>         I just got a crash in the PresentationActivity timerUpdateThread - it's
> not related to this (I think) - but I guess this could cause some
> nasties I suppose. It seems we're talking to the GUI from multiple
> threads concurrently:
As far as I can tell I'm on the main thread when updating the GUI -- my 
"UpdateThread" should actually be a runnable (I've now renamed it as 
such) -- it is never started manually, but is passed to a handler which 
runs the run method on the event/GUI Thread after the specified delay. 
So I don't think it's a threading issue causing the crash.
> http://developer.android.com/guide/components/processes-and-threads.html
>
>         "Additionally, the Andoid UI toolkit is not thread-safe. So, you must
> not manipulate your UI from a worker thread—you must do all manipulation
> to your user interface from the UI thread. Thus, there are simply two
> rules to Android's single thread model:
>
>       1. Do not block the UI thread
>       2. Do not access the Android UI toolkit from outside the UI thread"
>
>         I was also amused to stumble over this:
>
> http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
>
>         Which is quite amusing ;-) Anyhow - perhaps I'm missing something - I
> don't know what mTimeLabel.setText really does so ...
>
>         Are we doing our slower IPC in a thread and leaving the main thread to
> render ? (things are responsive so I assume so generally :-).
All the networking code is run in a separate thread (as required by 
android docs -- networking on the GUI thread results in errors being 
thrown -- except for writing to a stream). As far as I can tell all the 
GUI work is done in the GUI thread, with the timer update and any 
broadcasts from the background threads simply being handled as events on 
the GUI thread.

A summary of threads (to the best of my knowledge):

- GUI/event thread -- run by android, handles the timerUpdate events, 
and Broadcasts from the networking threads.
- Network handling thread: deals with connecting to a server (i.e. the 
opening of a socket, up until sending a pin) and spawning the Client 
thread as necessary.
- Client thread: listens to the network/bluetooth socket, and sends out 
broadcasts to the UI as appropriate when appropriate data is received on 
the socket.

I.e. as far as I can tell all UI work is done on the correct thread. 
What is however more complicated is the lifecycle of the activity and 
service, which has caused some issues (which is why that 
mCommunicationService==null check was needed), etc.


Cheers,

Andrzej