Re: [android-developers] Re: Best background practices
I suppose you'd be better off with a service per service instead of one god service. The reason is that it make the code cleaner - you don't need to manage multiple alarms and network connections in one class. An exception would be a service that just does one kind of thing, but handles a queue of requests. To avoid copy and pasting common code, use a common abstract base class that extends Service. -- 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
Re: [android-developers] Re: Best background practices
I'm not a total expert on this... Threads are really just a way of running multiple stacks/program counters in the same address space. It's fair to assume they are time-sliced. Services and Activities are run in a single UI thread (AFAIK) and the precessing model is typical UI thread which calls event methods on them sequentially (they don't really run like classical processes). AsyncTasks run from a thread pool. The first few can run concurrently, but after that the next one can't start until another one is finished. Network connections are also pooled (AFAIK), so that after you open a few, additional ones queue up. To get workable background processing/networking, you'll probably need to use alarms/saved state, since an app's process can be summarily dismissed any time by the OS when other apps need resources. Although some background processing that takes just seconds you might as well do with an AsyncTask in an activity instead of a service. Don't expect SDK apps to get any processing done when the device is sleeping or turned off (I'm sure you know that already). -- 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
Re: [android-developers] Re: Best background practices
On Sat, Aug 28, 2010 at 7:25 PM, Frank Weiss fewe...@gmail.com wrote: I'm not a total expert on this... Threads are really just a way of running multiple stacks/program counters in the same address space. It's fair to assume they are time-sliced. Services and Activities are run in a single UI thread (AFAIK) and the precessing model is typical UI thread which calls event methods on them sequentially (they don't really run like classical processes). AsyncTasks run from a thread pool. The first few can run concurrently, but after that the next one can't start until another one is finished. Network connections are also pooled (AFAIK), so that after you open a few, additional ones queue up. To get workable background processing/networking, you'll probably need to use alarms/saved state, since an app's process can be summarily dismissed any time by the OS when other apps need resources. Although some background processing that takes just seconds you might as well do with an AsyncTask in an activity instead of a service. Don't expect SDK apps to get any processing done when the device is sleeping or turned off (I'm sure you know that already). Thanks a lot. I just needed to know that my direction was the good one. Federico -- 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
