caliburnmicro Wiki Rss Feed

New Comment on "Introduction"

wst — Fri, 17 May 2013 13:13:57 GMT

typo: "Simply inherit from Bootsrapper" --> should be "BootsTrapper"

Updated Wiki: Documentation

McDonnellDean — Tue, 14 May 2013 22:07:02 GMT

Documentation

Getting Started

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- Working with Windows Phone 7 v1.0 v1.1
- Working with WinRT
  - WinRT Sharing with Caliburn Micro
  - WinRT Settings with Caliburn Micro
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
  - View/ViewModel Naming Conventions (v1.3)
  - Handling Custom Conventions (v1.3)
  - Using the NameTransformer - Advanced (v1.1)
- The Event Aggregator
- The Simple IoC Container
- The Service Locator
- The Window Manager
- Design-Time Support
- Async (Task) Support

External Tutorial

Recipes
- LoadCatalog Result
- Testing Coroutines

NOTE: Recipes are not maintained by the Caliburn.Micro project but by their contributors. Please contact the contributor with any issues you may find.

Contests
- 2010 Caliburn.Micro Application Contest Winners

3rd Party Extensions
- Telerik Integration (for SL 5.0 and WPF 4.0)
- DevExpress Integration (for WPF 4.0)
- ReactiveUI Integration (for SL 5.0, WPF 4.5 and WinRT)
- Bindable ApplicationBar (for WP 7.1 and WP 8.0)
- Some Extras (for all platforms)

NOTE: Please contact us if you want a project to be added to the list.

Updated Wiki: The Service Locator

McDonnellDean — Tue, 14 May 2013 22:06:20 GMT

To Follow...

Updated Wiki: The Event Aggregator

McDonnellDean — Mon, 13 May 2013 08:36:53 GMT

The Event Aggregator

Caliburn.Micro comes pre-bundled with an Event Aggregator, conveniently called EventAggregator. For those unfamiliar, an Event Aggregator is a service that provides the ability to publish an object from one entity to another in a loosely based fashion. Event Aggregator is actually a pattern and it's implementation can vary from framework to framework. For Caliburn.Micro we focused on making our Event Aggregator implementation simple to use without sacrificing features or flexibility.

Getting Started

As previously mentioned we provide an implementation of Event Aggregator for you. This implementation implements the IEventAggregator interface, however, you can provide your own implementation if required. Please take a moment to familiarize yourself with the IEventAggregator signature.

    public interface IEventAggregator {
    	Action<Action> PublicationThreadMarshaller { get; set; }
    	bool HandlerExistsFor(Type messageType);
    	void Subscribe(object subscriber);
    	void Unsubscribe(object subscriber);
    	void Publish(object message);
    	void Publish(object message, Action<Action> marshal);
    }

Creation and Lifecycle

To use the EventAggregator correctly it must exist as an application level service. This is usually achieved by creating an instance of EventAggregator as a Singleton. We recommend that you use Dependency Injection to obtain a reference to the instance although we do not enforce this. The sample below details how to create an instance of EventAggregator, add it to the IoC container included with Caliburn.Micro (although you are free to use any container you wish) and request it in a ViewModel.

    // Creating the EventAggregator as a singleton.
    public class Bootstrapper : BootstrapperBase {
        private readonly SimpleContainer _container =
            new SimpleContainer();

         // ... Other Bootstrapper Config

        protected override void Configure(){
            _container.Singleton<IEventAggregator, EventAggregator>();
        }

        // ... Other Bootstrapper Config
    }

    // Acquiring the EventAggregator in a viewModel.
    public class FooViewModel {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
        }
    }

Note that we are utilizing the Bootstrapper, and specifically the Configure method, in the code above. There is no requirement to wire up the EventAggregator in a specific location, simply ensure it is created before it is first requested.

Publishing Events

Once you have obtained a reference to the EventAggregator instance you are free to begin publishing Events. An Event or message as we call it to distinguish between .Net events, can be any object you like. There is no requirement to build your Events in any specific fashion. As you can see in the sample below the Publish method can accept any entity that derives from System.Object and will happily publish it to any interested subscribers.

    public class FooViewModel {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;

            _eventAggregator.Publish(new object());
            _eventAggregator.Publish("Hello World");
            _eventAggregator.Publish(22);
        }
    }

Publishing using a custom thread Marshal

By convention, the EventAggregator publishes on the UI thread. You can override this in two places, globally and per publish. Consider the following code below which publishes the message supplied on a background thread.

    _eventAggregator.Publish(new object(), action => {
                    Task.Factory.StartNew(action);
                });

You can also swap out the default marshaller globally.

    _eventAggregator.PublicationThreadMarshaller = action => { action(); };

Subscribing To Events

Any entity can subscribe to any Event by providing itself to the EventAggregator via the Subscribe method. To keep this functionality easy to use we provide a special interface (IHandle<T>) which marks a subscriber as interested in an Event of a given type.

    IHandle<TMessage> : IHandle {
	    void Handle<TMessage>(TMessage message);
    }

Notice that by implementing the interface above you are forced to implement the method Handle(T message) were T is the type of message you have specified your interest in. This method is what will be called when a matching Event type is published.

    public class FooViewModel : IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message) {
            // Handle the message here.
        }
    }

You may be wondering about IHandle<T> implementing IHandle. IHandle is a Marker Interface used internally to assist with reflecting over various IHandle Implementations, you do not need to work with this interface directly.

Subscribing To Many Events

It is not uncommon for a single entity to want to listen for multiple event types. Because of our use of generics this is as simple as adding a second IHandle<T> interface to the subscriber. Notice that Handle method is now overloaded with the new Event type.

    public class FooViewModel : IHandle<string>, IHandle<bool> {
        private readonly IEventAggregator _eventAggregator;
    
        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }
    
        public void Handle(string message) {
            // Handle the message here.
        }

        public void Handle(bool message) {
            // Handle the message here.
        }
    }

