> The experience I shared there was practical - and there are times and > requirements when you do need to start a service at the boot time, and > it's really better to run it in a separate process. For example, any > mail-like application would have such requirements.
Autostart might be useful, but usually the service doesn't need to run all the time. I'd stop the service after retrieving mail (unless it's bound, i.e. an activity is visible, of course) and use AlarmManager to schedule the next update. OK, push mail might be a different story... However in my experience, many users don't check "running services" but use task managers, where services are listed once they ran to handle a broadcast and are stopped for ages, so you'd get complaints about "always running services" anyway. ;) > It's probably the > simplicity of the functionality of that small example that makes the > chosen architecture look a bit overshot. Partly that, partly because of the huge amount of misunderstandings in several other blogs, books and forums, partly because of weird behaviour on some devices and/or older Android versions. E.g. I had some troubles with local services that were suspended when the activity of the same app was left (yes, I did startService before bindService - pretty mean pitfall for beginners btw.), so I did a remote service. Now it works as local service as well, I assume android:exported="true" did the trick... > Now, I would be happy to hear something about the loopers and the > handlers. :) Just one note: I think Services do have internal Loopers as well, not just the UI thread. -- 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
