3

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!

Egor
  • 39,695
  • 10
  • 113
  • 130
CompEng88
  • 1,336
  • 14
  • 25

3 Answers3

5

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.

Snicolas
  • 37,840
  • 15
  • 114
  • 173
  • The [**RandomMusicPlayer**](http://developer.android.com/resources/samples/RandomMusicPlayer/index.html) example on developer.android.com is a good starting point when implementing a music (or chat) service that requires internet access and runs in the foreground. – Jens Feb 29 '12 at 08:12
  • I am able to as of now, run different apps and still be notified when I get a new message without using a service (the AsyncTask is in the background running always). And if I want to access resources between Activities, I use singletons and a static reference in my Application class so that's no problem either (no binding for services is needed for each activity). As far as sending notifications, any activity can send a notification by obtaining the NotificationManager. As far as I can tell, even in the service I will need to create an AsyncTask either way. I'm not sure if I see a difference. – CompEng88 Mar 01 '12 at 05:51
0

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.

Simon
  • 451
  • 2
  • 9
  • 19
0

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.

Community
  • 1
  • 1
Knossos
  • 15,802
  • 10
  • 54
  • 91
  • I've tried XMPP actually. It has a lot of what I was looking for, but I wanted more control over what goes into the database, etc. Building my own server seemed ideal for the control I was looking for and I am more than capable. – CompEng88 Mar 01 '12 at 05:54