-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async command examples #4
Comments
The The I do plan on writing up docs on using them together, since this will be a common use case. I'm also considering some static methods or possibly simple wrapper types for common construction scenarios. In the meantime, for a
|
With the
|
So to be clear, while in the previous version we could reuse the CancelCommand, in the |
@roubachof The new
then you can re-use The problem is, that's difficult to verify in some scenarios (namely, synchronous ones). So I'd say as a general rule, if you're overwriting the It would be possible to make a more-reusable |
Well what I find peculiar is that with implementation I guess we need to create a new AsyncCommand each time we want to use it in our view. public class VM
{
public VM()
{
CountUrlBytesCommand = new AsyncCommand(() => CountUrlBytesCommandAsync);
}
public AsyncCommand CountUrlBytesCommand { get; }
public async Task CountUrlBytesCommandAsync()
{
}
} If we have a look to the "old" way (https://msdn.microsoft.com/en-us//magazine/dn630647.aspx), the CancelCommand is directly linked to the current Command. var vm = new VM();
var commandToBeCalled = vm.CountUrlBytesCommand;
var cancelCommand = vm.CountUrlBytesCommand.CancelCommand;
cancelCommand.Execute(null); // Cancels previous before running the new
commandToBeCalled.Execute(...); So we create the Command once (CancelCommand was embedded in the AsyncCommand). But with the new approach, I guess we would need to have this: public class VM
{
public VM()
{
CancelCommand = new CancelCommand();
}
public CancelCommand CancelCountCommand { get; private set; }
public AsyncCommand CountUrlBytesCommand
{
get
{
CancelCountCommand = new CancelCommand();
return new AsyncCommand(CancelCountCommand.WrapDelegate(async (_, token) =>
{
await TestService.DownloadAndCountBytesAsync(Url, token);
}));
}
}
public async Task CountUrlBytesCommandAsync()
{
}
} And in the code behind if we keep the old workflow: var vm = new VM();
var commandToBeCalled = vm.CountUrlBytesCommand; // We just created a new instance of AsyncCommand
var cancelCommand = vm.CancelCommand; // Oops old cancel command is gone
cancelCommand.Execute(null); // Cancels the new command
commandToBeCalled.Execute(...); // Born cancelled So we would have to do: var vm = new VM();
var cancelCommand = vm.CancelCommand; // the cancel command linked to the previous command
var commandToBeCalled = vm.CountUrlBytesCommand; // We just created a new instance of AsyncCommand
cancelCommand.Execute(null); // Cancels the new command
commandToBeCalled.Execute(...); // Born cancelled This would be ok but the we are workflow dependent and the accessor creates a new Command. |
So to answer your question: it seems that having a reusable cancel command will fix the workflow + new async command instance issues. |
Any chance some examples of AsyncCommand could be added in conjunction with the IProgress API? |
Hi Stephen,
This really is not an issue it's just a discussion about usage of AsyncCommand in general.
I really loved your MSDN magazine articles about this subject. They are awesome. You really explained your thought process while creating NotifyTask and AsyncCommand classes. Problem with this version on GitHub is considerable difference than your last explained version. I would really love to see your thought process while designing this class.
Another issue is cancellation. I am not sure what would be the proper way of "connecting" Async and Cancel commands. I did tried to use something like this in ViewModel constructor (same example like you used in your MSDN article):
CancelCountCommand = new CancelCommand();
CountUrlBytesCommand = new AsyncCommand.v2.AsyncCommand(async (param) => ByteCount = await TestService.DownloadAndCountBytesAsync(Url, CancelCountCommand.CancellationToken));
But the problem with this solution is that Cancel button is enabled by default. Canceling works only first time and if user tries to start AsyncCommand again, it fails saying that Task is canceled. How should I use it properly?
Thank you,
Milos
The text was updated successfully, but these errors were encountered: