Join Helen Miller for an in-depth discussion in this video Why use XAML?, part of XAML in Xamarin.Forms.
- [Instructor] Suppose you had an app like this to translate and dial a phone number. The UI is really simple. You have at the top a label to prompt the user. Below that, you have a text entry field where the user would type in the phone number. And then you have two buttons. When the user clicks on the button, you translate the phone number and update the text on the call button. When they click the call button, you pop up a confirmation dialog and if they click yes, then you go ahead and dial the number. You could implement the entire Phoneword application in code.
So here we are in the C# file. We might start off with some fields to store the controls that we're going to need to access from code. And then in our constructor, we would create the controls and set some properties. So for example, create the label, set a couple of properties on it. And create the text entry field. Prepopulate it with a sample phone number. Create the translate button. Create the call button. You notice that one's going to start off as disabled and it's not going to become enabled until we have a phone number to call.
And then we create a container to arrange the controls. In this case, we're going to use StackLayout. Add all the controls to the StackLayout. Set the content of this page to be the StackLayout panel. And then just add a little padding around the edges. So all that code right there is the user interface part. Then we would also have the behavior here in code. So for example, we could subscribe to the click event on the two buttons. There's the stub out of the method. In Translate, we're going to translate the phone number and then update the text on the call button.
And in the OnCall method, we're going to do a little bit of confirmation with the user. And then if they say yes, we're going to go ahead and dial the number. Here's the code for the app we were just building all in one place. If we look at the code here, we'll see that there's two categories of stuff. There's the code to build the user interface and then there's the code to implement the behavior. And of course, it's all together in a single file. This kind of approach where you build the UI dynamically does have one nice advantage.
The UI itself can be different depending on the data that you're trying to present. So notice it's not that the data changes between runs, in this case, it's that the UI itself can adapt to different datasets. Because you're producing in code, you can present different controls based on the data that you receive from a server or something. So, that situation is one really nice benefit of building the UI in code. However, that doesn't come up very often.
And on the other hand, building the UI in code is actually quite limiting. It means that you have to have a developer that's building the user interface. There's no possibility, in this case, to delegate that work to a dedicated UI designer. So that's a bit of the motivation for a different approach. We're going to use something called the Extensible Application Markup Language or XAML to define our user interface, with the markup language that's intended and dedicated towards building user interfaces.
Instead of the traditional approach where you write code, you use markup instead. So here's that same example again, slimmed down just to the core elements. If we code this in XAML, we'd end up with something like this. Instead of allocating objects using new, we have element tags in our markup. Instead of adding the controls explicitly to the StackPanel, we just nest them inside the panel in the XAML. And similarly, instead of assigning to the Content property of the page, we just nest the StackLayout inside the content property of the page.
Many people think that the XAML approach is more readable. For example, in the XAML, you nest the controls inside the layout panel. And just at a glance, it's obvious that those are the children of the StackLayout. And it's much more obvious than it is in code. So if we fill this out a bit, we end up with XAML that looks something like that for the user interface. So this is the XAML that's equivalent to the code that we wrote earlier.
This is the entire declaration of the user interface in a single dedicated source file, so it's completely separated from the behavior. If we look at the code now, all the user interface stuff is gone. Instead, what we have here is just the behavior. No UI. So to summarize, XAML gives us three really nice benefits over doing the UI in code. The first is this division of labor. We split up the work between a UI designer and the developer.
Second is XAML tends to be very tool friendly, so it's possible to use a design tool to do a lot of the UI work for you. You've probably seen tools that work like this where you have a design surface and a toolbox full of controls where you can drag controls from the toolbox onto your design surface. And there's a nice properties editor where you can set properties all in a nice graphical user interface without ever directly editing any of the underlying markup.
And finally, we get a really clean separation of our UI from our behavior.
This course was created by Xamarin University. We are honored to host this training in our library.