Complex Animations in Xamarin.Forms using Finite State Machine

Avatar

Slava

This guest post was contributed by Slava Chernikoff, a Principal Engineer at Binwell. Microsoft MVP and Xamarin Certified experienced mobile cross-platform and native developer. Also, a previously honored Nokia Champion and Qt Certified Developer.

Introduction

If you have been a student of a technical specialty, you will surely remember the course devoted to the Finite State Machines.

This simple, but very capacious model of finite state machine (a.k.a. FSM) is used widely, although most programmers have unfortunately forgotten about it. Today we will talk about finite state machines and their application in complex animations for Xamarin.Forms apps.

If you already use Xamarin.Forms in real projects, you probably saw a built-in animation engine. If not, then we recommend you start with the articles “Creating Animations with Xamarin.Forms” and “Compound Animations”.

Modifying Properties

Most often, you need to animate the following properties:

  • Scale of the element
  • Opacity transparency
  • Translation additional offset x, y, relative to the position obtained in the layout
  • Rotation rotation around the x, y, z-axes

There are low-level iOS/Android mechanisms used in Xamarin.Forms to modify these properties which have a great effect on performance, so there is no problem animating a lot of controls at once.

In our example we will focus on the set of properties shown before, however you can expand the mechanisms by yourself for supporting BackgroundColor property, for example.

Finite State Machines

Figure 1. Sample of a Finite State Machine diagram

A Finite State Machine is an object that can be in different stable states (i.e. “download” or “error”). The machine changes its states under the influence of external events. The number of states is finite. Examples of such machines are elevators and traffic lights.

How do finite state machines relate to animations and especially to Xamarin.Forms? Let’s see.

One Screen, Many States, and Animated Transitions

To learn more about page states it is suggested to start with StateContainer component by Patrick McCurley. This control simplifies the development of complex user interfaces and is suitable for most screens in business applications.

This component works well when all states exist independently of each other and there is a simple transition between them, “one disappeared — the second appeared”.

Figure 2. State switching using the StateContainer

But what if you need to implement a complex and animated transition from one state to another? As an example, let’s look at the screen for entering addresses and working with the map. It is implemented in navigators or taxi services.

Imagine that we have animated transitions between the following states of ONE screen:

Figure 3. Screen with transition animations between states

As shown, we have such a finite state machine that shown on Figure 4.

Figure 4. State transitions for navigator app main page

It is necessary to implement the following animations when changing from state to state:

  • Entering FindAddress state, will hide the old content with the animation and smoothly display the new one. Also, it will animate the buttons at the time of appearance.
  • Switching to ShowRoute, it is necessary to hide the old state and a route information component will appear from the bottom.
  • Switching to Drive, it is necessary to hide the old state and display route information on the top of the screen.
  • When going to Main (except for the first run), hide the current state and smoothly display the button with a small zoom animation.

Here you can find a demo video.

Write Your FSM

Take the simplest implementation of FSM:

  • The machine has a fixed set of states that can be specified at initialization – Method Add.
  • Each state is described by a set of necessary animations, or final properties values, for UI elements (buttons, labels, etc.).
  • When it enters to a new state, all animations that were added at the initialization of the machine are started in parallel.

We will not store any transition history. It also doesn’t matter which user event triggered the transition from one state to another. There is only a transition to a new state – the Go method, which is accompanied by animations.

So, the simplest FSM, called Storyboard, will look like this:

In the example above, the input data checks are omitted. A full version of the example can be found in the repository.

As you can see, when you move to a new state, only the necessary smooth changes are started in parallel. There is also the possibility to enter a new state without animation.

Using Finite State Machine

So, we have a machine and can connect it to set the necessary states of UI elements. Example of adding a new state:

For the Drive state, set an array of individual animations. ShowRouteView and DriveView are the usual Views, specified in XAML displayed on the example below.

To go to a new state it is enough to call the Go() method:

The code is relatively small and group animations are created by a simple set of numbers. Our state machine can work not only with pages, but also with individual View which expands the variants of its application. It is better to use Storyboard inside the page’s C# code behind(Page.cs) and not mix it with business logic (ViewModels).

Here is an example of XAML, which describes all the elements of the user interface.

Figure 5. Sample of XAML page with Storyboard

Conclusion

This article describes the Finite State Machine model and its application for complex page state transitions. If you decide to add the ability to change the color of items with animations, we recommend the article  “Building Custom Animations in Xamarin. Forms”.

The full code of the demo project can be found in this repository.

Avatar
Slava Chernikoff

Follow Slava   

1 comment

  • Avatar
    Charlie Finlayson

    Hi Slava,

    Thank you for the great tutorial. I want to ask about one part. You say “It is better to use Storyboard inside the page’s C# code behind(Page.cs) and not mix it with business logic (ViewModels).” Given that I have my view bound to commands in my ViewModel, can you recommend an approach where I could call _storyboard.Go(…) in the page when my commands in the ViewModel are actually what’s being called?

    Thanks!

Leave a comment