Should Android SignalR be implemented as a Service or IntentService?

Question

In my Android app, I implement a SignalR connection ( https://github.com/erizet/SignalA ) to connect to a hub server to send requests and receive responses.

A sample of my code is as follows:

signalAConnection = new com.zsoft.SignalA.Connection(Constants.getHubUrl(), this, new LongPollingTransport()) { @Override public void OnError(Exception exception) { } @Override public void OnMessage(String message) { } @Override public void OnStateChanged(StateBase oldState, StateBase newState) { } }; if (signalAConnection != null) signalAConnection.Start(); 

There is also a send bit

 signalAConnection.Send(hubMessageJson, new SendCallback() { public void OnError(Exception ex) { } public void OnSent(CharSequence message) { } }); 

Sending and receiving will be performed through active actions, and some responses will be sent at arbitrary points of time regardless of activity, you should also open the connection while the application is running (even if the application is running in the background), why do I want to implement signalA connection in background service quality

The question is whether I should implement it as:

1 - Service ( http://developer.android.com/reference/android/app/Service.html )

OR

2 - Intent Service ( http://developer.android.com/training/run-background-service/create-service.html )

Remembering that I will need to send lines to the service and receive response lines from the service.

I would be very grateful if someone would show me how to implement this kind of connection in the code as a background service / intenservice.

Thanks for reading.

UPDATE:

Please check out this developer demo as he implemented SignalA https://github.com/erizet/SignalA/blob/master/Demo/src/com/zsoft/SignalADemo/DemoActivity.java

The problem is that AQuery (which I don't know anything about) is used in this demo. Does AQuery constantly work in the background? The problem is that the latest update to SignalA mentions the following

I changed the transport. LongPolling now uses the basic-http-client instead of Aquery for http communication. I removed all dependencies from Aquery.

Therefore, I am not sure whether I should follow this demo activity or not.

Update 2:

This is what confuses me more in IntentService. The OnHandleIntent method calls stopSelf after completing its tasks, when I really want the code in IntentService to keep working all the time

protected abstract void onHandleIntent (intent intent) Added to API level 3 This method is called on a workflow with a processing request. Only one Intent is processed at a time, but processing occurs in a workflow that runs independently of other application logic. Thus, if this code takes a lot of time, it will delay other requests to the same IntentService, but it will not delay anything. When all requests are processed, the IntentService stops, so you should not call stopSelf ().

Answer 1

SignalA runs in a thread that creates and starts a connection, but all network access is performed in the background. The rest of the work on the original thread is very easy, so it’s quite normal to do this on the protectors of the interface.

To answer your question, you need to have a thread controlling the signaling connection. Therefore, I believe that the service is the best choice, because SignalA should constantly work.

Regarding Aquery and the demo project. I removed all dependencies to Aquery in the libraries, not in the demo. To be clear, you do not need Aquery to run SignalA.

Answer 2

In my case, what I wanted was a service, not a service of intent, as I need something that will work until the application closes