On Fri, Apr 20, 2012 at 3:16 PM, Nathan <[email protected]> wrote: > If I understand right, the default behavior of execute is changing to one > single thread pool with only one thread?
I have not been able to confirm that this change is in place. When I try testing a bunch of tasks, they seem to execute in parallel, even on 4.0.3 (haven't tried 4.0.4 yet). > Does that mean, that absent some code changes, all asynctasks inside a > process will only happen sequentially? Once this change takes effect (if it has not already), then yes. > So therefore, if I have a service running DownloadDictionaryTask in the > background, and the user chooses a menu item that starts CheckDiskSpaceTask, > the progress bar will cycle without any progress because the task never > makes progress? Yes. Either use the supplied pooled executor with executeOnExecutor(), or move one of those things out of AsyncTask (e.g., DownloadDictionaryTask might be better as an IntentService, if it is supposed to keep rolling even if the user leaves the app). > A user and I could briefly reproduce a situation where, as far as I could > tell, no asynctasks were running, yet my AsyncTask would not even start. In > this case, I couldn't even get one thread. Alas, I cannot reproduce that > situation, which appeared to fix itself without any code changes. If you come up with a reproducible scenario that demonstrates that the default executor is the single-threaded one, I'd be interested in taking a peek at it. > But in any case, this isn't really acceptable to have only one asynctask > task run at once. But there is no central way to control that behavior, is > there? I would have to replace 83 instances of task.execute with > task.executeonExecutor. Since the above method is only available in SDK>11, > this isn't a one line change - it's more like 10-20 lines of code with > reflection, and some extensive testing. You wouldn't necessarily need to use reflection. Set your build target to 11+ and create your own static execute() method somewhere that, based on API level, uses execute() or executeOnExecutor() directly. It's a code change, though, regardless. Another possibility would be for you to grab an older AsyncTask out of github.com/android, refactor it into your own package, and change your import statements to use it instead of the stock AsyncTask. > In my opinion, this a deplorable punishment for those developers who have > dutifully followed the AsyncTask pattern, which, to this day, the Android > platform has encouraged. You certainly won't get any argument from me on this. My gast was most certainly flabbered when Romain Guy mentioned this possibility a year-plus ago. > Or perhaps I am reading this wrong. Maybe all DownloadDictionaryTasks share > one pool, and all CheckDiskSpaceTasks share another pool. The pool is static at the AsyncTask level. Hence, all subclasses share a single pool, unless I'm seriously missing something. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.7 Available! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
