Validating User Input in Xamarin.Forms IV

Previously I discussed how validation can be automatically triggered when properties changes, or manually triggered to validate all properties. In this blog post I’m going to explore how to notify the user about any validation errors that have occurred.

Displaying Validation Errors

Validation errors are shown to the user by highlighting the control that contains invalid data, and by displaying an error message beneath the control, as shown in the following screenshot:

Highlighting a Control that contains Invalid Data

The Validation attached behaviour class is used to highlight controls where validation errors occur. The following code example shows how the Validation behaviour is attached to an Entry control:

<Entry Placeholder="Enter forename here" 
       Text="{Binding User.Forename, Mode=TwoWay}" 
       local:Validation.Errors="{Binding User.Errors[Forename]}" />

The Validation attached behaviour gets and sets the Errors bindable property, and in this example binds it to the Errors property of the User model class that’s exposed by the associated view model. The User.Errors property is provided by the ValidatableBase class, from which all model classes derive, and is an instance of the Validator class. The indexer of the Validator class returns a ReadOnlyCollection of error strings, to retrieve any validation errors for the Forename property. The Validation attached behavior class is shown in the following code example:

public static class Validation
{
    public static readonly BindableProperty ErrorsProperty =
        BindableProperty.CreateAttached(
            "Errors",
            typeof(ReadOnlyCollection<string>),
            typeof(Validation),
            Validator.EmptyErrorsCollection,
            propertyChanged: OnPropertyErrorsChanged);

    public static ReadOnlyCollection<string> GetErrors(BindableObject element)
    {
        return (ReadOnlyCollection<string>)element.GetValue(ErrorsProperty);
    }

    public static void SetErrors(BindableObject element, ReadOnlyCollection<string> value)
    {
        element.SetValue(ErrorsProperty, value);
    }

    static void OnPropertyErrorsChanged(BindableObject element, object oldValue, object newValue)
    {
        var view = element as View;
        if (view == null | oldValue == null || newValue == null)
        {
            return;
        }

        var propertyErrors = (ReadOnlyCollection<string>)newValue;
        if (propertyErrors.Any())
        {
            view.Effects.Add(new BorderEffect());
        }
        else
        {
            var effectToRemove = view.Effects.FirstOrDefault(e => e is BorderEffect);
            if (effectToRemove != null)
            {
                view.Effects.Remove(effectToRemove);
            }
        }
    }
}

The Errors attached property is registered as a ReadOnlyCollection of strings, by the BindableProperty.CreateAttached method. When the value of the Errors bindable property changes, the OnPropertyErrorsChanged method is invoked. The parameters for this method provide the instance of the control that the Errors bindable property is attached to, and any validation errors for the control. The BorderEffect class is added to the control’s Effects collection if validation errors are present, otherwise it’s removed from the control’s Effects collection.

The BorderEffect class subclasses the RoutingEffect class, and is shown in the following code example:

class BorderEffect : RoutingEffect
{
    public BorderEffect() : base("Xamarin.BorderEffect")
    {
    }
}

The RoutingEffect class represents a platform-independent effect that wraps an inner effect that’s usually platform-specific. This simplifies the effect removal process, since there is no compile-time access to the type information for a platform-specific effect. The BorderEffect calls the base class constructor, passing in a parameter consisting of a concatenation of the resolution group name, and the unique ID that’s specified on each platform-specific effect class.

The following code example shows the Xamarin.BorderEffect implementation for iOS:

[assembly: ResolutionGroupName("Xamarin")]
[assembly: ExportEffect(typeof(BorderEffect), "BorderEffect")]
namespace MVVMUtopia.iOS
{
    public class BorderEffect : PlatformEffect
    {
        protected override void OnAttached()
        {
            try
            {
                Control.Layer.BorderColor = UIColor.Red.CGColor;
                Control.Layer.BorderWidth = 1;
            }
            catch (Exception ex)
            {
                Console.WriteLine("Cannot set property on attached control. Error: ", ex.Message);
            }
        }

        protected override void OnDetached()
        {
            try
            {
                Control.Layer.BorderWidth = 0;
            }
            catch (Exception ex)
            {
                Console.WriteLine("Cannot set property on attached control. Error: ", ex.Message);
            }
        }
    }
}

The OnAttached method sets Control.Layer properties to values to create the red border, and the OnDetached method removes the red border. This functionality is wrapped in a try/catch block in case the control that the effect is attached to does not have the required Control.Layer properties.

For more information about effects, see Effects.

Displaying an Error Message

Each control that undergoes validation also has a Label beneath it, which is used to display the error message associated with the control. The following code example shows the Label displayed underneath the Entry that accepts a user’s forename:

<Label Text="{Binding User.Errors[Forename], Converter={StaticResource FirstErrorConverter}" />

The Label binds its Text property to the Errors property of the User model class that’s exposed by the associated view model. The User.Errors property is provided by the ValidatableBase class, from which all model classes derive, and is an instance of the Validator class. The indexer of the Validator class returns a ReadOnlyCollection of error strings, with the FirstErrorConverter retrieving the first error from the collection, for display.

