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