> > I don't think so. From a user's point of view, there's no difference > > if there's a started service that's actually doing something by > > Handler.postDelayed every 5 minutes and an app that does the same by a > > repeating AlarmManager. > Sure there is. It's called a "process" and "a big chunk of RAM".
The "big chunk of RAM" remains allocated on most newer devices anyway, because there's usually enough memory to keep several apps there. And the process doesn't use up that much CPU while in message loop idle mode as well. Besides, if not, the RAM has to be allocated and additional initialization work might be necessary for the AlarmManager receiver. But I think in most cases, what's eating up the most CPU (iow "slows down the device" and "eat battery") will be the actual job itself. And, as said, I think for the user the most important part is "hey, this app's still doing something!", not that much how it's realized. Maybe it even would be a good idea to show the interval and next broadcast time, so users are more likely to modify the preferences of apps that are too busy. >From a developer's point of view, there still remain several good reasons to prefer AlarmManager to services whenever possible. And I think the difference between "running" and "ready" (or whatever) should give the user an idea that there's (usually) some difference in resource allocation. > Because it's really easy for developers to accidentally think that > everlasting services are a good idea. IMHO, it is less likely that > they will accidentally make something run every few seconds via > AlarmManager and think that is a good idea. Admitted, "every few seconds" is not very likely, it's been just an extreme example. But intervals from 5 to 15 minutes aren't. > > In theory, that's true. But an official way to do that is an entirely > > different thing than a private campaign that might even end up with > > dozens of concurring intents because every task manager developer > > wants his own package name contained. > That would not be "a convention". That's the problem. As a common user, I could just make a proposition, everybody can make of it what he wants. It's an entirely different pair of shoes with official android.intent.action.* Intents. And I wouldn't dare to propose something like android.intent.action.STOP_BACKGOUND, this namespace (package) is reserverd to official Intents imho. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
