Caliburn Micro

I have been building Windows Phone apps using the Caliburn.Micro framework for some time now. Setting up a new project takes some time and can be easily automated, so I decided to create a Visual Studio template for Windows Phone apps build with Caliburn.Micro.

The templates can be downloaded from the Visual Studio Extensions gallery and used to build Windows Phone 8 and Windows Phone 8.1 Silverlight apps. It contains the basic setup with Caliburn Micro and Fody, with a sample view and viewmodel.

The source code is available on GitHub, so if you want to modify it to best suit your needs, feel free to do it.

My MVVM framework of choice, Caliburn.Micro, provides a simple Dependency Injection container, where you have to register all your ViewModels and Services. This is done in the Bootstraper’s Configure method and may look like this:

container.PerRequest<MainViewModel>():
container.PerRequest<AboutViewModel>();

container.Singleton<SessionService>();
container.RegisterSingleton(typeof(ISettingsService),null,typeof(SettingsService));

where you typically register your ViewModels as per request and services as singletons.

Of course this is done just once, but having to register a ViewModel each time you create a new one can be a nuisance, especially in a large project.

Windows Phone 8.1 introduced many interesting new thing, the one I personally like the best as a developer is the Share Contract. The Share Contract allows your apps to share data using an unified and easy way and also to receive data from other apps. This functionality is important for my Pock8 app, which is a Pocket client. By making Pock8 app a Share Contract target, the app can receive links from other apps, more importantly from the built-in webrowser (IE). This makes the app even more easy to use and valuable.

The problem is that all the documentation I found and also the sample app are for Windows Runtime. Pock8 is a Silverligt app and I have no intentions to rewrite it to Windows Runtime.

I had to make some digging and I finally found the solution in a build video called Contracts and Pickers: Building Apps that Work Together on Windows.

Having a Search box in a Windows Phone app is a common use-case but it is only rarely done right. A good Search box does not have a Search button associated with it that the users have to click when they are finished typing and want to start the search. A good Search box starts the search immediately when the user stops typing (for a certain period of time).

You can implement this functionality with some nasty code using a DispatcherTimer, or you can use Reactive Extensions. You can use Reactive Extensions directly on a TextBox representing the Search box, but if you use MVVM (and you should) you need to attach to the property associated with the Search box instead.

Suppose the ViewModel contains a string property called SearchTerm (with two-way binding to the Search box) and an event called PropertyChanged (used for the INotifyPropertyChanged implementation). We need to observe the changes of the SearchTerm property. There is no way to do it directly, we need to observe the PropertyChanged event instead.

In this installment of the series I will show you how user data services. We will finally use the Unity DI container that is part of the project setup.

Data and Services

In next installment we will be showing a list of products, so let’s create a simple Product class first in the Data directory:

PropertyChangedBase is a base class implementing the INotifyPropertyChanged interface and the ImplementPropertyChanged attribute makes sure it’s method is called for all the property changes. (More about Fody here)

In the previous post I stated that a well-behaved Windows Store app should remeber the View the user navigated to before suspension and navigate to this View upon next run. The View can contain some input that the user can fill in. A well-behaved Windows Store app should remember the user’s input and restore it after suspension.

Saving and restoring state

Implementation of the above-mentioned scenario is not very complicated, thanks to the project setup. If you want your ViewModel to be able to save and restore state, implement the IHaveState interface. It contains two method that you can override; SaveState and LoadState. In bith method you have access to a page state dictionary that you can use to save and load the state.

In this second part you will add another ViewModel and View and implement navigation between two ViewModels, including saving the navigation state between starts. The code is as always available at Github.

Invoking ViewModel methods

If you want to test out navigation between ViewModels, you first need something that will trigger the navigation. The easiest way to do this is to use a standard Button. If you do MVVM “by hand”, you are probably used to creating ICommand properties and binding them to the Button’s Command dependency property.

Caliburn Micro offers an easier way. If you want a Button to invoke a method on your ViewModel, just the give the button the same name as the name of the button. The method should be public void.

I have been developing Windows Store apps for some time. I have always used MVVM, but mostly “my own” MVVM. I have finally decided to use a “real” MVVM framework and I have chosen Caliburn Micro, because I did not like MVVM very much. In this article I am going to show you how to use Caliburn Micro, Unity and Fody to develop Windows Store apps.

Caliburn Micro

Caliburn Micro is a small, yet powerful framework, designed for building applications across all Xaml Platforms. With strong support for MVVM and other proven UI patterns, Caliburn.Micro will enable you to build your solution quickly, without the need to sacrifice code quality or testability.