Handling Visual States in Xamarin Forms

If there is something that can take a good-looking app to an incredible-looking app, that may very well be Visual States. By defining different Visual States, you are able to define how a certain element must look depending on some interaction from the user. Buttons are the simpler example of this, which are able to show you when someone hovers over them (by changing color), when someone presses them (by changing the scale), or when they are not being targeted.

So, how do I do this myself?

This is rather easy to implement with Xamarin Forms, which has been around since Xamarin Forms 3.0, and you should definitely learn how to use this feature. Let’s implement a couple of Visual States on an ImageButton, so that it changes its scale when pressed, which is a quite common “animation” in buttons.

Of course, we would need to start by defining the ImageButton itself, but this works with other controls as well:

<ImageButton Source="profits.png"
             Clicked="ImageButton_Pressed"
             HeightRequest="200"
             WidthRequest="200">
</ImageButton>

This ImageButton has a Clicked event handler, a source, and some Height and Width requests, but these are not necessary for the Visual States; all we need is the element (in this case, the ImageButton) to be defined with an opening and a closing tag, so that between these tags we can define the Visual States.

Defining the Visual States

This will take us a couple steps. We will start by defining as many groups of Visual States as we need. All of these groups will need to exist inside a VisualStateGroups tag, like this:

<ImageButton Source="profits.png"
             Clicked="ImageButton_Pressed"
             HeightRequest="200"
             WidthRequest="200">
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup Name="CommonStates">
          
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</ImageButton>

In this example I only need one group, which I’ve named CommonStates. You could, however, have more than one VisualStateGroup.

Now, it is inside the group where the exciting thing happens. Here we define as many states as needed. In the example that we are building, we need two of them; one for when the ImageButton is not doing anything, and another one for when the user presses it. Notice how on each state I am defining some setters; hese setters act just like the setters that define a style, accessing one Property for the element (in this case the ImageButton) and setting it to a particular value. Since we are working with VisualStates, this happens when a specific VisualState is active.

So, the first VisualState is the Normal one, which has to set the Scale of the item to 100% (or 1). The second one changes that Scale to 80%, of course, you can change this to another value, depending on your preferences. It is essential that these VisualStates are named Normal and Pressed, this way the Visual State Manager knows when to use each of them.

<ImageButton Source="profits.png"
             Clicked="ImageButton_Pressed"
             HeightRequest="200"
             WidthRequest="200">
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup Name="CommonStates">
            <VisualState Name="Normal">
                <VisualState.Setters>
                    <Setter Property="Scale" Value="1"/>
                </VisualState.Setters>
            </VisualState>
            <VisualState Name="Pressed">
                <VisualState.Setters>
                    <Setter Property="Scale" Value="0.8"/>
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</ImageButton>

Now, when you run your application, each state is used accordingly. The Normal state is the default one, and when you press the ImageButton, you can see the change in scale that is defined by the Pressed state.

You may be able to imagine how useful Visual States are in Xamarin Forms, but to give you a better idea; you can use them to handle required changes to the UI when it changes from portrait to landscape orientation. That is what I will show you how to achieve in the next post, so make sure you subscribe to my newsletter so I can let you know as soon as that new post is ready: