Thanks mark for the speedy response as always. Thread 1 is listening for messages (in xml format) on a TCP socket and is sending the string over to thread 2. Thread 2 will parse the message into an object and interpret it. Thread 2 can also accept message objects and build an xml string, which it'll then pass to thread 1 to send back via TCP.
The third (conceptual) thread would 'do work' based on the message received from thread 2. My thinking behind all of these threads is to keep everything *off* the UI thread because the application is a game, and will potentially need to remain responsive to the user. I think I'll have to get a book on the subject as I find it all very hard to get my head around for some reason! 2010/1/9 Mark Murphy <[email protected]> > redders wrote: > > Currently I have two threads, other than the UI thread, which need to > > communicate with each other. > > Why? > > > Thread one needs to be able to send > > messages directly to thread two, and vice versa. > > Why? > > > At the minute, my code looks like this: > > > > runnable1 = new myRunnable(); > > runnable2 = new myOtherRunnable(runnable1); > > runnable1.setOtherRunnable(runnable2); > > sThread = new Thread(runnable1); > > sThread.start(); > > > > Then, inside runnable1, I've got: > > > > public void run() { > > Thread otherThread = new Thread(runnable2); > > .....*snipped code*..... > > if (event){ > > runnable2.sendMessage(message); > > otherThread.interrupt(); > > } > > } > > > > Thread two is in a constant sleep loop, until he is interrupted, at > > which point he'll check his message queue and act on it. > > If you elect to keep the threads, *please* consider using > java.util.concurrent.LinkedBlockingQueue and nuking the > interrupt()/sleep() code. > > > Add the fact I'm going to add a third thread that will also need to > > send messages to and get messages from thread 2, which makes my head > > near to exploding point thinking about it. > > Again, why do you have all of these manually-created threads? What are > they doing? Have you considered AsyncTask? > > > Should I be using callbacks/interfaces? Is there a good place to read > > about this somewhere? I'm very new to this side of things really. > > Tactically, there are some good books on concurrent programming in Java > out there. Anything involving Doug Lea would be a good choice. > > Strategically, it feels to me as if you're going about your problem the > wrong way. I can see having one background thread, listening on a > LinkedBlockingQueue, as an alternative to AsyncTask. I don't know what > the other threads you are creating are supposed to be doing, but I can't > see how they're adding value. > > Please remember that mobile devices have slow single-core CPUs (at > least, from the standpoint of application code), and so there really is > no parallel processing going on, unless you're blocking on I/O (in > Android's case, mostly network I/O). > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://twitter.com/commonsguy > > _Android Programming Tutorials_ Version 1.0 In Print! > > -- > 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]<android-developers%[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
