It's all well and good binding data, but if you can't do the same for other user input like button clicks and gestures, you've still got one foot in the tightly bound code-behind camp. Let's start by looking at the traditional or non-bound command scenario. In our student page XAML, we'd give the button a name and associate an action in the code-behind for the clicked event. The most striking aspect of this example is how lonely the SaveBtn_Clicked event is in StudentPage.xaml.cs. I'll just delete the click event handler and go to the view model code. We've got two commands, SaveCommand and CancelCommand, bound to XAML buttons with the same syntax as data binding. The command class is in the Xamarin.Forms library, so built into Xamarin and implements the ICommand interface found in System.Windows.Input. The Command class has four constructors, three methods, CanExecute, Execute, ChangeCanExecute, and one event, CanExecuteChange. In StudentViewModel, the two public commands have been assigned new command class instances. The save command with a two-parameter constructor specifying OnSave to execute and ValidateSave to check whether saving can be executed. The cancel command constructor specifies a private method to execute when clicked. The line below is interesting. This assigns the save command's can execute method, so ValidateSave, to the BaseViewModel's property changed handler. Whenever bound view model values change, the ValidateSave method will be called to see if OnSave can execute. If it can, the control associated with the command will be enabled. The brackets with the underscores represent the save command's signature with two parameters. Even though the underscores represent anonymous parameters, i.e., we don't care what they are, the compiler won't allow the same parameter twice, hence one single underscore and one double underscore. Like data binding, command binding uses reflection to associate the button with the action to execute.

I've removed the data binding from the student class and reinstated it in the view model, adjusting the view's bindings appropriately. Let's run the app without a student in the store and a breakpoint in ValidateSave. When the page is first loaded, and the binding context is set up, ValidateSave is executed. Whenever the underlying view model data is changed courtesy of data binding, ValidateSave is executed through its association with ChangeCanExecute. When all conditions are met, ValidateSave returns true, enabling the save command and button. Clicking save executes OnSave.