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
