We implemented a TaskManager class for this purpose: execute a number of tasks asynchronously (off the UI thread) one after the other. Basically, this class includes a queue of tasks and the functions to run/execute them.

Considering that the class is a hybrid between a collection and a manager, the question is: Should we have a separate queue inside it or not? What is the best architecture in this scenario?

public class TaskManager
    public List<Task> Queue; 

    public Exexcute(Task t) {...}
    public ExexcuteAll() {...}


public class TaskManager
    private List<Task> _queue; 

    public AppendToQueue() {...}
    public RemoveFromQueue() {...}

    public Execute(Task t) {...}
    public ExecuteAll() {...}

EDIT: We are not interested in suggestions on how to code this but on class architecture/design only. Thanks.

  • The "best" is probably using a normal ExecutorService instead. OK, it does not have a "remove", but you could flag this inside your callables instead. – mtj Nov 20 at 8:30
  • @mtj I think the question is related to design-pattern and not about an alternative object to use :) – ilCosmico Nov 20 at 8:42
  • 1
    @ilCosmico The question seems about a very specific case, which looks like reinventing the wheel. As esp. SE has a strong focus on real world problems in real world projects, I only point out the old rule, that normally the best software is the one that you don't have to write. (There's exceptions to the rule, but you have to look very carefully.) – mtj Nov 20 at 9:25
  • @mtj Agree with you. Maybe this is a simplified example of the goal, but now I better understand your answer. – ilCosmico Nov 20 at 9:48
  • "asynchronously one after the other" is a contradiction. If you're doing them one after the other, they're not being done asynchronously. – Flater Nov 20 at 11:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.