On Wed, May 16, 2012 at 9:09 AM, Dirk Jäckel wrote:
> Please document this here:
> https://developer.android.com/reference/android/os/Build.VERSION_CODES.html#HONEYCOMB_MR2
> Or is there a better place for developers to stay informed what a
> targetSDKVersion change means for their app?
>
As I a
On Friday, April 20, 2012 11:39:51 PM UTC+2, Dianne Hackborn wrote:
>
> Sorry yes it is API 13, I turned around the logic of the code when I
> glanced at it:
>
> // If the app is Honeycomb MR1 or earlier, switch its AsyncTask
> // implementation to use the pool executor. Normally,
On Saturday, April 21, 2012 12:52:17 AM UTC+2, b0b wrote:
>
>
> > Conclusion: there's probably man apps broken in subtle ways on ICS
>> because
>> > of this change.
>>
>> Probably not, only because they have to explicitly set the
>> targetSdkVersion to 13+, and I don't know how many people are set
On Tue, Apr 24, 2012 at 1:18 AM, RichardC wrote:
> Will this change break CursorLoader in multi-fragment Activities?
>
No.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so
On Tue, Apr 24, 2012 at 4:18 AM, RichardC
wrote:
> Will this change break CursorLoader in multi-fragment Activities?
CursorLoader uses the THREAD_POOL_EXECUTOR, last I checked.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | htt
Will this change break CursorLoader in multi-fragment Activities?
If I have an Activity with 2 Fragements, each fragment using a CursorLoader
to load its own data. CursorLoader is derived from AsyncTaskLoader which
uses AsyncTask to do the work which includes monitoring for data changes
therefo
My app targets sdk 15 (tested on CM9) and uses AsyncTask in every activity
but only one at a time. Explains why I did not notice the change. I agree
that this change deserves better documentation in the API reference in
addition to a blog post.
--
You received this message because you are subs
2012/4/20 Kostya Vasilyev
> So, changing the targetSdk may break code in various ways and requires
> careful (re)testing.
>
Yes, the whole reason for targetSdkVersion is to allow the platform to turn
off various compatibility behavior for older applications. If you bump up
your SDK version, you
21.04.2012 3:09 пользователь "Romain Guy" написал:
>
> > 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 get
> 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 framewor
>
> To illustrate this further, consider this code from Tim Bray downlading
> images in a ListView. Something that must be implemented in thousand apps:
>
http://android-developers.blogspot.fr/2010/07/multithreading-for-performance.html
This code running unmodified on ICS will download images s
21.04.2012 2:52 пользователь "b0b" написал:
>
>
>> > Conclusion: there's probably man apps broken in subtle ways on ICS
because
>> > of this change.
>>
>> Probably not, only because they have to explicitly set the
>> targetSdkVersion to 13+, and I don't know how many people are setting
>> it that
> > Conclusion: there's probably man apps broken in subtle ways on ICS
> because
> > of this change.
>
> Probably not, only because they have to explicitly set the
> targetSdkVersion to 13+, and I don't know how many people are setting
> it that high.
>
Bumping targetSdkVersion to the latest ve
21 апреля 2012 г. 2:39 пользователь Mark Murphy
написал:
> On Fri, Apr 20, 2012 at 6:26 PM, b0b wrote:
> > Conclusion: there's probably man apps broken in subtle ways on ICS
> because
> > of this change.
>
> Probably not, only because they have to explicitly set the
> targetSdkVersion to 13+, and
On Friday, April 20, 2012 3:26:26 PM UTC-7, b0b wrote:
>
>
>
> On Friday, 20 April 2012 23:24:34 UTC+2, Dianne Hackborn wrote:
>>
>> Yes if your targetSdkVersion is >= 12, then as of that release the
>> default executor is serial.
>>
>> This change was made because we realized we had a lot of bu
To complete on this topic, I think it would be very useful to post an
article on this issue on the developer's blog,
asking developers whose app run on APi 13+ to review all their AsyncTask
execute() code to check
if it can use the default Executor or if it must use the Threaded Executor,
for e
On Fri, Apr 20, 2012 at 3:26 PM, b0b wrote:
> While I understand why this change why made it introduced some subtle bugs
> in apps running on ICS with the SerialExecutor vs the the Threaded Executor.
> It is unfortunate and I'm not sure it was a wise decision to change such
> an important behavio
2012/4/20 Kostya Vasilyev
> Perhaps the documentation needs to be updated?
Yes sorry it wasn't updated in ICS, I have it updated in the current dev
tree.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
On Fri, Apr 20, 2012 at 6:26 PM, b0b wrote:
> Conclusion: there's probably man apps broken in subtle ways on ICS because
> of this change.
Probably not, only because they have to explicitly set the
targetSdkVersion to 13+, and I don't know how many people are setting
it that high.
That being sai
On Friday, 20 April 2012 23:24:34 UTC+2, Dianne Hackborn wrote:
>
> Yes if your targetSdkVersion is >= 12, then as of that release the default
> executor is serial.
>
> This change was made because we realized we had a lot of bugs in the
> platform itself where async tasks where created that ha
Perhaps the documentation needs to be updated?
As of right now, it says:
"Note: this function schedules the task on a queue for a single background
thread or pool of threads *depending on the platform version*. "
... and makes no mention of the target sdk setting in the manifest.
Still, an app
Sorry yes it is API 13, I turned around the logic of the code when I
glanced at it:
// If the app is Honeycomb MR1 or earlier, switch its AsyncTask
// implementation to use the pool executor. Normally, we use the
// serialized executor as the default. This has to happen in
On Fri, Apr 20, 2012 at 5:24 PM, Dianne Hackborn wrote:
> Yes if your targetSdkVersion is >= 12, then as of that release the default
> executor is serial.
Bingo! It's the targetSdkVersion that's controlling the behavior.
Looking at the AsyncTask source code, I can't quite see how that's
happening
Yes if your targetSdkVersion is >= 12, then as of that release the default
executor is serial.
This change was made because we realized we had a lot of bugs in the
platform itself where async tasks where created that had implicit ordering
dependences, so with the default parallel execution there w
"*Curiouser and curiouser*!" *Cried Alice*
Running your code on my GNex with official 4.0.2 I get this:
04-21 00:41:08.327 I/ParallelTasks(14355): A started
04-21 00:41:18.335 I/ParallelTasks(14355): A ended
04-21 00:41:18.335 I/ParallelTasks(14355): B started
04-21 00:41:28.335 I/ParallelTasks(1
21 апреля 2012 г. 0:36 пользователь Nathan написал:
>
> It's not quite so easy for a project that wants to run on pre 3.0
> platforms. If you have an elegant solution for that, it will save me some
> time.
>
Idea 1: Write a wrapper method in a utility class somewhere... replace
direct calls to ex
On Friday, April 20, 2012 12:31:01 PM UTC-7, Kostya Vasilyev wrote:
>
> The default, starting with 4.0, is to use the serial executor:
>
>
> https://github.com/android/platform_frameworks_base/blob/master/core/java/android/os/AsyncTask.java#L192
>
> But there is also an way to explicitly use the
On Fri, Apr 20, 2012 at 4:26 PM, Nathan wrote:
> I don't download the source myself, but if this source listing is accurate,
> it must be fully in place.
>
> https://github.com/android/platform_frameworks_base/blob/master/core/java/android/os/AsyncTask.java
I've seen that, which is why I can't ex
On Friday, April 20, 2012 12:29:24 PM UTC-7, Mark Murphy (a Commons Guy)
wrote:
>
> On Fri, Apr 20, 2012 at 3:16 PM, Nathan 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
2012/4/20 Kostya Vasilyev :
> The default is definitely serial on my GNex with 4.0.2.
>
> Did they revert it again for the 4.0.3 that you have?
Here's how I am testing it (sloppy code, but it meets the need):
import android.app.Activity;
import android.os.AsyncTask;
import android.os.Bundle;
impo
20 апреля 2012 г. 23:29 пользователь Mark Murphy
написал:
> On Fri, Apr 20, 2012 at 3:16 PM, Nathan 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. W
The default, starting with 4.0, is to use the serial executor:
https://github.com/android/platform_frameworks_base/blob/master/core/java/android/os/AsyncTask.java#L192
But there is also an way to explicitly use the thread pool executor:
https://github.com/android/platform_frameworks_base/blob/ma
On Fri, Apr 20, 2012 at 3:16 PM, Nathan 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
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).
Doe
34 matches
Mail list logo