Polymorphic Subscribers

Caliburn.Micro's EventAggregator honors polymorphism. When selecting handlers to call, the EventAggregator will fire any handler who's Event type is assignable from the Event being sent. This results in a lot of flexibility and helps reuse.

    public class FooViewModel : IHandle<object>, IHandle<string> {
        private readonly IEventAggregator _eventAggregator;
    
        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
            _eventAggregator.Publish("Hello");
        }
    
        public void Handle(object message) {
            // This will be called
        }

        public void Handle(string message) {
            // This also
        }
    }

In the example above, because String is derived from System.Object both handlers will be called when a String message is published.

Querying Handlers

When a subscriber is passed to the EventAggregator it is broken down into a special object called a Handler and a weak reference is maintained. We provide a mechanism to query the EventAggregator to see if a given Event type has any handlers, this can be useful in specific scenarios were at least one handler is assumed to exist.

    public class FooViewModel : IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message){
            if (_eventAggregator.HandlerExistsFor(typeof(SpecialMessageEvent))){
                _eventAggregator.Publish(new SpecialEventMessage(message));
            }
        }
    }

Coroutine Aware Subscribers

If you are using the EventAggregator with Caliburn.Micro as opposed to on it's own via Nuget, access to Coroutine support within the Event Aggregator becomes available. Coroutines are supported via the IHandleWithCoroutine<T> Interface.

    public interface IHandleWithCoroutine<TMessage> : IHandle {
		IEnumerable<IResult> Handle(TMessage message);
    }

The code below utilizes Coroutines with the EventAggregator. In this instance Activate will be fired asynchronously, Do work however, will not be called until after Activate has completed.

    public class FooViewModel : Screen, IHandleWithCoroutine<EventWithCoroutine> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public IEnumerable<IResult> Handle(EventWithCoroutine message) {
            yield return message.Activate();
            yield return message.DoWork();
        }
    }

    public class EventWithCoroutine {
        public IResult Activate() {
            return new TaskResult(Task.Factory.StartNew(() => {
                    // Activate logic
                }));
        }

        public IResult DoWork() {
            return new TaskResult(Task.Factory.StartNew(() => {
                // Do work logic
            }));
        }
    }

Task Aware Subscribers

Caliburn.Micro also provides support for task based subscribers where the asynchronous functionality of Coroutines is desired but in a more light weight fashion. To utilize this functionality implement the IHandleWithTask<T> Interface, seen below.

    public interface IHandleWithTask<TMessage> : IHandle {
        Task Handle(TMessage message);
    }

Any subscribers that implement the above interface can then handle events in Task based manner.

    public class FooViewModel : Screen, IHandleWithTask<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public Task Handle(object message) {
            return Task.Factory.StartNew(() => message);
        }
    }

Unsubscribing and Leaks

The problem with standard .Net events is that they are prone to memory leaks. We avoid this situation by maintaining a weak reference to subscribers. If the only thing that references a subscriber is the EventAggregator then it will be allowed to go out of scope and ultimately be garbage collected. However, we still provide an explicit way to unsubscribe to allow for conditional handling as seen below.

    public class FooViewModel : Screen, IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message) {
            // Handle the message here.
        }

        protected override void OnActivate() {
            _eventAggregator.Subscribe(this);
            base.OnActivate();
        }

        protected override void OnDeactivate(bool close) {
            _eventAggregator.Unsubscribe(this);
            base.OnDeactivate(close);
        }
    }

In the code above Screen is used to expose lifecycle events on the ViewModel. More on this can be found on this in the Screens, Conductors and Composition article on this wiki.

Custom Result Handling

In more complex scenarios it may be required to override the default handling of Handlers which have results. In this instance it is possible to swap out the existing implementation in favour of your own. First we create a new handler type.

    IHandleAndReturnString<T> : IHandle {
	    string Handle<T>(T message);
    }

Next we create our new result processor. This can be configured in the bootstrapper.

    var standardResultProcesser = EventAggregator.HandlerResultProcessing;
    EventAggregator.HandlerResultProcessing = (target, result) =>
    {
        var stringResult = result as string;
        if (stringResult != null)
            MessageBox.Show(stringResult);
        else
            standardResultProcesser(target, result);
    };

Now, any time an event is processed returns a string, it will be captured and displayed in a MessageBox. The new handler falls back to the default implementations in cases were the result is not assignable from string. It is extremely important to note however, this feature was not designed for request / response usage, treating it as such will most definitely create bottle necks on publish.

Updated Wiki: The Event Aggregator

McDonnellDean — Mon, 13 May 2013 08:36:07 GMT

The Event Aggregator

Getting Started

    public interface IEventAggregator {
    	Action<Action> PublicationThreadMarshaller { get; set; }
    	bool HandlerExistsFor(Type messageType);
    	void Subscribe(object subscriber);
    	void Unsubscribe(object subscriber);
    	void Publish(object message);
    	void Publish(object message, Action<Action> marshal);
    }

Creation and Lifecycle

    // Creating the EventAggregator as a singleton.
    public class Bootstrapper : BootstrapperBase {
        private readonly SimpleContainer _container =
            new SimpleContainer();

         // ... Other Bootstrapper Config

        protected override void Configure(){
            _container.Singleton<IEventAggregator, EventAggregator>();
        }

        // ... Other Bootstrapper Config
    }

    // Acquiring the EventAggregator in a viewModel.
    public class FooViewModel {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
        }
    }

Publishing Events

    public class FooViewModel {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;

            _eventAggregator.Publish(new object());
            _eventAggregator.Publish("Hello World");
            _eventAggregator.Publish(22);
        }
    }

Publishing using a custom thread Marshal

    _eventAggregator.Publish(new object(), action => {
                    Task.Factory.StartNew(action);
                });

You can also swap out the default marshaller globally.

    _eventAggregator.PublicationThreadMarshaller = action => { action(); };

Subscribing To Events

    IHandle<TMessage> : IHandle {
	    void Handle<TMessage>(TMessage message);
    }

    public class FooViewModel : IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message) {
            // Handle the message here.
        }
    }

Subscribing To Many Events

    public class FooViewModel : IHandle<string>, IHandle<bool> {
        private readonly IEventAggregator _eventAggregator;
    
        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }
    
        public void Handle(string message) {
            // Handle the message here.
        }

        public void Handle(bool message) {
            // Handle the message here.
        }
    }

Polymorphic Subscribers

    public class FooViewModel : IHandle<object>, IHandle<string> {
        private readonly IEventAggregator _eventAggregator;
    
        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
            _eventAggregator.Publish("Hello");
        }
    
        public void Handle(object message) {
            // This will be called
        }

        public void Handle(string message) {
            // This also
        }
    }

In the example above, because String is derived from System.Object both handlers will be called when a String message is published.

Querying Handlers

    public class FooViewModel : IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message){
            if (_eventAggregator.HandlerExistsFor(typeof(SpecialMessageEvent))){
                _eventAggregator.Publish(new SpecialEventMessage(message));
            }
        }
    }

Coroutine Aware Subscribers

    public interface IHandleWithCoroutine<TMessage> : IHandle {
		IEnumerable<IResult> Handle(TMessage message);
    }

The code below utilizes Coroutines with the EventAggregator. In this instance Activate will be fired asynchronously, Do work however, will not be called until after Activate has completed.

    public class FooViewModel : Screen, IHandleWithCoroutine<EventWithCoroutine> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public IEnumerable<IResult> Handle(EventWithCoroutine message) {
            yield return message.Activate();
            yield return message.DoWork();
        }
    }

    public class EventWithCoroutine {
        public IResult Activate() {
            return new TaskResult(Task.Factory.StartNew(() => {
                    // Activate logic
                }));
        }

        public IResult DoWork() {
            return new TaskResult(Task.Factory.StartNew(() => {
                // Do work logic
            }));
        }
    }

Task Aware Subscribers

    public interface IHandleWithTask<TMessage> : IHandle {
        Task Handle(TMessage message);
    }

Any subscribers that implement the above interface can then handle events in Task based manner.

    public class FooViewModel : Screen, IHandleWithTask<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public Task Handle(object message) {
            return Task.Factory.StartNew(() => message);
        }
    }

Unsubscribing and Leaks

    public class FooViewModel : Screen, IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message) {
            // Handle the message here.
        }

        protected override void OnActivate() {
            _eventAggregator.Subscribe(this);
            base.OnActivate();
        }

        protected override void OnDeactivate(bool close) {
            _eventAggregator.Unsubscribe(this);
            base.OnDeactivate(close);
        }
    }

In the code above Screen is used to expose lifecycle events on the ViewModel. More on this can be found on this in the Screens, Conductors and Composition article on this wiki.

Custom Result Handling

    IHandleAndReturnString<T> : IHandle {
	    string Handle<T>(T message);
    }

Next we create our new result processor. This can be configured in the bootstrapper.

    var standardResultProcesser = EventAggregator.HandlerResultProcessing;
    EventAggregator.HandlerResultProcessing = (target, result) =>
    {
        var stringResult = result as string;
        if (stringResult != null)
            MessageBox.Show(stringResult);
        else
            standardResultProcesser(target, result);
    };

Updated Wiki: The Event Aggregator

McDonnellDean — Sun, 12 May 2013 23:09:49 GMT

The Event Aggregator

Getting Started

    public interface IEventAggregator {
    	Action<Action> PublicationThreadMarshaller { get; set; }
    	bool HandlerExistsFor(Type messageType);
    	void Subscribe(object subscriber);
    	void Unsubscribe(object subscriber);
    	void Publish(object message);
    	void Publish(object message, Action<Action> marshal);
    }

Creation and Lifecycle

    // Creating the EventAggregator as a singleton.
    public class Bootstrapper : BootstrapperBase {
        private readonly SimpleContainer _container =
            new SimpleContainer();

         // ... Other Bootstrapper Config

        protected override void Configure(){
            _container.Singleton<IEventAggregator, EventAggregator>();
        }

        // ... Other Bootstrapper Config
    }

    // Acquiring the EventAggregator in a viewModel.
    public class FooViewModel {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
        }
    }

Publishing Events

    public class FooViewModel {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;

            _eventAggregator.Publish(new object());
            _eventAggregator.Publish("Hello World");
            _eventAggregator.Publish(22);
        }
    }

Publishing using a custom thread Marshal

    _eventAggregator.Publish(new object(), action => {
                    Task.Factory.StartNew(action);
                });

You can also swap out the default marshaller globally.

    _eventAggregator.PublicationThreadMarshaller = action => { action(); };

Subscribing To Events

    IHandle<TMessage> : IHandle {
	    void Handle<TMessage>(TMessage message);
    }

Notice that by implementing the interface above you are forced to implement the method Handle(T message) were T is the type of message you specified your interest in. This method is what will be called when a matching Event type is published.

    public class FooViewModel : IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message) {
            // Handle the message here.
        }
    }

Subscribing To Many Events

    public class FooViewModel : IHandle<string>, IHandle<bool> {
        private readonly IEventAggregator _eventAggregator;
    
        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }
    
        public void Handle(string message) {
            // Handle the message here.
        }

        public void Handle(bool message) {
            // Handle the message here.
        }
    }

Polymorphic Subscribers

