Is it worth threading the TCP client implementation?

Question

Java

Previously, C++ & Qt worked, things were different there, perhaps even simpler.

Now there is a task to write TcpClient for android, that is, in Java. So, naturally, you need to process requests from the server, and be able to receive it yourself. So far, I have settled on the idea that this is to divide the work of the client into two threads, one, for example, receives requests from the server and processes them. The second thread, actually gui itself and sending requests.

What do you think? Is it possible to choose a better path? I would like to listen to people who worked in this area, maybe someone can advise a good link to an example with code, unfortunately I have not yet found src on the Internet that would help me.

Answer 1

You are doing everything right. GUI in the vast majority of cases is taken out in one thread. In addition, an arbitrary number of threads is used for background tasks, receiving packets (including tcp), sending requests, etc.
Offhand - after receiving each packet, listeners twitch, which update the UI.
When I have time, I'll look for something specific.

Answer 2

And there it is impossible to use select?
And transfer the interface to the second thread, as a result, the interface will not slow down from the work of the tcpclient