# Task Commands revisited

DevFeed: [Task Commands revisited](<https://devfeed.tech/articles/task-commands-revisited-38411.md>)

Original publisher: [Read original article](<https://khmylov.com/2012/02/task-commands-revisited/>)

Author: Andrew Khmylov

Published: 2012-02-23T00:00:00Z

Content type: tutorial

Language: en

Sources: [Despite the odds](<https://devfeed.tech/sources/despite-the-odds.md>)

Topics: [MVVM](<https://devfeed.tech/topics/mvvm.md>), [async](<https://devfeed.tech/topics/async.md>), [Code](<https://devfeed.tech/topics/code.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [test](<https://devfeed.tech/topics/test.md>), [WPF](<https://devfeed.tech/topics/wpf.md>)

Tags: [async](<https://devfeed.tech/tags/async.md>), [bitbucket](<https://devfeed.tech/tags/bitbucket.md>), [code](<https://devfeed.tech/tags/code.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [mvvm](<https://devfeed.tech/tags/mvvm.md>), [test](<https://devfeed.tech/tags/test.md>), [zip](<https://devfeed.tech/tags/zip.md>)

## AI overview

The article revisits an earlier TPL and MVVM command implementation, replacing its event-based asynchronous completion notification with an ExecuteAsync method that returns a Task. It presents an updated generic AsyncRelayCommand and explains its inner command, asynchronous execution, explicit ICommand.Execute implementation, and CanExecute handling.

## Source excerpt

Half a year ago I blogged about using TPL with MVVM in a test-friendly way. My solution turned out to be pretty handy, though it was far from being perfect. In this post I will describe what was wrong with the initial implementation and can we slightly improve it. Looking at that solution right now, I wonder why did I decide to use event async pattern (providing the ExecuteCompleted event) in the first place. The intention was to notify the caller about completion of the asynchronous operation. That is what System.Threading.Task is used for this days, isn't it? So the obvious solution is to expose the ExecuteAsync() method returning the Task instance on the command class. Here is the source of the updated AsyncRelayCommand: public class AsyncRelayCommand<T> : ICommand { private readonly RelayCommand<T> _internalCommand; private readonly Func<T, Task> _executeMethod; public event EventHandler CanExecuteChanged { add { _internalCommand.CanExecuteChanged += value; } remove { _internalCommand.CanExecuteChanged -= value; } } public AsyncRelayCommand(Func<T, Task> executeMethod, Predicate<T> canExecuteMethod) { if (executeMethod == null) { throw new ArgumentNullException("executeMethod"); } _executeMethod = executeMethod; _internalCommand = new RelayCommand<T>(_ => { }, canExecuteMethod); } public AsyncRelayCommand(Func<T, Task> executeMethod) : this(executeMethod, _ => true) { } void ICommand.Execute(object parameter) { if (parameter is T) { ExecuteAsync((T)parameter); } else throw new ArgumentException("Parameter should be of type " + typeof(T)); } public Task ExecuteAsync(T parameter) { return _executeMethod(parameter); } public bool CanExecute(object parameter) { return _internalCommand.CanExecute((T)parameter); } public void RaiseCanExecuteChanged() { _internalCommand.RaiseCanExecuteChanged(); } } The code is pretty straightforward, here are the key points: Create an inner command that responds to CanExecute, RaiseCanExecute calls and handles subscriptions to CanExec