Summary

Any mobile app that accepts user input should ensure that the input is valid. This could involve, for example, checking that input contains only characters in a particular range, or is of a certain length. Without validation, a user can supply data that can cause the app to fail.

In the context of MVVM, user input can be synchronously validated client-side in view model objects or in model objects. However, validating data in view models often means duplicating model properties. Instead, view models can delegate validation to the model objects they contain, with validation then being performed on the model objects. Validation rules can be specified on the model properties by using data annotations that derive from the ValidationAttribute class.

To participate in validation, model classes must derive from the ValidatableBase class, which provides an error container whose contents are updated whenever a model class property value changes. The Validator and ValidatableBase classes both implement INotifyPropertyChanged in order to provide property change notification.

The SetProperty method in the ValidatableBase class performs validation when a model property is set to a new value. The validation rules come from data annotation attributes that derive from the ValidationAttribute class. The attributes are taken from the declaration of the model property being validated.

Users are notified of validation errors by highlighting the controls that contain the invalid data with red borders, and by displaying error messages that inform the user why the data is invalid.

The code can be downloaded from GitHub.

Validating User Input in Xamarin.Forms III

Previously I discussed how validation rules are specified by adding data annotation attributes, that derive from the ValidationAttribute class, to properties in model classes that require validation. In this blog post I’m going to explore how validation is triggered, both automatically and manually.

Triggering Validation

This validation approach can automatically trigger validation when properties change, and manually trigger validation of all properties. Each will be discussed in turn.

Triggering Validation when Properties Change

Validation is automatically triggered when a bound property changes. When a two way binding in a view sets a bound property in a model class, that class should invoke the SetProperty method, provided by the BindableBase class, which sets the property values and raises the PropertyChanged event. However, the SetProperty method is also overridden by the ValidatableBase class. The SetProperty method in the ValidatableBae class calls the SetProperty method in the BindableBase class, and performs validation if the property has changed. The following code example shows how validation occurs after a property change:

public bool ValidateProperty(string propertyName)
{
    if (string.IsNullOrEmpty(propertyName))
    {
        throw new ArgumentNullException("propertyName");
    }

    var propertyInfo = entityToValidate.GetType().GetRuntimeProperty(propertyName);
    if (propertyInfo == null)
    {
        throw new ArgumentException("The entity does not contain a property with that name.", propertyName);
    }

    var propertyErrors = new List<string>();
    bool isValid = TryValidateProperty(propertyInfo, propertyErrors);
    bool errorsChanged = SetPropertyErrors(propertyInfo.Name, propertyErrors);

    if (errorsChanged)
    {
        OnErrorsChanged(propertyName);
        OnPropertyChanged(string.Format(CultureInfo.CurrentCulture, "Item[{0}]", propertyName));
    }

    return isValid;
}

This method retrieves the property to be validated, and attempts to validate it by calling the TryValidateProperty method. If the validation results change, for example, when new validation errors are found or when previous errors have been corrected, then the ErrorsChanged and PropertyChanged events are raised for the property. The following code example shows the TryValidateProperty method:

bool TryValidateProperty(PropertyInfo propertyInfo, List<string> propertyErrors)
{
    var results = new List<ValidationResult>();
    var context = new ValidationContext(entityToValidate) { MemberName = propertyInfo.Name };
    var propertyValue = propertyInfo.GetValue(entityToValidate);

    bool isValid = System.ComponentModel.DataAnnotations.Validator.TryValidateProperty(propertyValue, context, results);
    if (results.Any())
    {
        propertyErrors.AddRange(results.Select(c => c.ErrorMessage));
    }

    return isValid;
}

This method calls the TryValidateProperty method from the Validator class, to validate the property value against the validation rules for the property. Any validation errors are added to a list of errors.

Trigger Validation Manually

Validation can be triggered manually for all properties of a model object. For example, in the sample application when the user clicks the Navigate button on the FirstPage. The button’s command delegate calls the NavigateAsync method, which is shown in the following code example:

async Task NavigateAsync()
{
    if (user.ValidateProperties())
    {
        await navigationService.NavigateAsync("SecondPage");
    }
}

This method calls the ValidateProperties method of the ValidatableBase class (because the User model class derives from the ValidatableBase class), which in turn calls the ValidateProperties method of the Validator class. Providing that validation succeeds, page navigation occurs, otherwise validation errors are displayed. The following code example shows the ValidateProperties method from the Validator class:

public bool ValidateProperties()
{
    var propertiesWithChangedErrors = new List<string>();
    var propertiesToValidate = entityToValidate.GetType()
                                               .GetRuntimeProperties()
                                               .Where(c => c.GetCustomAttributes(typeof(ValidationAttribute)).Any());

    foreach (PropertyInfo propertyInfo in propertiesToValidate)
    {
        var propertyErrors = new List<string>();
        TryValidateProperty(propertyInfo, propertyErrors);

        bool errorsChanged = SetPropertyErrors(propertyInfo.Name, propertyErrors);
        if (errorsChanged && !propertiesWithChangedErrors.Contains(propertyInfo.Name))
        {
            propertiesWithChangedErrors.Add(propertyInfo.Name);
        }
    }

    foreach (string propertyName in propertiesWithChangedErrors)
    {
        OnErrorsChanged(propertyName);
        OnPropertyChanged(string.Format(CultureInfo.CurrentCulture, "Item[{0}]", propertyName));
    }

    return errors.Values.Count == 0;
}

