Android lifecycle - should I use a service?

Question

I'm creating a chat app and I am wondering if I should use a service and how it will affect the lifecycle of my app. I understand that the Android OS can destroy my app if there isn't enough memory. My question: do apps that only use Activities and Receivers get restarted if Android destroys them or do I need a STICKY Service for this? I've created apps with both, so I have somewhat of an idea, but I just want to make sure.

Second, http://developer.android.com/reference/android/app/Service.html says:

Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work.

My application has a long running thread (AsyncTask) that does the reading from the server (and constantly blocking). Is it a good idea to leave my app as it is, without a service and use the AsyncTask instead? How will this affect the lifecycle of an app if Android chooses to close my app? Is it good practice to have a long running service if there doesn't need to be, as in, should I make a STICKY Service anyway? I noticed a lot of chat and txt msg apps use a sticky service. I'm just trying to think if my app would need one.

Thanks again in advance!

Answer 1

Basically, a service allows to run a task that is not bound to a single activity lifecycle.

For instance you could play music inside of a single activity using normal objects. But if you want your app to play music and allow users to go in and out from all your activities, then you need a service.

If your app has multiple activites and you want your chat client to still listen to sockets (and I bet you do want that), then you should write a service.

If you want users to know that a service is running, then your service your service should go to foreground and allow interaction via the notification bar.

If you want your activities to communicate with your service, then you should bind your service from within your activities.

And last, you should provide a clear way for users to stop your service as this process will no longer be tied to your app lifecycle and you must explicitly call its stop method or call stopService or make the service call stopSelf on itself. Then provide your users an easy way to stop the service.

You will also need to get a powerlock and most probably a wifi lock for your service so that it is not stopped by the device going to sleep and the connection to the net is preserved for your service when your application is cleaned by android.

Answer 2

This isn't a direct answer, but you may want to look into using XMPP.

Android can and will destroy any Activity any time.

I would definitely use a service. You are already using an AsyncTask, so you are fine Thread-wise. If you want replies to your chats while your App isn't in the foreground then a service will be necessary.

Your service could then send a Notification when a new message is received or whatever is required.

Answer 3

I think that you are better of using a Service. The AsyncTask will basically be the same because it runs in a separate thread from the main thread. I have seen some examples in certain conditions AsyncTask beeng paused when leaving the Main UI Thread. I believe that when running out of memory the Service will be restarted rather than just killed but I'm not 100% sure. And long running background task are what Services are for.