It has been quite a while, but today a new version of Catel is released. It took us more time then usual, but in return we have a great version ready to be downloaded via the site or via NuGet.

Added WinRT and Windows Phone 8 support

This is probably the most noticeable “feature” of all. Both WinRT and Windows Phone 8 are fully supported with all features that you are familiar with in Catel. This means that we were able to port everything (not really everything, but 90 %) of it to WinRT and all known Windows Phone features to Windows Phone 8.

Performance improvements

For this release, we focused on performance. We made a lot of improvements by tracing and tweaking all the calls thoroughly. Below is a list of tweaks:

• All reflection calls are now being cached
• Logging is only executed when there are actually listeners registered
• ModelBase.LeanAndMeanModel property to (temporarily) suspend both validation and change notifications, great when restoring models from disk
• Added a FastObservableCollection which allows the adding of a range and only invokes a single event at the end
• It is now possible to control (globally or per control) whether InfoBarMessageControl and WarningAndErrorValidator controls must be created or MVVM controls
• Constructors in the ServiceLocator are cached which gives a major performance boost when creating new instances of types with dependency injection

Improved IoC container

The IoC container in Catel, the ServiceLocator, now supports registration of types with a tag. This allows the same type to be registered multiple times.

And much more…

Besides new features, we also fixed over 40 issues in this new release. Not all new features are described in this blog post, so make sure you get the latest version while it’s hot!

