How to design a basic socket client application

It all depends on the application you want to do, I will answer in a generic way so that you apply the use on different occasions.

1. it is recommended to delegate connection management (connect, disconnect) and sending messages to a separate class (by example a Singleton)?

See this: https://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons

Some programmers consider Singleton an" anti-pattern", avoid using it, it can brings you barriers while developing the application. But yes, you should have one class specialized in receiving connections, another to create connections and one shared by the previous two to transmit your messages, reduce the scope to this at this stage to avoid any unnecessary coupling (Activties for example, these classes do not know that they exist).

1. the use of broadcasts to pass an incoming message to the current Activity seems to be the appropriate choice in the case of a relatively simple application architecture. Does anyone disagree? It would be preferable an event Bus or else coupling (bind) to a service?

The application is simple, so its code should be simple, but on occasions when multiple Activities can receive messages, notifications, alerts, etc delegate all these tasks to a "Bound Service".

Http://developer.android.com/guide/components/bound-services.html

Use the service to send and receive messages over the network and it can create notifications about new messages.

1. the system is expected to kill the application process to free up memory, but the connection must be reestablished as soon as there is memory available for this. What is the best way to do this? Schedule periodic connection checks via AlarmManager does not seem to me proper, and neither use startForeground (), which besides not ensuring that the process is killed (just makes it less likely to happen) it still displays the user an annoying notification that the app is running, which on top of that if clicked leads to a screen offering the option to terminate the application. I thought returning START_STICKY in the Service method.startCommand() could help in this sense, but it does not seem to be made for it.

In general, keep this simple:

1. When creating the service: Open Connection

2. Close service( not guaranteed to be called): Try to close connection.

3. Service doesn't have an "onServiceRestoreState" method or something, so you can take advantage of the methods onDestroy, onUnbind, onTrimMemory, startForeGround, stopForeground to undo the connection. use this as well: START_REDELIVER_INTENT . This will that onStartCommand is called again and you can reestablish the connection.

About AlarmManager: https://stackoverflow.com/questions/19411744/android-when-a-service-is-killed-how-can-we-persist-the-service-state-for-late

The use of AlarmManager is designated for tasks that must be performed from time to time, as it says in the question above,

Intensive use of a service is hostile.

Tip: you don't need to be listening for new messages or notifications from a server all the time (imagine the memory load of a server with multiple open connections, many perhaps without transmitting data for long periods). Do periodic checks (let it be every 1 minute if so necessary, open connection to the server, check and close it).

1. I'm not sure how connection reestablishment should work in order to process the queue of messages to be sent. I suppose involve listen to the broadcast CONNECTIVITY_CHANGE or else a connection reestablished. How best to do this, ensuring that the app try to send the messages when possible?

Is trivial, but there are aspects that should be considered: yes, check CONNECTIVITY_CHANGE to know whether or not there is connection available

Monitoring connections

Handle Socket, Tcp, etc exceptions (you can have Network on the device, but the server may be offline or some network error occurs) as a lost connection in your implementation. when performing any action: attempt to send message, read server notifications check this "disconnected state" and if disconnected try reconnecting to send the request.

When you are offline or receive an exception clean the resources (Dispose Socket, Tcp, etc), when you try to reconnect you will create them again.

But in short: when perform network operations you treat the state of the connection.

1. after there is consensus regarding the modeling of the application, I believe it will be necessary to include Wake Locks in the code to prevent the device enters sleep mode while processing incoming messages or placed in the send queue. But I'm not sure which part of the code includes them and would like recommendations. For this I have also the following considerations additional:

A) once the connection established, the device can enter sleep mode quietly that the arrival of data will wake you up. However, it is not guaranteed that these data is processed in its completeness without a Wake Lock, before the apparatus to go back to sleep;

The WakeLook is designed to prevent the device from going into Idle, but this is not a livable means of waking you up when you receive a notification/message.

The most indicated in this case would be the WifiLock which prevents the network device from being turned off when the mobile device goes into Idle.

You will use the aquire method to say that the device cannot turn off your network device, and release after closing connections, terminating the service, or terminating application actions.

B) if the application is asleep and the connection become available, a desirable requirement may be that the row of messages to be sent are processed in their completeness before the apparatus go back to sleep. Not sure where I should add the Wake Lock in that case.

For both WakeLock and WifiLock:

 wakeLock.acquire();
 this.processQueue();
 wakeLock.release();

C) same as the library that works with the communication protocol chosen is prepared to work with Android (i.e., manage input / output on one or more threads in the thread of UI), it may be that it is programmed to run your callbacks (in particular the callback you receive messages) in the UI thread. This may affect the way I dispose the Wake Locks in my code.

Yes, keep the WakeLocks inside the classes that manage the messages (like coupling, maybe an IoC here) and try to keep the code "Thread-Safe", the rest is on account of dependency injection.

1. there is a need to keep an active thread in continuous loop to maintain the connection open? How can I avoid this?

If you need the connection open all the time: yes (not recommended) in some Thread it will need to be (this is inevitable), it does not need to be looped, but the process can be Idle, waiting for the messages. Keeping a connection open for long periods is well prone to failure( especially mobile networks), consider that the client questions the server about notifications over long periods instead of keeping the connection open and wait for messages.