views:

258

answers:

1

I'm developing an app that checks several conditions during an incoming phone call. The main parts of the app are a BroadcastReceiver listening for Intents related to the phone's status and a local Service checking the conditions.

At the moment the service is started each time an incoming call is detected and is stopped when the phone status changed back to idle.

Now I'm wondering if this procedure is correct and whether it is reasonable to start and stop the service related to the phone's status. Or would it be better to let the service run regardless of the phone's status and bind/unbind to/from it when needed.

Are there any performance issues I would have to think about? Perhaps it is more expensive to start/stop a service than letting it run and communicate with it. Are there any best practices out there regarding the implementation of services?

+3  A: 

Or would it be better to let the service run regardless of the phone's status and bind/unbind to/from it when needed.

Please don't. It will just take up RAM for no good reason. It is everlasting services like this that cause users to attack developers with task killers.

Are there any best practices out there regarding the implementation of services?

Here are two of my posts on the subject, for what they're worth.

CommonsWare
Also: when an `Activity` binds to a `Service`, the `Service` lives as long as there are bonds to it. When the last `Activity` unbinds the `Service` finishes().
MrSnowflake
That assumes it's a bind/unbind pattern, which does not work with `BroadcastReceiver`. A `BroadcastReceiver` needs to use start/stop -- it cannot bind (let alone unbind). Hence, I was assuming the OP meant to start the service and leave the service running.
CommonsWare