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) =
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
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
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.
--
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?
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
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 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
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
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
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
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,
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?
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
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
15 matches
Mail list logo