Caliburn.Micro's EventAggregator honours polymorphic. When selecting handlers to call the EventAggregator will fire any handler who's Event type is assignable from the Event being sent. This results in a lot of flexibility and helps reuse.

    public class FooViewModel : IHandle<object>, IHandle<string> {
        private readonly IEventAggregator _eventAggregator;
    
        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
            _eventAggregator.Publish("Hello");
        }
    
        public void Handle(object message) {
            // This will be called
        }

        public void Handle(string message) {
            // This also
        }
    }

In the example above, because String is derived from System.Object both handlers will be called when a String message is published.

Querying Handlers

    public class FooViewModel : IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message){
            if (_eventAggregator.HandlerExistsFor(typeof(SpecialMessageEvent))){
                _eventAggregator.Publish(new SpecialEventMessage(message));
            }
        }
    }

Coroutine Aware Subscribers

    public interface IHandleWithCoroutine<TMessage> : IHandle {
		IEnumerable<IResult> Handle(TMessage message);
    }

The code below utilizes Coroutines with the EventAggregator. In this instance Activate will be fired asynchronously, Do work however, will not be called until after Activate has completed.

    public class FooViewModel : Screen, IHandleWithCoroutine<EventWithCoroutine> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public IEnumerable<IResult> Handle(EventWithCoroutine message) {
            yield return message.Activate();
            yield return message.DoWork();
        }
    }

    public class EventWithCoroutine {
        public IResult Activate() {
            return new TaskResult(Task.Factory.StartNew(() => {
                    // Activate logic
                }));
        }

        public IResult DoWork() {
            return new TaskResult(Task.Factory.StartNew(() => {
                // Do work logic
            }));
        }
    }

Task Aware Subscribers

    public interface IHandleWithTask<TMessage> : IHandle {
        Task Handle(TMessage message);
    }

Any subscribers that implement the above interface can then handle events in Task based manner.

    public class FooViewModel : Screen, IHandleWithTask<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public Task Handle(object message) {
            return Task.Factory.StartNew(() => message);
        }
    }

Unsubscribing and Leaks

    public class FooViewModel : Screen, IHandle<object> {
        private readonly IEventAggregator _eventAggregator;

        public FooViewModel(IEventAggregator eventAggregator) {
            _eventAggregator = eventAggregator;
            _eventAggregator.Subscribe(this);
        }

        public void Handle(object message) {
            // Handle the message here.
        }

        protected override void OnActivate() {
            _eventAggregator.Subscribe(this);
            base.OnActivate();
        }

        protected override void OnDeactivate(bool close) {
            _eventAggregator.Unsubscribe(this);
            base.OnDeactivate(close);
        }
    }

In the code above Screen is used to expose lifecycle events on the ViewModel. More on this can be found on this in the Screens, Conductors and Composition article on this wiki.

Custom Result Handling

    IHandleAndReturnString<T> : IHandle {
	    string Handle<T>(T message);
    }

Next we create our new result processor. This can be configured in the bootstrapper.

    var standardResultProcesser = EventAggregator.HandlerResultProcessing;
    EventAggregator.HandlerResultProcessing = (target, result) =>
    {
        var stringResult = result as string;
        if (stringResult != null)
            MessageBox.Show(stringResult);
        else
            standardResultProcesser(target, result);
    };

Updated Wiki: Documentation

McDonnellDean — Sun, 12 May 2013 11:57:00 GMT

Documentation

Getting Started

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- Working with Windows Phone 7 v1.0 v1.1
- Working with WinRT
  - WinRT Sharing with Caliburn Micro
  - WinRT Settings with Caliburn Micro
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
  - View/ViewModel Naming Conventions (v1.3)
  - Handling Custom Conventions (v1.3)
  - Using the NameTransformer - Advanced (v1.1)
- The Event Aggregator
- The Simple IoC Container
- The Window Manager
- Design-Time Support
- Async (Task) Support

External Tutorial

Recipes
- LoadCatalog Result
- Testing Coroutines

NOTE: Recipes are not maintained by the Caliburn.Micro project but by their contributors. Please contact the contributor with any issues you may find.

Contests
- 2010 Caliburn.Micro Application Contest Winners

3rd Party Extensions
- Telerik Integration (for SL 5.0 and WPF 4.0)
- DevExpress Integration (for WPF 4.0)
- ReactiveUI Integration (for SL 5.0, WPF 4.5 and WinRT)
- Bindable ApplicationBar (for WP 7.1 and WP 8.0)
- Some Extras (for all platforms)

NOTE: Please contact us if you want a project to be added to the list.

Updated Wiki: The Simple IoC Container

McDonnellDean — Sun, 12 May 2013 11:56:25 GMT

To Follow...

New Comment on "Cheat Sheet"

fffz — Thu, 09 May 2013 17:02:16 GMT

This project is awesome! but Can someone fill up the "Blanks" on the documentation, please?

Updated Wiki: Working with Windows Phone 7 v1.1

tibel — Fri, 26 Apr 2013 14:04:14 GMT

Working with Windows Phone 7 v1.1

In version 1.0 we had pretty good support for building apps for WP7, but in v1.1 we’ve taken things up a notch. Let’s look at the same HelloWP7 sample that we did previously, but see how it’s been updated to take advantage of our improved tombstoning, launcher/chooser support and strongly typed navigation. You’ll also notice that the code is cleaner overall.

Bootstrapper

Here’s the cleaned up boostrapper in v1.1.

public class HelloWP7Bootstrapper : PhoneBootstrapper {  
    PhoneContainer container;  
  
    protected override void Configure() {  
        container = new PhoneContainer(RootFrame);

        if (!Execute.InDesignMode)
            container.RegisterPhoneServices();

        container.PerRequest<MainPageViewModel>();  
        container.PerRequest<PivotPageViewModel>();  
        container.PerRequest<TabViewModel>();  
  
        AddCustomConventions();  
    }  
  
    static void AddCustomConventions() {  
        //ellided  
    }  
  