The Catel team is very proud the announce the new 3.2 release. As always, the new version is available via NuGet and via Codeplex (http://catel.codeplex.com).

In this blog post, I will try to explain the most important new changes in Catel.

Dependency injection support in the ServiceLocator

The ServiceLocator in Catel now fully supports dependency injection. This means that when a type is being resolved from the ServiceLocator.

Dependency injection via the ServiceLocator in Catel is enabled by default. This means that when a type is resolved from the container, it will automatically use dependency injection to construct the type if it is not registered as instance.

It will first search for all available constructors on the type that will be instantiated. Then, for each constructor, starting with the one with the most parameters, it will try to retrieve all values. If one fails, it will go to the next. If all fail, it will try to use the default constructor without parameters. If that fails as well, then the type cannot be constructed and an exception will be thrown.

To get a better understanding of what happens, see the class below:

public class MyClass
{
  private IFirstDependency _firstDependency;
  private ISecondDependency _secondDependency;
 
  public MyClass()
     : this(null) { }
 
  public MyClass(IFirstDependency firstDependency)
     : this(firstDependency, null) { }
 
  public MyClass(IFirstDependency firstDependency, ISecondDependency secondDepdenceny)
  {
    _firstDependency = firstDependency;
    _secondDependency = secondDependency;
  }
}

When the MyClass will be retrieved from the ServiceLocator, this will happen:

1. Find constructor with most parameters (the one with both firstDependency and secondDependency). If both IFirstDependency and ISecondDependency can be resolved from the ServiceLocator, the type will be constructed with the constructor. Otherwise it will proceed with step 2.
2. Find next constructor with most parameters (the one with only firstDependency). If IFirstDependency can be resolved from the ServiceLocator, the type will be constructed with the constructor. Otherwise it will proceed with step 3.
3. At this point, no constructor could be used. In this case, the ServiceLocator will try to use the default constructor (the one without parameters) as last resort to instantiate the type.

Introducing the ViewModelFactory

In previous versions of Catel, it was only possible to inject a datacontext into a view model. In Catel 3.2, the new ViewModelFactory is introduced. This class is responsible for instantiating the view model.

By default, the implementation does exactly the same as before, but this gives great freedom when the view models cannot be instantiated by Catel itself (for example, when dependency injection is used, or when the registered view models of a control are interfaces).

Below is an example of a custom implementation of a view model factory:

public class CustomViewModelFactory : ViewModelFactory
{
  public override IViewModel CreateViewModel(Type viewModelType, object dataContext)
  {
      if (viewModelType == typeof(MySpecialViewModel))
      {
          // Use custom constructor with dependency injection
          return new MySpecialViewModel(dep1, dep2, dep3, dataContext);
      }
 
      // Fall back to default behavior
      return base.CreateViewModel(viewModelType, dataContext);
  }
}

All reflection is cached

In preparation for WinRT support, we moved all reflection to a single class with extension methods. This was a great opportunity to add caching to all reflection.

This means that all reflection is cached on the first call. This provides major performance improvements when using reflection.

More flexible behavior base classes

Catel already provided memory leak free base classes for behaviors and triggers. In the new version, a few new base classes are introduced to allow faster behavior developmentP:

• CommandBehaviorBase – supports a command, command parameter and key modifiers out of the box
• UpdateBindingBehaviorBase – supports binding updates on dynamic dependency properties

Core services now only use interfaces for MVVM integration

The core services (such as the MVVM behaviors) in Catel now use interfaces such as INotifyableViewModel and IRelationViewmodel. This makes it possible to use different base classes for view models and still use the full potential of Catel.

Updated to latest external libraries

We also took the time to update all external libraries to the latest version. The following libraries were updated:

• Ninject (3.0)
• Castle.Windsor (3.0)
• FluentValidation (3.3.1)

We just released Catel 3.1. You can grab the latest version:

• Via NuGet
• Via installer

In this blog post, we already described the most important changes, but you can find a full list of changes here.

As always, if you have any questions or feature requests, don’t hesitate to contact us or create an issue!

So, it’s been another month since we released Catel 3.0. This means that soon, we will release a new version, and it will be 3.1. You can grab the latest version:

• Via NuGet
• Via installer

Below is a list of the most important changes.

OnDataContextChanged and OnPropertyChanged methods

Since lots of people need to write handlers (but forget to unsubscribe thus cause memory leaks), we made these available as default to all controls that Catel provides.

AsynchronousCommand

Asynchronous development becomes more and more important. In the latest version, we proudly introduce the AsynchronousCommand, which is a command that runs in the background and doesn’t block and UI. It is able to provide thread-safe callbacks to the UI as well.

You can read all about it in the official docs.

Memento pattern

The memento pattern is something hardly any custom made application implements due to its complexity. Catel now includes a memento service which allows to undo/redo changes on properties, collections and custom actions.

If you ever need to build in undo/redo support, this is what you are looking for! You can read all about it in the official docs.

Note that this feature is also available for non-xaml solutions

Improved handling of datacontext changes for nested user control scenarios

If you are using Catel, you are probably aware that you sometimes get false reports of binding errors. Catel now uses an improved way of determining the right datacontext in nested user control scenarios so these false errors no long appear in your output window.

What to expect next?

We are currently investigating what it takes to port Catel to WinRT. However, since reflection in WinRT is very basic (for example, we cannot get the name of a method), it is really hard to implement the WeakEventListener and MessageMediator in WinRT. However, we will keep trying…

You can also checkout the road map.

In Catel (2.5, not released yet, only beta available), it is possible to hook the CanExecute of a Command to the IValidationSummary automatically. This way, there is no need to check for errors manually in the CanExecute. The example below first adds a validation summary to a view model to get the validation result. Then, it uses this validation summary to automatically determine whether a command can be executed.

1. Add validation to a person view model (note how the validation adds the tag PersonValidation to a validation):

   1: /// <summary>

   2: /// Validates the field values of this object. Override this method to enable

   3: /// validation of field values.

   4: /// </summary>

   5: /// <param name="validationResults">The validation results, add additional results to this list.</param>

   6: protected override void ValidateFields(System.Collections.Generic.List<IFieldValidationResult> validationResults)

   7: {

   8:     if (string.IsNullOrEmpty(FirstName))

   9:     {

  10:         validationResults.Add(FieldValidationResult.CreateError(FirstNameProperty, "First name cannot be empty", "PersonValidation"));

  11:     }

  12:  

  13:     if (string.IsNullOrEmpty(LastName))

  14:     {

  15:         validationResults.Add(FieldValidationResult.CreateError(LastNameProperty, "Last name cannot be empty", "PersonValidation"));

  16:     }

  17: }

2. Add a property to the view model containing the validation summary using the ValidationToViewModel attribute.

   1: [ValidationToViewModel(Tag = "PersonValidation")]

   2: public IValidationSummary PersonValidationSummary { get; set; }

3. Define a command on the view model:

   1: /// <summary>

   2: /// Gets the Save command.

   3: /// </summary>

   4: public Command Save { get; private set; }

   5:  

   6: /// <summary>

   7: /// Method to invoke when the Save command is executed.

   8: /// </summary>

   9: private void OnSaveExecute()

  10: {

  11:     // TODO: Handle command logic here

  12: }

4. Create the command that automatically uses the validation summary using the CommandHelper class:

   1: Save = CommandHelper.CreateCommand(OnSaveExecute, () => PersonValidationSummary);

With this example, the Save command on the view model can only be executed when there are no errors with the PersonValidation tag.