The real problem that is see with this change is that while you can modify all of your own uses of AsyncTask to suit you can be entirely hamstrung by one or more 3rd-party libraries that are also using AsyncTasks.
Personally I've been using my own replication of AsyncTask for the last 12 months as it avoided changes of threading behaviour between sdk versions. But even good 3rd party libraries can cut down down due to changes in policy like this. William On Saturday, April 21, 2012 5:16:35 AM UTC+10, Nathan wrote: > > Still adjusting to the changes in Android 4.0 regarding AsyncTask. > > If I understand right, the default behavior of execute is changing to one > single thread pool with only one thread? With the reason cited that > programmers are not capable of handling a bigger threadpool (I'm > paraphrasing). > > Does that mean, that absent some code changes, all asynctasks inside a > process will only happen sequentially? > > 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? > > 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. > > 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. > > 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. > > Or perhaps I am reading this wrong. Maybe all DownloadDictionaryTasks > share one pool, and all CheckDiskSpaceTasks share another pool. In that > case, the rule is that only one task *of the same concrete type* can run at > once. This rule, I can probably live with, as I've used my own threading > pools for tasks that are truly data parallel. > > Can anyone enlighten me more? > > Nathan > > -- 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