    protected override object GetInstance(Type service, string key) {  
        return container.GetInstance(service, key);  
    }  
  
    protected override IEnumerable<object> GetAllInstances(Type service) {  
        return container.GetAllInstances(service);  
    }  
  
    protected override void BuildUp(object instance) {  
        container.BuildUp(instance);  
    }  
}

There are two things to notice here. First, we’ve removed all the manual Caliburn.Micro service configuration and pushed it into the SimpleContainer. That gives you one line of code to configure the framework if you are using the OOTB container. Speaking of which, we now provide the SimpleContainer officially in the Caliburn.Micro.Extensions assembly. That helps you get started faster. You can always plug your own in, of coarse. In addition to the simplified configuration, notice that the ViewModels for pages are no longer registered using a string key. For v1.1 our ViewModelLocator has been re-implemented to pull VMs from the container by Type rather than key. It now follows the exact same naming strategies as the ViewLocator (but in reverse) and even derives possible interface names so that it resolves VMs from the container correctly. This both improves the consistency of ViewModel location as well as makes the configuration simpler.

The boostrapper is added to your App.xaml as always:

<Application x:Class="Caliburn.Micro.HelloWP7.App"  
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"  
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
             xmlns:local="clr-namespace:Caliburn.Micro.HelloWP7">  
    <Application.Resources>  
        <local:HelloWP7Bootstrapper x:Key="bootstrapper" />  
    </Application.Resources>  
</Application>

Important Note About App.xaml.cs

If you create your WP7 application using a standard Visual Studio template, the generated App.xaml.cs file will have a lot of code in it. The purpose of this code is to set up the root frame for the application and make sure everything gets initialized properly. Of course, that's what the bootstrapper's job is too (and in fact it does a few things better than the out-of-the-box code in addition to configuring CM). So, you don't need both. When using CM's PhoneBootstrapper, be sure to clear out all the code from the App.xaml.cs file except for the call to InitializeComponent in the constructor.

INavigationService

Let’s review what CM’s INavigationService does for you. First, remember that WP7 enforces a View-First approach to UI at the platform level. Like it or not, the platform is going to create pages at will and the Frame control is going to conduct your application thusly. You don’t get to control that and there are no extensibility points, unlike the Silverlight version of the navigation framework. Rather than fight this, I’m going to recommend embracing the View-First approach for Pages in WP7, but maintaining a Model-First composition strategy for the sub-components of those pages and a Model-First approach to coding against the navigation system. In order to bridge this gap, I’ve enabled the INavigationService to hook into the native navigation frame’s functionality and augment it with the following behaviors:

When Navigating To a Page

Use the new ViewModelLocator to conventionally determine the Type of the VM that should be attached to the page being navigated to. Pull that VM by Type out of the container.
If a VM is found, use the ViewModelBinder to connect the Page to the located ViewModel.
Examine the Page’s QueryString. Look for properties on the VM that match the QueryString parameters and inject them, performing the necessary type coercion.
If the ViewModel implements the IActivate interface, call its Activate method.

When Navigating Away From a Page

Detect whether the associated ViewModel implements the IGuardClose interface.
If IGuardClose is implemented and the app is not being tombstoned or closed, invoke the CanClose method and use its result to optionally cancel page navigation.1
If the ViewModel can close and implements the IDeactivate interface, call it’s Deactivate method. Always pass “false” to indicate that the VM should deactivate, but not necessarily close. This is because the phone may be deactivating, but not actually tombstoning or closing. There’s no way to know.

The behavior of the navigation service allows the correct VM to be hooked up to the page, allows that VM to be notified that it is being navigated to (IActivate), allows it to prevent navigation away from the current page (IGuardClose) and allows it to clean up after itself on navigation away, tombstoning or normal “closing” of the application (IDeactivate). All these interfaces (and a couple more) are implemented by the Screen class. If you prefer not to inherit from Screen, you can implement any of the interfaces individually of coarse. They provide a nice View-Model-Centric, testable and predictable way of responding to navigation without needing to wire up a ton of event handlers or write important application flow logic in the page’s code-behind.

These hooks into phone navigation enable a really smooth way of interacting with the phone’s navigation lifecycle. But now that we have an improved ViewModelLocator that matches exactly the ViewLocator and works on types, we can take things further. In v1.1 we’ve introduced support for strongly-typed navigation. Here’s what the new MainPageViewModel from the sample looks like using this new feature:

public class MainPageViewModel {  
    readonly INavigationService navigationService;  
  
    public MainPageViewModel(INavigationService navigationService) {  
        this.navigationService = navigationService;  
    }  
  
    public void GotoPageTwo() {  
        navigationService.UriFor<PivotPageViewModel>()  
            .WithParam(x => x.NumberOfTabs, 5)  
            .Navigate();  
    }  
}

This allows you to specify a ViewModel to navigate to along with the query string parameters. Since this all happens using generics and lambdas, you can never miss-type a page Uri or mess up your query strings….and refactoring will work beautifully.

For the sake of completeness, here’s the page that will be bound to MainPageViewModel:

