This update includes changes based on feedback from our community who’ve been using the initial preview of the library. It does contain some breaking changes, so be sure to read our notes about that here<\/a> if you are updating.<\/p>\n \ud83d\udcdd The highlights for the update to the library include:<\/p>\n The rest of this post will cover our journey on how we set out to improve the usability of one of these API calls. Early on, we discovered an issue with compiling those changes on .NET Native for UWP; however, we ended up not only working around them, but also designing an even better API surface in the process! \ud83d\ude80<\/p>\n In our initial preview<\/em> of the MVVM Toolkit<\/a>, we provided a new API that allows a developer to more easily get notified in their UI when a Task is completed in their ViewModel. This makes it easier to directly obtain status on a task and remove While looking complex, it was still fairly straight-forward to use in practice as seen here:<\/p>\n However, you’ll note that we’re effectively passing the same task twice into the function in different ways. \ud83d\ude15 The first reference to the task, allowed the function to not need reflection in order to validate the initial task setup. The second lambda expression allows the method to check that the task is still the same upon completion (via reflection) before notifying the application that it was finished (as we couldn’t re-use the ref in the asynchronous method).<\/p>\n This pattern though, was still more complex than using a standard property change setup in the normal use case which just took a reference to the backing field:<\/p>\n As we set out to improve the API after our initial preview of it. We wanted to try to simplify the need for passing the task twice to the This would simplify the syntax for utilizing the method by combining the The added benefit to this approach was that it also removed the need for reflection entirely. \ud83d\ude80 You can see how this improved the performance of this one API here:<\/p>\n This led to a 7-14 times improvement in execution time and over 60% improvement to memory usage! \ud83c\udf89<\/p>\n Even though our library is based on .NET Standard, one of the primary target groups for the Windows Community Toolkit are UWP developers! This of course means we want to ensure the library works well for them on .NET Native. When Sergio went to push his new changes to his open PR, he found our Continuous Integration build to have failed! What could have happened with this seemingly simple update using a feature of C#?<\/p>\n Unfortunately for us, we discovered the .NET Native compiler doesn’t support ref returning delegates. \ud83d\ude25<\/p>\n We reached out to the .NET Native team, originally starting our discussion on GitHub here<\/a> about what might be going on. They confirmed this was indeed a known issue with .NET Native.<\/p>\n In order to workaround this issue, we were going to have to try and change our method signature in another way to achieve our goal of simplifying its usage. Thankfully, the .NET Native team was able to help us investigate and suggest a potential solution to our problem. \ud83c\udf89<\/p>\n Their initial proposal was effectively the following API surface and usage:<\/p>\n While this would resolve the issue when compiling to .NET Native, it introduced some extra overhead on the developer compared to our standard property change notification pattern.<\/p>\n However, our first step was to at least implement the suggested pattern in the library to ensure it worked and compare the performance with the existing updated improvements we had already achieved.<\/p>\n During this implementation, we realized the backing In the end, we were concerned about having the extra wrapping type (including needing to specify Task as a generic type argument again), having to initialize the wrapper, and having to unwrap it again to retrieve it.<\/p>\n Side note though<\/em>, this workaround did improve the memory usage even further! \ud83d\ude2e<\/p>\n What followed was over a day long quest between Sergio and I to see if we could simplify the usage pattern of the API for developers, while still maintaining the goal of working with .NET Native. We really wanted to ensure this was an easy to use API without a lot of overhead for developers to understand and discover a complex nuanced syntax. \ud83e\udd14<\/p>\n The first issue we tackled was around needing to initialize the wrapper type and marking the backing field as Secondly, we improved the We were getting closer to our goal of simplifying this API. \ud83d\udc68\u200d\ud83d\udd2c The last thing that remained on our minds was the API still required including the generic type While we (or rather Sergio) worked to thinking of a solution, an interesting anecdote occurred to me at this point. Thinking of the name Lucky for us, we realized by just changing the name to Finally, to implement a solution for the embedded \ud83d\udcdd Note: There’s a bit more behind the scenes to this story in terms of implementation details and how it all functions. Of course, this is all open source code up on GitHub, so you can see how it works for yourself here<\/a>.<\/em><\/p>\n We finally reached a state where we were truly happy with how developers could use this API. Now, it was not only simpler to use, but just as performant (indeed more so, see below), and closely mirrored the base property change API. This is the final result to the end developer in this new preview:<\/p>\n And when compared to the standard property backing, it becomes more apparent how nice this solution was:<\/p>\n You’ll see the only change a developer needs to enable Tasks is to use At the end of this adventure, we ended up with a better API than where we started, that was more performant, and easier to use. See the final comparison of performance metrics below.<\/p>\n \ud83e\udd99\ud83d\udc97 We’re thankful to the .NET Native team for working with us and proposing an initial solution to workaround our issue. It’s really amazing how this journey to improve an API led us down some unexpected paths, but in the end resulted in improvements for the MVVM Toolkit. \ud83d\ude80<\/p>\n Be sure to checkout our preview MVVM Toolkit sample and doc repo here<\/a>. You can file issues against the samples and docs there, or provide input on the MVVM Toolkit code itself on our main repo’s tracking issue here<\/a>. \ud83d\udce2<\/p>\n Thank you for sharing your feedback with us!<\/p>\n\n
Microsoft.Extensions.DependencyInjection<\/code> so developers are free to choose that or any library for their Inversion of Control needs.<\/li>\nThe Beginning<\/h2>\n
IsLoading<\/code> type properties to control UI flow while awaiting these Tasks. This API is called SetPropertyAndNotifyOnCompletion<\/code><\/a> and had the following signature:<\/p>\nprotected bool SetPropertyAndNotifyOnCompletion<TTask>(\r\n ref TTask? field,\r\n Expression<Func<TTask?>> fieldExpression,\r\n TTask? newValue,\r\n [CallerMemberName] string? propertyName = null)\r\n where TTask : Task;\r\n<\/code><\/pre>\nprivate Task<string> myTask;\r\npublic Task<string> MyTask\r\n{\r\n get => myTask;\r\n set => SetPropertyAndNotifyOnCompletion(ref myTask, () => myTask, value);\r\n}\r\n<\/code><\/pre>\nprivate string query;\r\npublic string Query\r\n{\r\n get => query;\r\n set => SetProperty(ref query, value);\r\n}\r\n<\/code><\/pre>\nThe Initial Refactor<\/h2>\n
SetPropertyAndNotifyOnCompletion<\/code> method. Sergio Pedri, an active community member and developer of the MVVM Toolkit library, originally came up with an optimization using a custom ref returning delegate (a relatively newer feature introduced in C# 7):<\/p>\nprotected delegate ref T FieldAccessor<T>();\r\n\r\nprotected bool SetPropertyAndNotifyOnCompletion<TTask>(\r\n FieldAccessor<TTask?> fieldAccessor,\r\n TTask? newValue,\r\n [CallerMemberName] string? propertyName = null)\r\n where TTask : Task;\r\n<\/code><\/pre>\nref<\/code> and lambda (effectively) together:<\/p>\nprivate Task<string> myTask;\r\npublic Task<string> MyTask\r\n{\r\n get => myTask;\r\n set => SetPropertyAndNotifyOnCompletion(() => ref myTask, value);\r\n}\r\n<\/code><\/pre>\n![\"Initial](\"https:\/\/devblogs.microsoft.com\/pax-windows\/wp-content\/uploads\/sites\/61\/2020\/10\/MVVMToolkit-PerformanceInitialImprovement.png\")
<\/p>\nEnter .NET Native<\/h2>\n
\/\/ API Surface\r\nprotected class TaskAccessor<T> where T : Task\r\n{\r\n public T Task { get; set; }\r\n}\r\n\r\nprotected bool SetPropertyAndNotifyOnCompletion<TTask>(\r\n TaskAccessor<TTask> accessor,\r\n TTask newValue,\r\n [CallerMemberName] string? propertyName = null)\r\n where TTask : Task\r\n{\r\n return default;\r\n}\r\n\r\n\/\/ Developer Usage\r\nprivate TaskAccessor<Task<string>> myTask = new TaskAccessor<Task<string>>();\r\npublic Task<string> MyTask\r\n{\r\n get => myTask.Task;\r\n set => SetPropertyAndNotifyOnCompletion(myTask, value);\r\n}\r\n<\/code><\/pre>\nTaskAccessor<\/code> field would probably be best marked readonly<\/code> as it shouldn’t be changed after initialization. This would be another step for developers using the API to have to know to setup.<\/p>\n![\"Accessor](\"https:\/\/devblogs.microsoft.com\/pax-windows\/wp-content\/uploads\/sites\/61\/2020\/10\/MVVMToolkit-PerformanceAccessor.png\")
<\/p>\nThe Journey<\/h2>\n
readonly<\/code>. By changing the API to accept the parameter by ref<\/code> and leveraging TaskAccessor<T><\/code>‘s parameterless constructor, the API itself could automatically initialize the field with a new instance, if needed:<\/p>\nprivate TaskAccessor<Task<string>> myTask;\r\npublic Task<string> MyTask\r\n{\r\n get => myTask.Task;\r\n set => SetPropertyAndNotifyOnCompletion(ref myTask, value);\r\n}\r\n<\/code><\/pre>\nget<\/code> accessor by adding an implicit cast operator to the TaskAccessor<T><\/code> field, which would automatically unwrap the inner T<\/code> instance. This allows developers to have their property getters return the backing field directly (like a standard property setup), with the C# compiler taking care of invoking the implicit operator to retrieve the task instance stored there, if present:<\/p>\nprivate TaskAccessor<Task<string>> myTask;\r\npublic Task<string> MyTask\r\n{\r\n get => myTask;\r\n set => SetPropertyAndNotifyOnCompletion(ref myTask, value);\r\n}\r\n<\/code><\/pre>\nTask<\/code> within the TaskAccessor<\/code> itself. Not only was it more verbose, but it was especially odd if the Task was non-generic as you’d have to specify TaskAccessor<Task><\/code>. It’d be great if we could just use something like TaskAccessor<\/code> directly and not re-iterate the Task<\/code> within it.<\/p>\nTaskAccessor<\/code> seemed to be very monolithic and indicative of the core problem we were trying to work around. This didn’t lead to feeling great about the solution, even though we had come so far at this point to get here. \ud83e\udd14<\/p>\nTaskNotifier<\/code> instead, it seemed to make things tie together more closely to the API it was related too, and just generally make us feel better about having to use it. Now, rather than seeming like a workaround to access a field, it feels like a piece of code that is actively working towards helping the developer with this scenario (even though it doesn’t actually do any of the real notifying. \ud83e\udd2b Shhhh, it’s a secret).<\/p>\nTask<\/code> type, Sergio decoupled the handling of both the generic and non-generic tasks by introducing two separate wrapping types: TaskNotifier<\/code> and TaskNotifier<T><\/code>. The generic TaskNotifier<T><\/code> type automatically maps to Task<T><\/code> for the internal task instance, while TaskNotifier<\/code> just contains a simple Task<\/code>. We then exposed two different overloads of the SetPropertyAndNotifyOnCompletion<\/code> method, one accepting a TaskNotifier<\/code> and one accepting a TaskNotifier<T><\/code> parameter. This whole procedure is completely transparent for consumers of the library, but it allows us to completely remove the need to have those two type arguments being specified, making the code much less verbose.<\/p>\nThe Final Result<\/h2>\n
private TaskNotifier<string> myTask;\r\npublic Task<string> MyTask\r\n{\r\n get => myTask;\r\n set => SetPropertyAndNotifyOnCompletion(ref myTask, value);\r\n}\r\n<\/code><\/pre>\nprivate string query;\r\npublic string Query\r\n{\r\n get => query;\r\n set => SetProperty(ref query, value);\r\n}\r\n<\/code><\/pre>\nSetPropertyAndNotifyOnCompletion<\/code> instead of SetProperty<\/code> and change their Task<\/code> backing type to TaskNotifier<\/code> while still being able to leverage Task<\/code> in their property itself. \ud83c\udf89<\/p>\n![\"Accessor](\"https:\/\/devblogs.microsoft.com\/pax-windows\/wp-content\/uploads\/sites\/61\/2020\/10\/MVVMToolkit-PerformanceAll.png\")
<\/p>\nProviding Feedback<\/h2>\n