I'm trying to update my codebase to use ThreadPoolExecutor, but I found
this to be odd:
/** @hide */
public static void setDefaultExecutor(Executor exec) {
sDefaultExecutor = exec;
}
So why is this method hidden? So I can't globally set the DefaultExecutor
to ThreadPool? Or is this subject to change that is why its marked as
@hide?
Currently the Solution I came up with is subclass the AsyncTask:
public abstract class ThreadPoolAsyncTask<Params, Progress, Result>
extendsAsyncTask<Params, Progress, Result> {
public void executeOnThreadPool(Params...params) {
/*
* This is a helper method to allow ICS AsyncTask to run in a thread pool,
* without break API compatability with pre-ICS devices.
* If you don't want a threadpool use the default AsyncTask since that is
the
* default for ICS. If you don't want a threadpool for pre-ICS (API level
< 13)
* then you need to write your own AsyncTask. Use the AsyncTask.java source
as a starting point.
*/
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
this.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
} else {
this.execute(params);
}
}
}
I'm just wondering if this is the best solution? That way I can use a
ThreadPoolAsyncTask if I really want Parallel task and use AsyncTask
directly if I want Serial execution.
Am I understanding this correctly?
Thanks,
On Friday, April 20, 2012 3:16:35 PM UTC-4, 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
