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)

So, lots of people came to me asking whether there will be a WinRT version of Catel. First, I said we were seriously considering it. But lately the idea of not supporting it became more and more the idea I wanted to follow.

A little history

Instead of going with the flow, let’s first take a look at the history of Catel and why it has been created anyway. Mid 2010, I needed a (WPF) MVVM framework that would contain the following features:

• Support IDataErrorInfo for the view model so it could contain validation
• Nested user controls (because I couldn’t create big trees of hierarchy view models)
• Ease of development

With the latest I mean I didn’t want to go with the hype where everything needed to be “light”, simply because I always found myself writing extension methods and improving code. After I seriously considered Cinch, the moment I decided to write my own was when there was a “view model generator tool”.

When I started with MVVM and Xaml, all I did was WPF, which is simply the best implementation of Xaml for me. But, then people started asking: can you support Silverlight as well? Then the hell of missing features began. Lots of interfaces that Catel uses to allow property undo-ing such as INotifyPropertyChanging were not supported. It took me about 3 weeks to make sure everything in Catel also worked in Silverlight. Most of the time, I simply wrote the WPF features that were missing from Silverlight to allow the same functionality of Catel in Silverlight.

When WP7 came out, I was already prepared for the upcoming hell, but it wasn’t as bad as the transition from WPF => Silverlight. However, it again took me at least 2 weeks to create all the project and item templates and the Windows Phone specific implementations of the navigation services and tombstoning.

When the windows 8 beta came out, I quickly installed it to check out what has changed so I could convert Catel. But… it seems there are more, much more changes than I expected. For example, the whole reflection system has been changed.

Also, Catel supports a WeakEventListener and WeakActions for the MessageMediator, but this is simply not possible in WinRT because important reflection (although public) is not available.

What’s WinRT exactly?

After fighting with WinRT for about 4 weeks, I decided to take a look at the the current state and how much work there was in front of me. Then I realized I already left out the most important features (because I knew they wouldn’t compile anyway out of the box), but I couldn’t even get the Core libraries to compile (such as the WeakEventListener).

Then I thought: is Catel the way to go for WinRT anyway? And the answer is no. I see WinRT applications as a windows phone application without any specific LoB requirements. For example, checking the weather, checking facebook, etc. If you need a real LoB application, I still recommend to go for WPF or Silverlight which is the way to go.

Taking a look at the history of Catel, it was originally founded as a LoB framework, not as a framework to fit all purposes such as very light applications. I have decided to stick with the initial goal (targeting LoB applications) and the pain is just not worth the gain.

Is it definitely a no go?

For now: yes. If I am honest, apps written in WinRT are so light that a full-featured framework such as Catel is an overkill. You can better choose a light framework such as MVVM light which basically only supports property change notifications, a messenger and event to command.

I did write lots of code to allow reflection on both WinRT and not WinRT platforms in Catel , but it is not finished. Maybe, if Microsoft makes some changes so we can actually get, for example, the MethodInfo of a handler, we will re-evaluate the decision.

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.

We as developers of Catel are a huge fan of Resharper. And, of course we are also a big fan of Catel. One of the developers, Alex, came up with a great idea (and implementation) of a plugin for Resharper which makes it much easier to write Catel specific features.

Before we start, you can find the installer here.

Checking arguments of a method

If you are not using the Argument class, you are definitely missing something! It allows you to check for a method input and make sure it is valid. So, instead of writing this:

public void DoSomething(string myInput)
{
    if (string.IsNullOrWhitespace(myInput)
    {
        Log.Error("Argument 'myInput' cannot be null or whitespace");
        throw new ArgumentException("Argument 'myInput' cannot be null or whitespace", "myInput");
    }

    // custom logic
}

You can write this:

public void DoSomething(string myInput)
{
    Argument.IsNotNullOrWhitespace("myInput", myInput);

    // custom logic
}

However, when you are writing lots of code, then even this piece of code can be too much. Thanks to the Catel.Resharper plugin, it is possible to select the argument (in this case myInput), hit ALT + Enter and generate the code, just like the video below:

Converting regular properties into Catel properties

Catel is extremely powerful, but sometimes the property definitions are lots of work to write down. The code snippets already make your life much easier, but with the Catel.Resharper plugin it might be even easier. You can simply write this code:

public class Person : DataObjectBase<Person>
{
    public string FirstName { get; set; }

    public string MiddleName { get; set; }

    public string LastName { get; set; }
}

Then hit ALT + Enter and turn properties into Catel properties, which will result in this class:

public class Person : DataObjectBase<Person>
{
    /// <summary>
    /// Gets or sets the first name.
    /// </summary>
    public string FirstName
    {
        get { return GetValue<string>(FirstNameProperty); }
        set { SetValue(FirstNameProperty, value); }
    }

    /// <summary>
    /// Register the FirstName property so it is known in the class.
    /// </summary>
    public static readonly PropertyData FirstNameProperty = RegisterProperty("FirstName", typeof(string));


    /// <summary>
    /// Gets or sets the middle name.
    /// </summary>
    public string MiddleName
    {
        get { return GetValue<string>(MiddleNameProperty); }
        set { SetValue(MiddleNameProperty, value); }
    }

    /// <summary>
    /// Register the MiddleName property so it is known in the class.
    /// </summary>
    public static readonly PropertyData MiddleNameProperty = RegisterProperty("MiddleName", typeof(string));

    /// <summary>
    /// Gets or sets the last name.
    /// </summary>
    public string LastName
    {
        get { return GetValue<string>(LastNameProperty); }
        set { SetValue(LastNameProperty, value); }
    }

    /// <summary>
    /// Register the LastName property so it is known in the class.
    /// </summary>
    public static readonly PropertyData LastNameProperty = RegisterProperty("LastName", typeof(string));
}