1. Home
  2. Training Library
  3. Programming
  4. Programming Courses
  5. Building a Xamarin Forms UI - Resources



Resources in Xamarin
1m 3s

The course is part of this learning path


Building a Xamarin Forms UI - Resources continues to refine the user interface XAML we developed in Building a Xamarin Forms UI - Layout Containers course. In this course, we introduce resources as a means of streamlining the customizations and formatting of the UI elements. Resources enable the developer to centrally locate controls' formatting and then easily apply the "look and feel" to multiple controls.

Souce code




XAML is all about the user interface, meaning that it is mostly about formatting and style. This is another commonality Xaml shares with HTML. Setting multiple stylistic attributes for each element is tedious and makes maintenance and changes time-consuming. Let's look at xaml resources that enable you to define stylistic attributes in one place and use them throughout your application. If this sounds a lot like CSS, you're not wrong. Resources are scoped, meaning they can be applied to pages, views, or the application as a whole. Let's start by defining some style resources for the MainPage. Resources are defined within a resource tag, so in this case, it will be ContentPage.Resources.

I'll define two colors, one for the button background and one for the button text. The x:key attribute is the resource's name used when styling an element. With the resources defined, we can substitute the literal color value with the resource name. Still within the quotes and within curly braces, we can use the keywords StaticResource or DynamicResource followed by the resource name. A static resource is evaluated at compile-time, whereas a dynamic resource is evaluated when the element is rendered. In this simple example, it doesn't matter whether I say the resource is static or dynamic; the result will be the same. Not a great example of showing the difference as those two blues are very similar; I'll change the dark blue button resource to forest green. You can see that resources are really just interpolation or substitution. Their power comes when they are used globally. 

You can define resources at the application level within the App.xaml file. I'll paste the MainPage resources between the Application.Resources tags in App.xaml. 

As I said, resources are scoped, so a resource with the same name at the page level will take precedence over its namesake defined at the application level. If I change the dark blue button back to the hexadecimal value and then comment out the resource definition on MainPage, we can see the buttons become the same color. I'll also define a frame border color to use with the MainPage frame. It's good practice to define your resources within a separate file known as a resource dictionary, a xaml file with no code-behind file. I'll add a resource dictionary to the root of the application structure.

There is no resource dictionary item type, so I'll just create a new ContentPage called MyResources. I still need the Xamarin and Microsoft schema namespaces, but I can delete the reference to the code-behind class. I'm getting all these green squiggly lines because the application is still running. I'll paste in my dark blue button colors and delete the MyResources.xaml.cs file. While I'm here, I'll define an integer resource specifying the amount of corner radius I want on my controls. Once we have the resource dictionary defined, we can place a reference to it within the Application.Resources tags. In the way I've referenced the dictionary, you can see that you could have multiple resource dictionaries, but you just need to be aware of resource name collisions between dictionaries. I'll go back to MainPage.xaml and substitute in my resource names for the literal values. 

While we're on the subject of resources, let's add a custom font as a resource. I'll create a new resource folder with a font folder underneath it and add the inkfree font. Within AssemblyInfo.cs, we need to export the font from the Xamarin forms assembly to be available for our android and iOS apps. I'll give it an alias that I'll use within my resources, and I need to add a using statement for Xamarin.forms. Last but by no means least, I need to mark the font's build action as an embedded resource. Next, I'll define a few more resources for the font size and the font name using the alias.

As you can see, a resource definition begins with a type, whether it's color, an integer type, or a string. Keeping with the CSS theme, I can define a style as a resource that incorporates a bunch of stylistic attributes under one name. The style is called MainPageButtonStyle, which targets a button. The target type is important because we use setter tags to assign resources to the various properties of the user interface element. This style changes the background color, text color, corner radius, font, and font size.

Each one of these properties is assigned a resource value. Okay, let's run that and see what it looks like. Hmmm, I did not expect that. It turns out that the corner radius data type for a frame is a floating-point single number, whereas a button's corner radius is an Int32. Who would have guessed, certainly not me. I need to define two corner radius resources, one for the frame and one for the button. 

So why are we finding out about this data mismatch now when I set the frames corner radius earlier? I'm guessing because I was making the XAML changes while the app was running under hot-reload, and only when I restarted the app causing the code to be re-compiled did Visual Studio catch the error. Now that's working properly; I can change the frame's corner radius via the resource.


With the style defined, I can remove the background color and text color from the layouts button and assign my style resource to the style property of the button. Now we can see our layouts button has rounded corners and uses the InkFree font. Adjusting values within the resource dictionary still translates to the emulator via hot reload in real-time.

About the Author
Learning Paths

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.