If you missed Part 1 check that out first. In this section we are talking about actually issuing commands and receiving feedback from the Model and ViewModel.
One of the more awkward things to do in MVVM is testing the ViewModel. Its meant to be designed for easy Unit Testing but having to account for timeouts, exception handling, navigation, showing a dialog, updating properties, you all of a sudden have to remember to mock a lot of services and make sure they are called correctly.
An easier approach would be each ICommand in the ViewModel to just return a result and the timeout’s, insights and error handling to all be done via a separate already tested wrapper. This is exactly what IViewModelExecute does. Allows you to separate the actual code unique in an ICommand, see it result and let the framework handle the result, rather than you having to handle the result for each command.
First we want to create an IOperation. This is what actually performs the function you want it to do. In this example I am using a piece from my Tesla Sample App where it will Honk the horn.
The only thing you need to focus on is performing the Honk command, then setting a result. In this case we don’t want to do anything so it is set to None but other options include navigation and error handling.
Next all we need is a wrapper to add the operations in. This is here in case you want to separate out your operations. The ViewModelExecute allows you to group operations together and set the timeout for all of them to complete.
Now we create the command in the ViewModel. This method allows you to keep your ViewModel simple and clean.
As you may see from the example above I created a VisualState object and passed it through. What is this craziness you ask? It a separate class that holds purely the Visual State of the ViewModel. Its not necessary but helps provide a nice separate and easy state management and testing.
Why a private set? This is because would want a function in the Visual State to update the state as appropriate. Don’t let outside forces control your visual state, let them pass through the information needed and update the state dependent upon your VisualState objects rules. This prevents getting into Visual States that are hard to track how they came about.
Handling the Result
When the operation returns the result, what handles it? The Base ViewModel in Exrin has a property called Execution and by default it is already setup to do some basic things such as show a message when a timeout occurs, switch the IsBusy property when its performing an action and handling your navigation. However if you want to override it, just assign a new ViewModel.Execution object with functions to handle your results as needed.
Tip: File Nesting
All of these files can become quite overwhelming after a short space of time and that is why I suggest using Visual Studio’s inbuilt File Nesting. There is a File Nesting plugin that makes it nice and easy.
Moving on to the Model, a similar approach was made for calling an action, however it is much simpler than the IViewModelExecute due to a reduced amount of situations to handle.
The IModel is then used to call this operation and provides the wrapping functions of handling timeout and exception handling.
Next in Part 3 we will look at using Exrin Insights, which is an all in one wrapper for complete error tracking, debug logging and application insights throughout the application, which will then relay to the appropriate insight provider such as HockeyApp, Raygun, or local log file.