Great video! Sorry I am just now seeing it. I just wanted to mention that I purposefully don't use ContinueWith for a number of reasons. First, it wraps the delegate in a Task object which means it allocates another task per operation. ContinueWith also defaults to TaskScheduler.Current not TaskScheduler.Default which makes it dangerous. This means you should always pass an explicit TaskScheduler to Task.ContinueWith to avoid any scheduler issues. However, in general I agree with everything you said. Especially the part about not putting async void in your ctors 😁
Hey Brian, thanks for checking this out and for those tips on Tasks too! I agree with your avoidance of ContinueWith and typically stay away from it in my own projects too. Anyways, I'm a big fan of all the stuff you do in the community! Glad to hear you won't be putting async voids in constructors anytime soon 😄
11:26 - Useful tip for WPF view-model creation with async support Note: I think there is also a good tutorial where you where showing SignalR feature that uses this approach In the tutorial user could send graphic as message ua-cam.com/video/7fLnF7VBjas/v-deo.html
I don't know if anyone does this, but if I need asynchronous initialization in a ViewModel, then I create the "Task InitTask { get; }" property and start initialization in it like InitTask = Task.Run(InitAsync). And then I can await for it if I need it like await ViewModel.InitTask.
Hi Sean! Your videos are amazing! I've learned so much from them. I have a suggestion/request. Can you make videos on the topic of creating docked/floating panels in WPF? A layout design like Visual Studio. I know there are some toolkits out there that can be used for this but I would love to learn how to create it from scratch. Thanks!
Thanks Mo! That seems like a pretty advanced UI manipulation, but I'm interested in investigating that in the future since it would be useful for an application. I've done a lot of work with drag and drop recently, so I assume this would extend on that. Thanks for the suggestion, I'll add that to the list!
Isn’t this bad practice? I mean there’s a reason that constructors can’t be async. If you really need a method like that, just add something like: public async Task InitializeAsync() That’s awaitable and easy testable, as well as more predictable.
I completely agree Christoph! I believe constructors should be as simple as possible and not execute any complex logic. I also go over an alternative solution at the end of this video, which is similar to the solution you suggested!
@@SingletonSean Oh yeah, I fell asleep before I got to that part :D I'm starting to really like functional programming languages and would really love to see discriminated unions come to C# in C# 11 or 12. That'd be one hell of an upgrade, and they already did a part of the work with records already.
6:20 - TaskCompletionSource
Great video! Sorry I am just now seeing it. I just wanted to mention that I purposefully don't use ContinueWith for a number of reasons. First, it wraps the delegate in a Task object which means it allocates another task per operation. ContinueWith also defaults to TaskScheduler.Current not TaskScheduler.Default which makes it dangerous. This means you should always pass an explicit TaskScheduler to Task.ContinueWith to avoid any scheduler issues. However, in general I agree with everything you said. Especially the part about not putting async void in your ctors 😁
Hey Brian, thanks for checking this out and for those tips on Tasks too! I agree with your avoidance of ContinueWith and typically stay away from it in my own projects too. Anyways, I'm a big fan of all the stuff you do in the community! Glad to hear you won't be putting async voids in constructors anytime soon 😄
This is the best explanation of this topic period.
Thank you so much.
8:56 - Factory method inside the class with async/await support
I think I will go with Bryan's approach.. Looks cleaner.
That's definitely understandable, it could go either way. Thanks for the feedback Jashobanta!
11:26 - Useful tip for WPF view-model creation with async support
Note: I think there is also a good tutorial where you where showing SignalR feature that uses this approach
In the tutorial user could send graphic as message
ua-cam.com/video/7fLnF7VBjas/v-deo.html
I could not handle some unit test cases in my real project. Now I clearly understoood, how to handle those test cases. Thanks again...
Awesome Mohammad, this is definitely a difficult test case!
Thanks for these videos, with the ones about wpf and viewmodels you are helping me a lot :)
11:27 WPF view issue with awaiting (DataTemplates)
Awesome video!
You are amazing 😎
I don't know if anyone does this, but if I need asynchronous initialization in a ViewModel, then I create the "Task InitTask { get; }" property and start initialization in it like InitTask = Task.Run(InitAsync).
And then I can await for it if I need it like await ViewModel.InitTask.
Hi Sean! Your videos are amazing! I've learned so much from them. I have a suggestion/request. Can you make videos on the topic of creating docked/floating panels in WPF? A layout design like Visual Studio. I know there are some toolkits out there that can be used for this but I would love to learn how to create it from scratch. Thanks!
Thanks Mo! That seems like a pretty advanced UI manipulation, but I'm interested in investigating that in the future since it would be useful for an application. I've done a lot of work with drag and drop recently, so I assume this would extend on that. Thanks for the suggestion, I'll add that to the list!
Isn’t this bad practice? I mean there’s a reason that constructors can’t be async. If you really need a method like that, just add something like:
public async Task InitializeAsync()
That’s awaitable and easy testable, as well as more predictable.
I completely agree Christoph! I believe constructors should be as simple as possible and not execute any complex logic. I also go over an alternative solution at the end of this video, which is similar to the solution you suggested!
@@SingletonSean Oh yeah, I fell asleep before I got to that part :D
I'm starting to really like functional programming languages and would really love to see discriminated unions come to C# in C# 11 or 12.
That'd be one hell of an upgrade, and they already did a part of the work with records already.