On 1 August 2011 21:05, Greg Brown <[email protected]> wrote: > Here's a thought - maybe TaskGroup itself should also be deprecated. I'm > wondering if it might encourage bad development practice. While it allows you > to execute multiple tasks in the background, it doesn't "return" until all of > those tasks are complete. One might argue that a well-designed UI should > present information as soon as it becomes available.
This functionality is useful for showing a splash screen with a progress bar while an application initializes. Individual tasks send back notifications of their completion to update the progress bar, and once the parent task (TaskGroup) returns, the splash screen can be replaced with the main application UI. > For example, let's say you are writing an app that browses a product catalog. > You create one task to pull a product image from an image server, another > that retrieves a product description from a database, and a third that pulls > pricing and inventory information from another back-end system. TaskGroup > allows you to wait until all of that data has been retrieved before > presenting any of it, but is that really the best user experience? Maybe not While TaskGroup allows this, the choice still lies with the developer as to whether or not they use it, and how they use it. It might be appropriate to collate the data from all grouped tasks before it can be used/displayed. The individual tasks still have their own TaskListeners, so the results of each Task could be used as soon as it returns, as per my comment above. > There may be valid use cases for something like this, but I'm just wondering > if it is common enough that a class to facilitate it should be included in > the platform. The lack of a dedicated TaskGroup class does not preclude a > developer from implementing similar behavior at the application level. Despite of the rest of my reply, I don't see this as a particularly valuable class, so wouldn't object to it being deprecated and eventually removed, especially if TaskSequence goes too. I'd prefer to make a couple of little changes to Task itself, and leave the rest to the developer. (Multiple TaskListeners per Task, and ability to execute a Task using an ExecutorService supplied after construction - specifically at execution time) Chris
