How is the rest of your game currently implemented? Are you using a game oriented library, or Swing, or something else?

No I am not using a new game library.

Its a multiplayer game, something like Checkers, implemented in Java.

The client application runs on Android.

The server is just a simple TCP server(decided not to use UDP since its not realtime game) which sends/received messages using Json.

The Client responsible for player movements, and sends to Server the move for authentication(client received an ACK).

The server sends to opponent the other player movement.

BTW, there is no select() in Java(there is the option to use NIO or MINA)

I decided that each client will have 2 threads: one for reading and one for writing, to mimic non-blocking I/O

Please feel free to advice since its my first time implementing a game.

Thx

why is it bad for the client to block after 'recv()' method?

Because the client may also want to respond to user interaction (in the UI) or send chat messages or (if mobile) respond to battery event, network status events, etc.

there is no select() in Java

You can use nio Selectors. Or, since you are on Android, you can use one of the many asynchronous networking libraries that exist. Or just use AsyncTask.

I was thinking about using AsyncTask but, according to Docs: AsyncTasks should ideally be used for short operations (a few seconds at the most.)

and my client app can wait, in worst case if opponent not make a move, for 15 seconds before turn switch back to him.

More over, when the Activity is destroyed, the AsyncTask will still runs, and if you do stuff in onPostExecute() and try to refer to views of the destroyed Activity, you will receive an Exception.

when the Activity is destroyed, the AsyncTask will still runs, and if you do stuff in onPostExecute() and try to refer to views of the destroyed Activity, you will receive an Exception

Yes, threaded code requires that you use proper safe coding and notification of users. Even if an AsyncTask doesn't support cancellation, it can support detecting that the view has gone away and stop talking to it.

Ok I will use AsyncTask.

I currently stuck in a critical decision point, and I really need your help!

I already said its my first game implementation and I don't know if my architecture is correct.

Note: I am using Java/Android.

In my Activity, I have 2 objects:

1) Game - which is the game's board and all the game rules including the game loop.
the player plays according to GameState.

2) ConnectionThread with 2 mainly methods:

2.1) onRead() runs in endless loop and wait for server response.

When a response received it notify both Game object and Activity.
A response is used to notify player if he should WAIT/TURN, or to update opponent's soldiers after moving.

2.2) onWrite(String Message) just sends a message to server, and exits

Game & Activity assign a callback to Connection's onRead() method so they could be notified if new message received

And Game also has ConnectionThread reference, so it could use its onWrite() method to sends about his moves

Is this technique is the right way to implement, or should I do something else?

Thx

It's impossible to tell based on your description. As long as you solve synchronization such that you never get deadlocks, you're probably OK. Also, you don't want to be spawning a new thread each time you have anything to send to the server, but rather re-use a worker thread that pulls data to send from a queue.

Also, you generally don't want to be notifying more than one piece of the application about incoming data. Instead, it's common to use a model-view-controller system where the network acts as controller, and affects the model; the view then gets notified by the model when data changes. One set of data might be "whose turn is it?" and when that changes, the view changes how it displays itself.