Best way to implement Socket.io in android

ImMathan picture ImMathan · Aug 19, 2015 · Viewed 8.1k times · Source

I am planning to implement Socket.io in android by this library for a chat based application. As far as I understood the library seems to be pretty good. I want to know how to maintain a single socket connection throughout the app all the time? Here I have listed out ways to achieve, in which I need the best and stable way.

Three ways

MainApplication Class extends Application

By this we have a good scope that the socket connection is maintained in the main thread( or application's life cycle) and whenever the socket instance is needed from the activity we can get it easily. But it's main thread which also the problem. It might block the main thread.

BoundService

By this way we can bind the service with the activities and we can simply use it. Doing in separate thread is the way to achieve IO/Network calls. But cross processing transfer is more expensive than directly accessing in same process.

Singleton

Maintaining connection in Singleton also makes sense. But we don't know when the instance is killed by process, because it doesn't work in activity life cycle.

If I makes sense please help me out. If not comment it out.

Edit

I have given the answer which is more suitable for me.

Answer

Ofek Ron picture Ofek Ron · Aug 23, 2015

First of all, the Application's onCreate() is irrelevant in your use case because you can't have a thread running in the background when it was first initiated in a non service code.

Also, I would recommend using Google Cloud Messaging instead of creating your own mechanism. It would be best for the device's battery life and much less code for you to handle.

If you do want to implement that chat completely on your own, Service is your only choice. You can also combine it with a singleton, but I wouldn't recommend that approach. You can use broadcasts and BroadcastReceiver for communicating between your Service and Activity, I think it is easier than a Bound Service since bounding to the service is asynchronous and it creates a lot of mess compared to simple broadcasting.