[android-developers] Re: AsyncTask in Android 4.0
As opposed to all the solutions provided here isn't
if (Build.VERSION.SDK_INT = Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
the wrong check?
Shouldn't it check for the targetSDKVersion instead, as Dianne mentioned?
Sth like this:
if (SystemUtils.getTargetSDKVersion(pContext) = Build.VERSION_CODES.
HONEYCOMB_MR1 SystemUtils.isAndroidVersionOrHigher(Build.VERSION_CODES.
HONEYCOMB)) {
/Nicolas
On Wednesday, October 10, 2012 3:44:03 AM UTC-7, tom wrote:
I like this change. And have used a custom AsyncTask taken from API10 with
the following changes for awhile now.
private static final int CORE_POOL_SIZE = 1;
private static final int MAXIMUM_POOL_SIZE = 1;
ps. hope this is the correct way to get the serial execution on API11.
--
--
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
---
You received this message because you are subscribed to the Google Groups
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: AsyncTask in Android 4.0
I like this change. And have used a custom AsyncTask taken from API10 with the following changes for awhile now. private static final int CORE_POOL_SIZE = 1; private static final int MAXIMUM_POOL_SIZE = 1; ps. hope this is the correct way to get the serial execution on API11. -- 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
[android-developers] Re: AsyncTask in Android 4.0
How about AsyncTaskLoader? Are they effected by this change? (Will loaders not run in parallel if the SDK level is set to 13+?) If so, any work arounds to restore previous behavior? On Apr 20, 4:07 pm, Romain Guy romain...@android.com wrote: There are some subtle activity lifecycle callback changes starting with 3.0, some not so subtle home screen widget changes starting with 4.0... just what comes to mind right away... And don't forget hardware acceleration that gets turned on when targetSdk=14+ -- Romain Guy Android framework engineer romain...@android.com -- 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: AsyncTask in Android 4.0
On Mon, Jun 11, 2012 at 11:32 AM, npike mav...@gmail.com wrote: How about AsyncTaskLoader? Are they effected by this change? (Will loaders not run in parallel if the SDK level is set to 13+?) AsyncTaskLoader specifically opts into the thread pool executor and so will work in parallel. -- 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 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
[android-developers] Re: AsyncTask in Android 4.0
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 ThreadPoolAsyncTaskParams, Progress, Result
extendsAsyncTaskParams, 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 SDK11,
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
[android-developers] Re: AsyncTask in Android 4.0
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).
I'm also trying to figuring out why setDefaultExecutor is hide but public?
/** @hide */
public static void setDefaultExecutor(Executor exec) {
sDefaultExecutor = exec;
}
Is this because it is subject to change and non-framework clients (i.e.
third party dev) should be use this? For my app I wanted to globally change
the Executor to ThreadPool, but that doesn't seem possible.
So what I'm currently doing is subclass the AsyncTask like so:
public abstract class ThreadPoolAsyncTaskParams, Progress, Result
extendsAsyncTaskParams, Progress, Result {
/*
* 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 wrote your own AsyncTask. Use the AsyncTask.java as a
good starting point.
*/
public void executeOnThreadPool(Params...params) {
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 is this is a good solution? This way I can use
ThreadPoolAsyncTask for task that can run in parallel and don't have any
implicit dependence on other tasks. And use AsyncTask directly if i want
them to run in serial.
Thanks,
--
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
[android-developers] Re: AsyncTask in Android 4.0
Hi Michael do you have some good alternative to the current AsyncTask implementation? Anyway the real big big big problem is for the 3rd party library or SDK that my project is currently used. I'm using some ads SDK and I'm pretty sure that they are using also AsyncTask in the normal way so I'm really afraid that their asynctasks will block mine for the serial problem we were discussing. On Saturday, April 21, 2012 5:38:47 AM UTC+2, MichaelEGR wrote: On Apr 20, 12:16 pm, Nathan nathan.d.mel...@gmail.com wrote: 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. Add it to the list... ;) I can't exactly call the unfurling Android SDK responsible API development. Quick and efficient if one judges efficiency by market share. Yes yes everyone works hard on the Android team, so do we your end users. When I saw AsyncTask pop up in 1.5 I thought to myself why oh why is there such a lightweight abstraction being offered over the already fine and dandy Executor framework as AsyncTask doesn't exactly add all too much. Granted I already had a nice abstraction layer on top of the Executor framework carried over from the desktop, so AsyncTask seemed quite moot and as we now see a bit destructive in terms of default behavior when one is trying to target the larger ecosystem. Also I don't have the time to go back and check 1.5 sources for this conversation, but I'd be really curious to see if the original AsyncTask didn't use the Executor framework underneath; that would be telling. I actually planned on discussing this as 1 of 5 main topics for my AnDevCon class coming up next month (Java performance tricks for the troubles); this certainly classifies as a big trouble (more so than I thought with the change in default behavior for AsyncTask) and now it's definitely in the class. I'll present my abstraction over the Executor framework; it's of course component oriented and can easily be extended. The one thing that cracks me up is that with not a whole lot of work one can still use a single ThreadPoolExecutor and simultaneously submit tasks to be run in a single queue manner or all tasks at once up to the pool limit. I also have a long running pending Executor submitter system component that is very handy for the GUI checkbox example a previous poster mentioned that saves state each press of the checkbox. In that particular submitter if a current task is running the latest task is stored as pending, each successive press of the checkbox (or any GUI element) replaces the pending task while one is executing. Instead of queuing up 30 tasks to run with 30 presses of the checkbox if a user rapidly presses the checkbox and there is a long running task kicked off just the first and last presses get tasks submitted. So basically the advice I'm offering is to copy / modify AsyncTask as necessary in ones own package or ditch usage of AsyncTask entirely and adopt a solid existing framework that won't change or simply investigate the Executor framework directly and build your own abstraction. It's the only foolproof way to get reliable task execution across all versions of Android and it is pointless / very bad style to embed conditional logic based on API level to limp along using AsyncTask. I know the Android team is just trying to provide a helper functionality, but to change the default behavior like this is yet another API sin; IMHO This revelation in the change of default behavior really demands an Android Dev blog post and the clearest possible documentation to be posted. -- 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
[android-developers] Re: AsyncTask in Android 4.0
I have concerns of making such major changes implicitly in android. For the developers who follow this thread they are safe, what about the thousands of developers who wont be reading this thread? Any possibility of making such major changes compile failures or deprecate old api and create new api with forced selection of parallel/serial executor. Easier to fix failures at app compile time for all developers, not so easy for each developer who is depending on current parallel asynctask behavior to google search for related asynctask slowness problems and find the cause of this six months down the road when 3.0+ is the default android on majority of devices? -- 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: AsyncTask in Android 4.0
I have to agree with Nathan, I've never read anywhere that AsyncTasks should only be used for short lived tasks (a couple seconds). The official documenation says This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers. Not only is it bad grammer :), it can easily be interpreted as ok to use for most background tasks (not everyone can get direct advice from a framework engineer). On top of that, why would AsyncTasks offer onProgressUpdate if they are only used for tasks that take a couple seconds? That would indicate it's made for long running tasks. Again, a lot of this is over my head, but maybe it helps to see the point of view from an average developer. -Kris http://www.filtrsoft.com Custom news monitoring apps On Saturday, April 21, 2012 6:58:58 PM UTC-4, Romain Guy (Google) wrote: The sole role of AsyncTask was to help not block the UI thread, not offer a fully fledged threading framework since, as you mentioned, the core APIs provide solid foundations for that. The advice I regularly give developers is to use the executor framework directly if they want more control over their tasks. And to answer your question, AsyncTask was already using the executor framework in 1.5. Speaking of 1.5, AsyncTask was using a serialized behavior in that release. This behavior is explained in the current documentation of the execute() method: Note: this function schedules the task on a queue for a single background thread or pool of threads depending on the platform version. When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. After HONEYCOMB, it is planned to change this back to a single thread to avoid common application errors caused by parallel execution. If you truly want parallel execution, you can use the executeOnExecutor(Executor, Params...) version of this method with THREAD_POOL_EXECUTOR; however, see commentary there for warnings on its use. -- Romain Guy Android framework engineer romain...@android.com -- 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
[android-developers] Re: AsyncTask in Android 4.0
On Saturday, 21 April 2012 05:39:30 UTC+2, William Ferguson wrote: 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. This concern could have been addressed with a single line of code, if this private API had been made public: AsyncTask.setDefaultExecutor(AsyncTask.THREAD_POOL_EXECUTOR); But in infinite wisdom, it was decided that developers would use (or abuse) above API wrong and thus this API was made private. So instead of a single line change, if you want the Threaded Executor for all your AsyncTasks you have to find and modify all your execute() calls. -- 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: AsyncTask in Android 4.0
Or one could want default serialized execution on 3.0 and prior, in case of issues in third party code. Looking at this more broadly, this is where I consider the framework somewhat lacking. It contains ready to use solutions for a lot of things, and using them is generally very simple and gets things done quickly. But attempts to customize something or to work around a bug often end at a @hide or final class or method. 21.04.2012 14:19 пользователь b0b pujos.mich...@gmail.com написал: On Saturday, 21 April 2012 05:39:30 UTC+2, William Ferguson wrote: 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. This concern could have been addressed with a single line of code, if this private API had been made public: AsyncTask.setDefaultExecutor(AsyncTask.THREAD_POOL_EXECUTOR); But in infinite wisdom, it was decided that developers would use (or abuse) above API wrong and thus this API was made private. So instead of a single line change, if you want the Threaded Executor for all your AsyncTasks you have to find and modify all your execute() calls. -- 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 -- 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: AsyncTask in Android 4.0
I know the Android team is just trying to provide a helper functionality, but to change the default behavior like this is yet another API sin; IMHO FWIW the parallel/serialized behavior was not initially documented, on purpose. The sole role of AsyncTask was to help not block the UI thread, not offer a fully fledged threading framework since, as you mentioned, the core APIs provide solid foundations for that. The advice I regularly give developers is to use the executor framework directly if they want more control over their tasks. And to answer your question, AsyncTask was already using the executor framework in 1.5. Speaking of 1.5, AsyncTask was using a serialized behavior in that release. This behavior is explained in the current documentation of the execute() method: Note: this function schedules the task on a queue for a single background thread or pool of threads depending on the platform version. When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. After HONEYCOMB, it is planned to change this back to a single thread to avoid common application errors caused by parallel execution. If you truly want parallel execution, you can use the executeOnExecutor(Executor, Params...) version of this method with THREAD_POOL_EXECUTOR; however, see commentary there for warnings on its use. -- Romain Guy Android framework engineer romain...@android.com -- 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
[android-developers] Re: AsyncTask in Android 4.0
Some of this is a little over my head, but from what I can understand, if
the targetSdkVersion is set to 13 or greater and I have a long running
AsyncTask (not exactly sure what is considered a long running task), I
should use this code to execute the AsyncTask?
if(android.os.Build.VERSION.SDK_INT =
android.os.Build.VERSION_CODES.HONEYCOMB) {
task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
} else {
task.execute(params);
}
Does in matter if the AsyncTask is used in a service or not?
-Kris
http://www.filtrsoft.com - Custom news monitoring apps
--
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
[android-developers] Re: AsyncTask in Android 4.0
On Apr 20, 12:16 pm, Nathan nathan.d.mel...@gmail.com wrote: 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. Add it to the list... ;) I can't exactly call the unfurling Android SDK responsible API development. Quick and efficient if one judges efficiency by market share. Yes yes everyone works hard on the Android team, so do we your end users. When I saw AsyncTask pop up in 1.5 I thought to myself why oh why is there such a lightweight abstraction being offered over the already fine and dandy Executor framework as AsyncTask doesn't exactly add all too much. Granted I already had a nice abstraction layer on top of the Executor framework carried over from the desktop, so AsyncTask seemed quite moot and as we now see a bit destructive in terms of default behavior when one is trying to target the larger ecosystem. Also I don't have the time to go back and check 1.5 sources for this conversation, but I'd be really curious to see if the original AsyncTask didn't use the Executor framework underneath; that would be telling. I actually planned on discussing this as 1 of 5 main topics for my AnDevCon class coming up next month (Java performance tricks for the troubles); this certainly classifies as a big trouble (more so than I thought with the change in default behavior for AsyncTask) and now it's definitely in the class. I'll present my abstraction over the Executor framework; it's of course component oriented and can easily be extended. The one thing that cracks me up is that with not a whole lot of work one can still use a single ThreadPoolExecutor and simultaneously submit tasks to be run in a single queue manner or all tasks at once up to the pool limit. I also have a long running pending Executor submitter system component that is very handy for the GUI checkbox example a previous poster mentioned that saves state each press of the checkbox. In that particular submitter if a current task is running the latest task is stored as pending, each successive press of the checkbox (or any GUI element) replaces the pending task while one is executing. Instead of queuing up 30 tasks to run with 30 presses of the checkbox if a user rapidly presses the checkbox and there is a long running task kicked off just the first and last presses get tasks submitted. So basically the advice I'm offering is to copy / modify AsyncTask as necessary in ones own package or ditch usage of AsyncTask entirely and adopt a solid existing framework that won't change or simply investigate the Executor framework directly and build your own abstraction. It's the only foolproof way to get reliable task execution across all versions of Android and it is pointless / very bad style to embed conditional logic based on API level to limp along using AsyncTask. I know the Android team is just trying to provide a helper functionality, but to change the default behavior like this is yet another API sin; IMHO This revelation in the change of default behavior really demands an Android Dev blog post and the clearest possible documentation to be posted. -- 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
[android-developers] Re: AsyncTask in Android 4.0
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 SDK11, 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
