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
