In a Xamarin.Forms application, is used to define the visual content with a XAML page and it works together with a C# file for the code behind.
The code-behind file provides code support for the markup. Together, these two files contribute to a new class definition that includes secondary views and initialization of the properties. In the XAML file, classes and properties are referenced with XML elements and attributes and bindings between code and markup are established.
The XAML file (.xaml) and the corresponding code-behind file (.xaml.cs) are two partial definitions of the same class.
The InitializeComponent() method that is called in the constructor of the underlying code class at runtime locates a URI in the compiled XAML file and passes it to a LoadComponent() method that parses the BAML, that is, the compiled XAML, and instantiate the elements that you have defined in your XAML markup.
So, in summary, the files ending in .xaml.cs are the ones that contain our “code behind” of the main .xaml file. Anything within this file is closely related to the .xaml file.
You will notice, for example, that the classes of the file are “partial” because there will be an automatically generated code when you compile your application that does specific things of the view, such as bindings, references, etc. The xaml.cs file should be used sparingly and only when you need to know or operate with specific details of the View itself.
MVVM (Model-View-ViewModel)
Now, using the MVVM pattern, you will encode almost all user interface interactions (UI) with their models in view models (.cs files), They are independent of the views.
The only binding between the view and the view model is that the view model is the data context of the view. In other words, the View knows about ViewModel, but that ViewModel knows nothing about the View.
With MVVM, you will often see code-behind classes that are almost completely empty, with only one constructor present. The logic in these cases is transferred to a “ViewModel” class that provides a binding between the View and the Model. You must bind objects in the View Model and use it as a data context for your view. It contains all the logic to define how the view affects your model.
The important thing to keep in mind is that MVVM mainly deals with two things: the separation of concerns (UI vs. UI Logic) and the ability to test your application.
Event Handlers
An event must live in the code behind because it cannot be explicitly linked to one in its ViewModel. You can easily call the function you want by accessing the ViewModel directly within that event handler, and there is nothing particularly atrocious in this approach.
Event handlers are generally not used in an MVVM world. You need to use another concept called Command that will live in the ViewModel itself; A command, unlike an event handler, is a Property, so you can bind it in your .xaml file using
These have good characteristics such as being able to define when the command is valid (so you can automatically disable a button when, for example, the form is missing a mandatory field).
On the other hand, you can also use Triggers or Behaviors.
When to use code behind
In general, it is advisable to use c# when you need to create dynamic controls, but having the general design (static storyboards, styles, data templates, etc.) in the XAM file.
The best thing about XAML is that it allows you to separate the design from its logic, which makes the code much easier for all of us to read. This greatly facilitates and speeds up long-term support.
YOu can also use C# for Markup to make declarative UIs. I think it is a project that has a lot to offer, and that we must support it. Personally, I believe that by having the options available we can use what suits us best in certain situations.
A good example of this is the animations within your views. The animations themselves are a bit complex on any platform, and trying to add more complexity can be a headache.
What I always try to do, if they are specific controls, is to create these controls in separate files and then reuse them in other Views. If the animations are for the page you can create a base page with the desired animation or if it is a page with very specific features then I use the code behind on that page.
In summary, we must use code behind when interaction between the controls of a view is needed. Remembering that our views (and our code behind too) know our ViewModel but our ViewModel should not know our view in order to separate concepts.
