Long-Running Services and User Acceptance
a fairly extensive thread
in progress on the
Google Group, discussing the behavior of long-running services.
Unfortunately, the original poster on that thread drew incorrect conclusions from his market research. He found that there were other apps like the one he wanted to create, that used long-running services, and that those apps had decent ratings. His conclusion is that there is no problem with long-running services. Along the way, he ignores not only all the problems with his analysis (including low sample size and sampling bias), but also all the evidence that points to the contrary, such as the millions of users of so-called “task killers”.
However, he does have a point. Long-running services are not intrinsically user-hostile. The issue is not the service — the issue is the control over the service.
If I examine the Running tab of the Apps screen in Settings on my Galaxy Nexus, I see that both of these apps have “1 process and 1 service”. Yet, I am sincerely frustrated at United Airlines and worry not a whit about Ambling BookPlayer Pro.
Why? Control, and to a lesser extent, sensibility.
It is entirely possible that there is a reason why the United Airlines app would need a service. However, there is no obvious need for why it would need a service running all the damn time. I have not run the app in days. I have no control over whether this service is used, short of getting rid of it from Settings. I tend not to bother, but it frustrates me, and I can easily see other users attacking the United Airlines app with task killers to try to get rid of the service.
Contrast that with Ambling BookPlayer Pro. It too has a service running all the time. In fact, its process consumes almost twice as much RAM as does the United Airlines app, so in theory I should be twice as annoyed. But I am not.
I know why the service is there — it is waiting for headset plug events
I value the service being there, as I like being able to just plug my phone into my Prius and not necessarily have to fumble with the touchscreen to get the audiobook playing again
It is a foreground service, so I have an icon that I can get to where I can stop the service through the player’s UI
The only thing that it is missing is an obvious way to prevent the service from running in the first place, albeit at the cost of not handling headset plug events.
Ideally, you do not have an everlasting service in the first place, and use polling or other techniques. If, however, you have a technically justifiable reason for trying to have a service run constantly, ensure that the user knows why the service is there and give the user the ability to control the service behavior, including disabling the service outright at the cost of some functionality. Those items should help improve user acceptance of your everlasting service and reduce the percentage of bad reviews because of your service.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!