Question

I have app A whose every say 3 seconds asks app B to do get some data and save it. After this data is saved A doesn't really need to ask B service again, but it does so just in case the user erases B's data (in that case data will be created over again on the next call).

I don't really know how battery expensive it is to call a service every 3 seconds (does it wakes up the whole app?). I was thinking that A may read a property (via ContentProvider?) from B; however, at the end A would be asking the ContentProvider every 3 seconds to know if it should or not call the service.

The best thing about ContentProvider is that it can return a result (can Service do this?) and if it is an "ok message" then A won't ask B again during the next day or so.

So,

The thing is that Service is already developed and ContentProvider isn't.

Is it worth to create the ContentProviedr or calling the Service doesn't really consume any battery? Taking into account that subsequent calls to the service will just ignore the processing as the data is already created.

Was it helpful?

Solution

After this data is saved A doesn't really need to ask B service again, but it does so just in case the user erases B's data (in that case data will be created over again on the next call).

Then monitor ACTION_PACKAGE_DATA_CLEARED broadcasts to know when the user erase's B's data. You can do this from a manifest-registered receiver, so neither App A nor App B need to be running for you to find out that the user cleared B's data.

I don't really know how battery expensive it is to call a service every 3 seconds

Keeping two apps running constantly, with IPC and disk I/O every three seconds, is the sort of thing that may get you burned in effigy.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top