(This question is also asked in Portuguese .)
First of all, apologies for the long text and for asking so many questions in one question. I thought it would be better to do this because they are interconnected, and also because I think that anyone who has experience in such an application (an Android socket client that maintains a constant connection to the server to send / receive messages) , will be able to answer all or many of these points. Basically, I ask for advice on several design decisions, which I'm not sure about what the “recommended Android method” is.
I am trying to establish what is the best way to implement such an application (socket client) in Android. He will use socket communication technology, such as WebSocket, Socket.IO, TCP, etc., to maintain a constant connection with a remote server to exchange information. I do not have a specific use case, except that it probably will not be a chat application, since the preferred technology for this is push notification (GCM or something similar). I am thinking of an application that keeps the connection open while the user is "logged in".
The connection should not be tied to the actions of the application, that is, messages can be received after the user has left the application (eventually creating a notification).
The questions I'm trying to answer to identify such an application:
Should connection processing (connection / disconnection) and message sending be delegated to a separate class (e.g. Singleton)?
The selection of gears for transmitting received messages to the current Activity looks fine; is there a more suitable solution? Could an event bus or Service binding be preferred, even if the application architecture is pretty simple?
Given that the connection must be maintained during the kill process (as the system usually does to free memory), the best approach would be to delegate the "connect" action to the Service with an overridden startCommand() method returns START_STICKY (which allows you to restart the Service as soon as it is available system memory)? Is this the most appropriate approach? I assume that since setting periodic connection checks in AlarmManager sounds unnecessary in this case, and using startForeground() does not prevent the application from killing (it just makes it less likely), it also shows an unwanted notification to the user that the application is working.
As soon as we agree on the design, I believe that it will be necessary to add tracking locks to it so that the device does not remain / remain awake during the processing of incoming / outgoing data. I am not sure how to add them to the final design, although I ask for clarification on this. I have in mind the following additional considerations:
a) It is expected that incoming data will awaken the device, but are not guaranteed to be fully processed before it returns to sleep mode;
b) The fact that the device sleeps when a connection to the server becomes available (which is signaled by CONNECTIVITY_CHANGE broadcasting) should not prevent the sending of several outgoing messages in the application, however I don’t know how to add Wake Lock to this project so that guarantee complete queue processing;
c) My protocol library can be prepared to work with Android (i.e. it handles I / O on one or more threads other than the UI), but its callbacks cannot be guaranteed to run on a thread other than the UI (the library can delegate them to the user interface stream). This may affect how I remove Wake locks through code.
Do I need to maintain an active thread loop to open a connection? How can I get around this?
Any feedback on these issues is welcome.
source share