<phone:PhoneApplicationPage x:Class="Caliburn.Micro.HelloWP7.MainPage"  
                            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"  
                            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
                            xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"  
                            xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"  
                            xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro"  
                            SupportedOrientations="Portrait"  
                            Orientation="Portrait"  
                            shell:SystemTray.IsVisible="True">  
    <Grid Background="Transparent">  
        <Grid.RowDefinitions>  
            <RowDefinition Height="Auto" />  
            <RowDefinition Height="*" />  
        </Grid.RowDefinitions>  
        <StackPanel Grid.Row="0"  
                    Margin="24,24,0,12">  
            <TextBlock Text="WP7 Caliburn.Micro"  
                       Style='{StaticResource PhoneTextNormalStyle}' />  
            <TextBlock Text='Main Page'  
                       Margin='-3,-8,0,0'  
                       Style='{StaticResource PhoneTextTitle1Style}' />  
        </StackPanel>  
  
        <Grid Grid.Row='1'>  
            <Button x:Name='GotoPageTwo'  
                    Content='Goto Page Two' />  
        </Grid>  
    </Grid>  
  
    <phone:PhoneApplicationPage.ApplicationBar>  
        <shell:ApplicationBar IsVisible='True'>  
            <shell:ApplicationBar.Buttons>  
                <cal:AppBarButton IconUri='ApplicationIcon.png'  
                                  Text='Page Two'  
                                  Message='GotoPageTwo' />  
            </shell:ApplicationBar.Buttons>  
        </shell:ApplicationBar>  
    </phone:PhoneApplicationPage.ApplicationBar>  
</phone:PhoneApplicationPage>

There’s really nothing new here in v1.1. But I just wanted to remind you that Caliburn.Micro supports Actions on the AppBar as long as you use CM’s AppBarButton and AppBarMenuItem :)

IPhoneService

The IPhoneService wraps the phone’s frame and provides access to important information and events. We had this service in v1.0 but we’ve expanded it in v1.1 to expose a better event model. Those familiar with WP7 know that the phone has a series of events that fire in different circumstances: Launching, Activated, Deactivated and Closing. Unfortunately, these events obscure whether the phone is actually resurrecting from a tombstoned state or simply continuing execution. The current SDK does not make it easy for the developer to actually determine this, so Caliburn.Micro does the heavy lifting for you and provides the following event model:

Launching - Occurs when a fresh instance of the application is launching.
Activated - Occurs when a previously paused/tombstoned app is resumed/resurrected.
Deactivated - Occurs when the application is being paused or tombstoned.
Closing - Occurs when the application is closing.
Continuing - Occurs when the app is continuing from a temporarily paused state.
Continued - Occurs after the app has continued from a temporarily paused state.
Resurrecting - Occurs when the app is "resurrecting" from a tombstoned state.
Resurrected - Occurs after the app has "resurrected" from a tombstoned state.

Using these new events, you can more intelligently make decisions about whether or not you need to restore data. In the forthcoming Mango release, the platform will provide us information on whether the app is continuing or resurrecting. However, developers working with Caliburn.Micro can have that information now and when Mango arrives, we’ll update our implementation to use the new bits. Your code won’t have to change.

Tombstoning

As you might imagine, our new tombstoning mechanism takes advantage of the new events so that it can more reliably and accurately save/restore important data. Let’s have a look at the PivotPageViewModel to see how it interacts with the tombstoning mechanism.

public class PivotPageViewModel : Conductor<IScreen>.Collection.OneActive {  
    readonly Func<TabViewModel> createTab;  
  
    public PivotPageViewModel(Func<TabViewModel> createTab) {  
        this.createTab = createTab;  
    }  
  
    public int NumberOfTabs { get; set; }  
  
    protected override void OnInitialize() {  
        Enumerable.Range(1, NumberOfTabs).Apply(x => {  
            var tab = createTab();  
            tab.DisplayName = "Item " + x;  
            Items.Add(tab);  
        });  
  
        ActivateItem(Items[0]);  
    }  
}

The PivotPageViewModel will receive the number of pivot items to create through it’s NumberOfTabs property, which is pushed in from the query string, as mentioned above. It will then add these items to the conductor and activate the first one. If you’re familiar with the Pivot and CM’s previous sample, you’ll notice that our PivotFix is gone. Pivot has a horrible bug that will crash your application if you try to set the SelectedItem or SelectedIndex to an item 3 or greater from either end of the pivot collection, while the Pivot itself is not visible. This makes it really hard to restore this control from a tombstoned state because you have to set the value at the exact right time. Previously we used a PivotFix hack to work around the control’s bug, but the new tombstoning mechanism is powerful and extensible enough to just make it work. You’ll notice that there are no attributes describing tombstoning behavior. They’ve been removed in favor of a poco model inspired by Fluent NHibhernate. If you would rather have the attributes, you can actually build them on top of the new system. The new system is also more reliable than previously and has a lot more options for storage. Let’s see the class that describes the tombstoning behavior for PivotPageViewModel:

public class PivotPageModelStorage : StorageHandler<PivotPageViewModel> {  
    public override void Configure() {  
        this.ActiveItemIndex()  
            .InPhoneState()  
            .RestoreAfterViewLoad();  
    }  
}

All you have to do to make a class participate in tombstoning is to inherit from StorageHandler<T>. The PhoneContainer will auto-register anything of this type in the assembly. Just override the Configure method and declare the tombstoning instructions. I’ve created some extension methods for common scenarios. Here’s what the above declaration states:

Persist the Conductor’s ActiveItem’s index
Store the index in PhoneState
Restore the value after the associated view has been loaded.

Let’s look at the storage handler for the TabViewModel to see some more options:

public class TabViewModelStorage : StorageHandler<TabViewModel> {  
    public override void Configure() {  
        Id(x => x.DisplayName);  
  
        Property(x => x.Text)  
            .InPhoneState()  
            .RestoreAfterActivation();  
    }  
}

Here we are specifying an Id because we actually need to persist multiple instances of the same VM. When we restore, we’ll need to know how to map the properties back. We’re also storing the data in PhoneState, but this time we’re not waiting for the view to load, but just waiting for the TabViewModel to be activated by its owning Conductor.

Out of the box, we also support storing data in AppSettings. For example, if you wanted to same tab to be selected across application restarts not just when tombstoned, you could define the PivotPageModelStorage like this:

public class PivotPageModelStorage : StorageHandler<PivotPageViewModel> {  
    public override void Configure() {  
        this.ActiveItemIndex()  
            .InAppSettings()  
            .RestoreAfterViewLoad();  
    }  
}

