Is an always-on Android service ever not an anti-pattern?

Question

I understand why an always-on service is normally an anti-pattern in Android, but my app really seems to be begging for one:

On first load, the app has to go through potentially thousands of small entities from the database to construct the initial state. There's not much data brought into memory (most is lazy loaded later), but that first scan is unavoidable by the nature of the app. This scan can take at worst 6-7 seconds with slow hardware and a big dataset, average is probably around 3. The app is a "impulse use in short bursts" type of thing, so those repeated loads are really not desirable.

I think this begs for a background service to be perpetually alive and holding that state, thus avoiding that load time. It will always be ready to be killed, and not in the foreground, so should the system or user decide that they have it out for the service, no harm is done. But if the service is left in peace, the app will start instantly, and in my case that does a lot for the user experience.

Am I still wrong?

Answer 1

I think this begs for a background service to be perpetually alive and holding that state, thus avoiding that load time.

As the British say, bollocks.

On first load, the app has to go through potentially thousands of small entities from the database to construct the initial state.

Then fix that. Either simplify this work, or persist the initial state in a simpler form for later reuse (eg, JSON).

If it is OK for you to use a cached result of this work that is held in RAM, it is OK for you to use a cached result of this work that is held in an easier-to-read-in persistent data structure.

Answer 2

An "always-on" service would essentially act like a daemon process and there are plenty of services on Android phones that never turn off.

In this case, though, it seems a better solution would be to simply have a splash screen and/or wait dialog that sits there until the data is loaded. It seems like a bad idea to me to take up resources when the app isn't running just so the app will load faster when the user finally opens it. If the average use of the app is much smaller than the load time, then it would probably be even better to speed up the scan in some way.

Answer 3

People use taskkillers to kill such kind of services. My view is, that when you make the user aware of why your service is running (say, this will load the app quicker), he will understand it and not kill it. You could also ofcourse add an option to use the service or not.