Edward Hinchliffe wrote: > 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.
OK, so thread 1 is blocking on network I/O, so that makes sense. > Thread 2 will parse the message > into an object and interpret it. OK. > 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. Ugh. > The third (conceptual) thread would 'do work' based on the message > received from thread 2. Egad. > 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. A noble goal. > 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! Are you absolutely sure there's no existing Java library that handles your network I/O for you? I read your description and, if this were Ruby, I'd say you need a finite state machine using EventMachine as the foundation. Frankly, I don't know the Java equivalent of this. I always find some existing JAR that handles all the low-level socket work for me. Sorry I barked up the wrong tree. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, $35/Year
-- 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