Pretty easy? All this works by collaborating with the IoC container and keying off of the new event model exposed by the IPhoneService. It’s pretty powerful and extensible. You can add your own storage mechanism or define your own restore timing. You can even implement IStorageHandler directly to write completely custom code on a class by class basis. You could easily add a version that inspected classes for custom attributes and built up the configuration, if you like the attribute model better. You can also store whole instances, not just their properties, and have them rehydrated properly and available for ctor injection.

Note About Restore Timing

If you want the data to be restored as soon as the object is created, leave off the timing specifier, ie. RestoreAfterViewLoad. The default is to restore the data immediately.

Launchers and Choosers

Launchers and Choosers are painful to work with if you want to do MVVM. In v1.0 we provided a solution to this. I wasn’t happy with its implementation…it was unpredictable in certain scenarios. Once we established the new phone events, better IoC integration and new tombstoning mechanism, I realized I could build a better launcher/chooser system. Let’s take a look at the updated version of TabViewModel in order to see how it works:

public class TabViewModel : Screen, IHandle<TaskCompleted<PhoneNumberResult>> {  
    string text;  
    readonly IEventAggregator events;  
  
    public TabViewModel(IEventAggregator events) {  
        this.events = events;  
    }  
  
    public string Text {  
        get { return text; }  
        set {  
            text = value;  
            NotifyOfPropertyChange(() => Text);  
        }  
    }  
  
    public void Choose() {  
        events.RequestTask<PhoneNumberChooserTask>();  
    }  
  
    public void Handle(TaskCompleted<PhoneNumberResult> message) {  
        MessageBox.Show("The result was " + message.Result.TaskResult, DisplayName, MessageBoxButton.OK);  
    }  
  
    protected override void OnActivate() {  
        events.Subscribe(this);  
        base.OnActivate();  
    }  
  
    protected override void OnDeactivate(bool close) {  
        events.Unsubscribe(this);  
        base.OnDeactivate(close);  
    }  
}

The most significant architectural change I made was to re-implement the launcher/chooser mechanism to work on top of the IEventAggregator. Take a look at the Choose method. The RequestTask method is just an extension method of the IEventAggregator that publishes a special event that the framework is subscribed to. The framework then starts the task. When it’s completed, the framework publishes an event TaskCompleted<T> where T is the result the the chooser returns. You can register for this in the same VM that published the chooser event or in an entirely different one if you like. In the case of our sample, we have 5 TabViewModels that can launch the same chooser. That’s probably not normal, but you can handle this situation in three ways. In our case, the VMs are in a Conductor, and only one of them can be active at a time, so we just Subscribe/Unsubscribe based on the Screen lifecycle so that only the active VM will receive the result. This is a version of the Latch pattern. The second way to handle this is through the event state. When you call the RequestTask method you can pass a state object which you can use for identification purposes later. Yes, this will be present even if the chooser causes a tombstone event. The final way is to have a single object that registers for the completed event, decoupling the launching from the completion. Thus multiple VM could launch the same chooser, but only one class would handle the result.

IWindowManager

The IWindowManager was actually in v1.0, as a last minute addition. It’s a really easy way to show native-looking, custom message boxes or modal dialogs. You can also use it to show popups. There is a whole topic devoted to this in the docs.

Referenced Samples

Caliburn.Micro.HelloWP7

Footnotes

Even though the IGuardClose interface was designed to handle async scenarios, you must use it synchronously in WP7. This is due to a flaw in the design of Silverlight Navigation Framework which doesn’t account for async shutdown scenarios.

New Comment on "Design-Time Support"

tianhonghui — Tue, 23 Apr 2013 15:28:31 GMT

very useful！

Updated Wiki: Documentation

EisenbergEffect — Tue, 23 Apr 2013 14:20:01 GMT

Documentation

Getting Started

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- Working with Windows Phone 7 v1.0 v1.1
- Working with WinRT
  - WinRT Sharing with Caliburn Micro
  - WinRT Settings with Caliburn Micro
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
  - View/ViewModel Naming Conventions (v1.3)
  - Handling Custom Conventions (v1.3)
  - Using the NameTransformer - Advanced (v1.1)
- The Event Aggregator
- The Window Manager
- Design-Time Support
- Async (Task) Support

External Tutorial

Recipes
- LoadCatalog Result
- Testing Coroutines

NOTE: Recipes are not maintained by the Caliburn.Micro project but by their contributors. Please contact the contributor with any issues you may find.

Contests
- 2010 Caliburn.Micro Application Contest Winners

3rd Party Extensions
- Telerik Integration (for SL 5.0 and WPF 4.0)
- DevExpress Integration (for WPF 4.0)
- ReactiveUI Integration (for SL 5.0, WPF 4.5 and WinRT)
- Bindable ApplicationBar (for WP 7.1 and WP 8.0)
- Some Extras (for all platforms)

NOTE: Please contact us if you want a project to be added to the list.

Updated Wiki: Documentation

tibel — Sat, 13 Apr 2013 19:40:21 GMT

Documentation

Getting Started

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- Working with Windows Phone 7 v1.0 v1.1
- Working with WinRT
  - WinRT Sharing with Caliburn Micro
  - WinRT Settings with Caliburn Micro
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
  - View/ViewModel Naming Conventions (v1.3)
  - Handling Custom Conventions (v1.3)
  - Using the NameTransformer - Advanced (v1.1)
- The Event Aggregator
- The Window Manager
- Design-Time Support
- Async (Task) Support

External Tutorial

Recipes
- LoadCatalog Result
- Testing Coroutines

NOTE: Recipes are not maintained by the Caliburn.Micro project but by their contributors. Please contact the contributor with any issues you may find.

Contests
- 2010 Caliburn.Micro Application Contest Winners

