0

my knowledge of services in any operating system, is that they usually run in the background and perform whatever work they have to do.

but the first time I got familiarized with android services, I got confused.

it appears they only run when the application is working, and that for me, makes them no more then sophisticated threads.

do I have this all wrong? how do I make a service that runs when the application doesn't? (so that I can check for updates and create notifications for the user that will then lead him to the application if he chooses to open them). does push notifications have anything to do with it?

Edit:

thank you guys for your answers so far. my problem seems to be the fact that the service is only started officialy when the device is booted up. I do call startService when the app starts, but that doesn't seem to help. the service still dies when the app is turned off (unless it was booted) also I never call stopService

Amir.F
  • 1,911
  • 7
  • 29
  • 52
  • Broadcast receivers are made to react on events in the system like e.g. on boot or on a particular time. They can start a service. Technically a service is always part of an application and the application runs in some way if the service runs – Michael Butscher Aug 11 '13 at 10:03
  • I have used this , but it didn't seem to work all the time – Amir.F Aug 11 '13 at 10:07
  • maybe it has to do with the fact that I bind it and unbind it when you turn the app on and then off, and then the service is shutdown – Amir.F Aug 11 '13 at 10:09
  • 1
    If you only use `bindService()` to access the service then this is the problem. But if you additionally call `startService()` (e.g. in the broadcast receiver) it should stay alive (as long as it wasn't stopped explicitly or by resource demand). – Michael Butscher Aug 11 '13 at 10:16
  • I am now editing my question, as my problem appears to be the fact that the schedule receiver (which uses an alarmManager), does not start until the device is booted – Amir.F Aug 11 '13 at 13:40

2 Answers2

2

If you are trying to implement a long running task that is performed in a (background) service, you have to start one or more threads within your service. So the service just gives you the opportunity to have an application context without having to have a user interface ;) you can consider it as a kind of container.

This page give you a nice overview about different thread approaches in Android. As you can see a service has not its own thread.

Anyway, in your case it seems that an AlarmManager is probably the better option. Running services for polling information all the time can be quite CPU and battery consuming (see this post for instance). So try to avoid having threads that run all the time.

If you can push information about updates from a server it's just fine. Check out Googles Cloud Messaging in this case.

Community
  • 1
  • 1
Trinimon
  • 13,839
  • 9
  • 44
  • 60
  • your answer is nice, I love that link, I am now editing my question, as my problem appears to be the fact that the schedule receiver (which uses an alarmManager), does not start until the device is booted – Amir.F Aug 11 '13 at 13:39
0

Michael who commented on my question first was right in his comment about startService()

so it goes like this:

  • my receiver is only activated on boot, and uses an AlarmManager to time the service to certain intervals.
  • what I did was to bind the activities to the service. if the service was off and I binded it and unbinded it, then by the time the app was terminated, there was nothing keeping it alive.
  • by simply making sure that the service was started properly with startService if it is not already on, I managed to keep the service alive at all times
  • also thanks to Trinimon who gave a very nice explanation on what services are, and the importance of not overloading the CPU with excessive polling. (which is kind of a trade off situation)

good luck to all :)

Amir.F
  • 1,911
  • 7
  • 29
  • 52