Does anybody know how big the overhead for services in Android is.
And if there are any other argument helping me with the following design decision.
I have two SQLite Dbs, one storing actual data (basically read only product inventory), the other storing settings, lists of selected items, etc.
Now I created a service to take care of manageing these databases, for two main reasons:
From a design perspective, I could either:
It feels cleaner to create a seperate service for each DB, e.g. extending a generic base class to take care of shutdown, timers, etc. It also allows me to configure them independent (which is NOT required right now).
On the other hand, I do not want to start going down this road, and then, when I am used to doing stuff like this in "services" discovering that there is a limit of 3 or 5 services.
So how is the Overhead of e.g. 5 running services, vs. one service hosting 5 different features? Any ideas?
The number of services effectively supported by Android should be nothing to worry about in your situation. Having seen lists of running services in some task managers, I tend to say that up to ~100 "running" services should be no problem on most devices.
However, I'm not sure if what you're trying to do actually should be implemented in a service. Can you elaborate why you think you need a service?
I want to be able to "save on close" (settings), which is possible with the onDestroy
Can't you do this in your normal Activity lifecycle callbacks?
It takes some time to load the data, so a quick close of the app keeps the data in memory
What do you mean by "quick close"? Are you trying to build some sort of cache for the DB data?