3rd Party Extensions
- Telerik Integration (for SL 5.0 and WPF 4.0)
- DevExpress Integration (for WPF 4.0)
- ReactiveUI Integration (for SL 5.0, WPF 4.5 and WinRT)
- Bindable ApplicationBar (for WP 7.1 and WP 8.0)
- Some Extras (for all platforms)

NOTE: Please contact us if you want a project to be added to the list.

Updated Wiki: Design-Time Support

tibel — Tue, 09 Apr 2013 17:35:50 GMT

Design-Time Support

Article forthcoming...

Enabling Caliburn.Micro inside the Visual Studio designer (or Blend) is quite easy.

You have to set a Desinger-DataContext and tell CM to enable its magic in your view XAML:

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:vm="clr-namespace:CaliburnDesignTimeData.ViewModels"
    xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro"
    mc:Ignorable="d" 
    d:DataContext="{d:DesignInstance Type=vm:MainPageViewModel, IsDesignTimeCreatable=True}"
    cal:Bind.AtDesignTime="True"

For this to work, the ViewModel must have a default constructor. If this isn't suitable, you can also use a ViewModelLocator for your design-time ViewModel creation.

NOTE: It seems that VS2010 has an issue in the WP7 designer and an exception in CM ConventionManager is thrown. You can workaround this by overriding ApplyValidation in your bootstrapper:

ConventionManager.ApplyValidation = (binding, viewModelType, property) => {
        if (typeof(INotifyDataErrorInfo).IsAssignableFrom(viewModelType)) {
            binding.ValidatesOnNotifyDataErrors = true;
            binding.ValidatesOnExceptions = true;
        }
    };

Updated Wiki: Documentation

tibel — Sun, 07 Apr 2013 20:14:12 GMT

Documentation

Getting Started

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- Working with Windows Phone 7 v1.0 v1.1
- Working with WinRT
  - WinRT Sharing with Caliburn Micro
  - WinRT Settings with Caliburn Micro
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
  - View/ViewModel Naming Conventions (v1.3)
  - Handling Custom Conventions (v1.3)
  - Using the NameTransformer - Advanced (v1.1)
- The Event Aggregator
- The Window Manager
- Design-Time Support
- Async (Task) Support

External Tutorial

Recipes
- LoadCatalog Result
- Testing Coroutines

NOTE: Recipes are not maintained by the Caliburn.Micro project but by their contributors. Please contact the contributor with any issues you may find.

Contests
- 2010 Caliburn.Micro Application Contest Winners

3rd Party Extensions
- Telerik Integration (for SL 5.0 and WPF 4.0)
- DevExpress Integration (for WPF 4.0)
- ReactiveUI Integration (for SL 5.0, WPF 4.5 and WinRT)
- Loading assemblies on-demand (for WP 7.1)
- Bindable ApplicationBar (for WP 7.1 and WP 8.0)

NOTE: Please contact us if you want a project to be added to the list.

Updated Wiki: Documentation

tibel — Sun, 07 Apr 2013 20:07:29 GMT

Documentation

Getting Started

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- Working with Windows Phone 7 v1.0 v1.1
- Working with WinRT
  - WinRT Sharing with Caliburn Micro
  - WinRT Settings with Caliburn Micro
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
  - View/ViewModel Naming Conventions (v1.3)
  - Handling Custom Conventions (v1.3)
  - Using the NameTransformer - Advanced (v1.1)
- The Event Aggregator
- The Window Manager
- Design-Time Support
- Async (Task) Support

External Tutorial

Recipes
- LoadCatalog Result
- Testing Coroutines

NOTE: Recipes are not maintained by the Caliburn.Micro project but by their contributors. Please contact the contributor with any issues you may find.

Contests
- 2010 Caliburn.Micro Application Contest Winners

3rd Party Extensions
- Telerik Integration (for SL 5.0 and WPF 4.0)
- DevExpress Integration (for WPF 4.0)
- ReactiveUI Integration (for SL 5.0, WPF 4.5 and WinRT)
- Loading assemblies on-demand (for WP 7.1)
- Caliburn Bindable AppBar (for WP 7.1 and WP 8.0)

NOTE: Please contact us if you want a project to be added to the list.

Updated Wiki: Async (Task) Support

tibel — Sat, 06 Apr 2013 11:50:39 GMT

Async (Task) Support

Article forthcoming...

NOTE: Task's are not supported on SL4 and WP71.

Updated Wiki: Design-Time Support

tibel — Sat, 06 Apr 2013 11:48:47 GMT

Design-Time Support

Article forthcoming...

Updated Wiki: Design-Time Support

tibel — Sat, 06 Apr 2013 11:48:20 GMT

Design-Time Support

Article forthcoming...

Updated Wiki: Documentation

tibel — Sat, 06 Apr 2013 11:47:15 GMT

Documentation

Getting Started

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- Working with Windows Phone 7 v1.0 v1.1
- Working with WinRT
  - WinRT Sharing with Caliburn Micro
  - WinRT Settings with Caliburn Micro
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
  - View/ViewModel Naming Conventions (v1.3)
  - Handling Custom Conventions (v1.3)
  - Using the NameTransformer - Advanced (v1.1)
- The Event Aggregator
- The Window Manager
- Design-Time Support
- Async (Task) Support

External Tutorial

Recipes
- LoadCatalog Result
- Testing Coroutines

NOTE: Recipes are not maintained by the Caliburn.Micro project but by their contributors. Please contact the contributor with any issues you may find.

Contests
- 2010 Caliburn.Micro Application Contest Winners

3rd Party Extensions
- Telerik Integration
- DevExpress Integration
- Callisto Helpers (for WinRT)
- CMContrib Extensions
- Loading assemblies on-demand (for WP7)
- Caliburn Bindable AppBar (for WP7 and WP8)

NOTE: Please contact us if you want a project to be added to the list.