This method retrieves any properties that have attributes that derive from the ValidationAttribute data annotation, and attempts to validate them by calling the TryValidateProperty method for each property. If the validation state changes, the ErrorsChanged and PropertyChanged events are raised for each property whose errors have changed. Changes occur when new errors are seen or when previously detected errors are no longer present.

Users are notified of validation errors by highlighting the controls that contain the invalid data with red borders, and by displaying error messages that inform the user why the data is invalid. In my next blog post I’ll explore this topic further. In the meantime, the code can be downloaded from GitHub.

Validating User Input in Xamarin.Forms II

Previously I introduced a high-level overview of an approach to validating user input in Xamarin.Forms. This approach involves specifying validation rules on model objects, invoking validation when a model property values changes, and then displaying any error messages. In this blog post I’m going to explore how to specify validation rules on model objects.

Specifying Validation Rules

Validation rules are specified by adding data annotation attributes, that derive from the ValidationAttribute class, to properties in model classes that require validation.

The following code example shows the User class, where the properties are decorated with validation attributes:

public class User : ValidatableBase
{
    string forename, surname;
    const string NAMESREGEXPATTERN = @"\A\p{L}+([\p{Zs}\-][\p{L}]+)*\z";

    [Required(ErrorMessage = "This field is required.")]
    [RegularExpression(NAMESREGEXPATTERN, ErrorMessage = "This field contains invalid characters.")]
    [StringLength(10, 
                  MinimumLength = 2, 
                  ErrorMessage = "This field requires a minimum of 2 characters and a maximum of 10.")]
    public string Forename
    {
        get { return forename; }
        set { SetProperty(ref forename, value); }
    }

    [Required(ErrorMessage = "This field is required.")]
    [RegularExpression(NAMESREGEXPATTERN, ErrorMessage = "This field contains invalid characters.")]
    [StringLength(15, 
                  MinimumLength = 2, 
                  ErrorMessage = "This field requires a minimum of 2 characters and a maximum of 15.")]
    public string Surname
    {
        get { return surname; }
        set { SetProperty(ref surname, value); }
    }
}

The Required attribute specifies that a validation failure occurs if the field is null, contains an empty string, or contains only white-space characters. The RegularExpression attribute specifies that a property must match the regular expression given by the NAMESREGEXPATTERN constant. This regular expression allows user input to consist of all unicode name characters as well as spaces and hyphens, as long as the spaces and hyphens don’t occur in sequences and are not leading or trailing characters. The StringLength attribute specifies the minimum and maximum length of characters that are allowed. Each attribute also sets an ErrorMessage property, which stores the error message to be displayed if validation fails.

It’s worth browsing the DataAnnotations namespace in order to discover all the different validation attributes. As well as the general attributes mentioned above, it contains specific attributes capable of validating email addresses, credit card numbers, and phone numbers. In addition, it also provides a CustomValidation attribute, which specifies an application-provided method to be invoked to validate the property whenever a value is assigned to it.

To participate in validation a model class must derive from the ValidatableBase class, so that model property values will be validated when they change. In my next blog post I’ll explore this topic further. In the meantime, the code can be downloaded from GitHub.

Validating User Input in Xamarin.Forms

Any mobile app that accepts user input should ensure that the input is valid. This could involve, for example, checking that input contains only characters in a particular range, or is of a certain length. Without validation, a user can supply data that can cause the app to fail.

In the context of MVVM, user input can be synchronously validated client-side in view model objects or in model objects. However, validating data in view models often means duplicating model properties. Instead, view models can delegate validation to the model objects they contain, with validation then being performed on the model objects. Validation rules can be specified on the model properties by using data annotations that derive from the ValidationAttribute class.

I’ve created a validation sample implements validation using this approach, which can be found on GitHub. The following diagram shows a high-level overview of the classes involved in validation:

To participate in validation, model classes must derive from the ValidatableBase class, which provides an error container whose contents are updated whenever a model class property value changes. The Validator and ValidatableBase classes both implement INotifyPropertyChanged in order to provide property change notification.

The SetProperty method in the ValidatableBase class performs validation when a model property is set to a new value. The validation rules come from data annotation attributes that derive from the ValidationAttribute class. The attributes are taken from the declaration of the model property being validated.

Users are notified of validation errors by highlighting the controls that contain the invalid data with red borders, and by displaying error messages that inform the user why the data is invalid, as shown in the following screenshot:

Over the coming weeks I’m going to explore this validation approach in a series of blog posts:

1. Specifying validation rules.
2. Triggering validation.
3. Displaying validation errors.

In the meantime, the code can be downloaded from GitHub.