Initial Version

We are creating the first version of our application and decide that we need a User database table with the following columns: Name (primary key), LastAccessedDate

So we create a User class as follows:

[Table]
public class User : INotifyPropertyChanged, INotifyPropertyChanging
{
  private string name;
  private DateTime? lastAccessed;

  [Column(IsPrimaryKey = true, CanBeNull = false, AutoSync = AutoSync.OnInsert)]
  public string Name
  {
  get { return name; }
  set
    {
      NotifyPropertyChanging("Name");
      name = value;
      NotifyPropertyChanged("Name");
    }
  }

  [Column]
  public DateTime? LastAccessed
  {
    get { return lastAccessed; }
    set
    {
      NotifyPropertyChanging("LastAccessed");
      lastAccessed = value;
      NotifyPropertyChanged("LastAccessed");
    }
  }

  // Version column aids update performance.
  [Column(IsVersion = true)]
  private Binary version;

  // INotifyPropertyChanged Members
  // INotifyPropertyChanging Members
}

In App.xaml.cs, you would use the following code to create your database:

using (MyDataContext db = new MyDataContext(DBConnectionString))
{
  // Create the database if it does not exist.
  if (db.DatabaseExists() == false)
  {
    // Create the local database.
    db.CreateDatabase();
  }
}

That is all the code that is needed for the first version as there are no update scenarios. You deploy your app to the Marketplace and hundreds of customers download it. We will call this group of people that downloaded it: Group A.

It is important to note that when a database is created for the first time (unless specific) it has a DatabaseSchemaVersion of 0.

Version 2

Let’s say that for the next version of your app, you need to change the table schema for User to add a Theme id as now your app lets the user choose which theme to use.

This requires an update to the User class:

//added in DB_VERSION 2
[Column(CanBeNull = true)]
public int? ThemeId

This column must allow nulls so that it can be added to existing rows in User table.

The code is App.xaml.cs will need to change to take into account two scenarios:

· Those in Group A upgrading from the first release to version 2
· Those downloading the app for the first time at version 2 (we will refer to them as Group B)

At the top of App.xaml.cs, add a DB_VERSION field to keep track of the current version of the database changes:

private static int DB_VERSION = 2;

The replace the previous code as follows:

using (MyDataContext db = new MyDataContext(DBConnectionString))
{
  if (db.DatabaseExists() == false)
  {
    db.CreateDatabase();
    DatabaseSchemaUpdater dbUpdater = db.CreateDatabaseSchemaUpdater();
    dbUpdater.DatabaseSchemaVersion = DB_VERSION;
    dbUpdater.Execute();
  }
  else
  {
    DatabaseSchemaUpdater dbUpdater = db.CreateDatabaseSchemaUpdater();

    if (dbUpdater.DatabaseSchemaVersion < DB_VERSION)
    {
      if (dbUpdater.DatabaseSchemaVersion < 2)
      {
        //added in version 2
        dbUpdater.AddColumn<User>("ThemeId");
      }

    dbUpdater.DatabaseSchemaVersion = DB_VERSION;
    dbUpdater.Execute();
    }
  }
}

We release this new version of the app to the Marketplace and those in Group A update their application. When they run it for the first time, they will fall into the else statement as the database already exists. The DatabaseSchemaVersion will be 0 which is less than our current version of 2, so it will go into the code that will add the ThemeId column to the existing User table. The DatabaseSchemaVersion will then be updated to 2 so that the update code will no longer run.

Now let’s look at Group B who are downloading the app for the first time when it was at version 2. For them, no database will exist so one will be created. It is important to point out that when the database is created it will include the ThemeId column on User since it is part of the User object. The DatabaseSchemaVersion is now updated so that on the next run of the app when the code hits the else block it will not try to add the column again and throw an exception.

Version 3

Let’s do a third version of the application and add a birthdate column to User:

//added in DB_VERSION 3
[Column(CanBeNull = true)]
public DateTime? DOB

In App.xaml.cs, change the version to 3:

private static int DB_VERSION = 3;

Now add a new if block for the new column:

using (MyDataContext db = new MyDataContext(DBConnectionString))
{
  if (db.DatabaseExists() == false)
  {
    db.CreateDatabase();
    DatabaseSchemaUpdater dbUpdater = db.CreateDatabaseSchemaUpdater();
    dbUpdater.DatabaseSchemaVersion = DB_VERSION;
    dbUpdater.Execute();
  }
  else
  {
    DatabaseSchemaUpdater dbUpdater = db.CreateDatabaseSchemaUpdater();
    if (dbUpdater.DatabaseSchemaVersion < DB_VERSION)
    {
      if (dbUpdater.DatabaseSchemaVersion < 2)
      {
        //added in version 2
        dbUpdater.AddColumn<User>("ThemeId");
      }

      if (dbUpdater.DatabaseSchemaVersion < 3)
      {
        //added in version 3
        dbUpdater.AddColumn<User>("DOB");
      }

      dbUpdater.DatabaseSchemaVersion = DB_VERSION;
      dbUpdater.Execute();
    }
  }
}

The above code now correctly handles the following scenarios:

· Those installing version 3 of the app as the first version they installed (new database will be created)
· Those with version 2 that are updating to version 3 (upgrade from previous version)
· Those at version 1 that didn’t update to version 2 but are now updating to version 3 (skip intermediate versions)

It should be easy to see how additional versions will require an increment to the DB_VERSION value and the addition of an if block to handle those changes added in a specific version.

To copy from the emulator’s isolated storage to your computer’s file system use:

ISETool.exe ts xd 11111111-2222-3333-4444-555555555555 “C:\MyApp\DbVersion1″

Where:

• ts – take snapshot
• xd – emulator
• guid – product GUID from WPAppManifest.xml
• desktop dir – where to copy the isolated storage files

To later copy those files from my desktop directory back to isolated storage on the emulator, use:

ISETool.exe rs xd 11111111-2222-3333-4444-555555555555 “C:\MyApp\DbVersion1\IsolatedStore”

In this case rs means restore snapshot.

But the restoring wasn’t working for me.  I would restore the snapshot, run my code and no database would be found so my code would create a new database.  It took me a few times to notice that what I was doing wrong was reusing the take snapshot command line and changing ts to rs.

But the problem with that is that the directory that you specify with ts is different than the one needed for rs.  Notice that rs adds “\IsolatedStore” to the end.

Hopefully this will save you from pulling  a few hairs out.

Learn what the future holds for Silverlight at this online event.

Register today: http://www.silverlight.net/news/events/firestarter/

The below screenshots were taken from the keynote video and you can see the timings at the bottom if you want to watch the video:

In addition to debugging on the device, you can profile the app by selecting Silverlight Performance Analysis:

The device will then be prepared for profiling:

After running the application, a graphical summary will be created with execution time on the x-axis.  It shows color-coded frame rates (green is good, red is bad) and relates that to CPU-usage and specific Storyboards:

In the above example, it appears that the first Storyboard might be leading to increased CPU usage and a degraded frame rate.  You can highlight and drill down to see details for a specific time frame (from approx 4.5 to 7.5 seconds into the profiling session):

The next screen shows CPU and GPU metrics as well as a list of warnings.  The first entry warns about 35 instances of ColorAnimation:

Scrolling down, you will see an Element Summary:

Followed by a Frames section with a CPU usage graph:

And finally the ability to drill down the Visual Tree and see problems highlighted:

This tool would be very helpful in analyzing app performance on the device.  ScottGu did not give a specific release date for this or any additional tools that might be coming.

Today I saw that there is a Silverlight Firestarter event scheduled for December 2, 2010 and wonder if the tool will be ready to release then. 

It would make a great time to announce it.

Extension to Caliburn.Micro to allow implementation of filters similar to what is found in Caliburn.

A Caliburn.Micro recipe: filters « Marco Amendola

Here is a link to the documentation topics:

• Getting Started
  • Introduction
  • Obtain and Build the Code

• Soup to Nuts
  • Basic Configuration, Actions and Conventions
  • Customizing The Bootstrapper
  • All About Actions
  • WP7 Basics
  • Coroutines

• Recipes
  • SimpleContainer

I know Rob has been working on some WP7 goodness that should be out soon.  Looking forward to the release.

When you run the application, you will see the XamWebOutlookBar hosted in a sidebar.  Both groups shown in the OutlookBar have corresponding ViewModels that in turn have associated Views:

At the end of the article is a link to the project source code.  In order to get the project to compile, you will need to download the Infragistics assemblies and add references to the following:

A trial of Infragistics can be downloaded from here.

Here is the final project structure:

Application

In typical Caliburn style, the App.xaml has been changed to a CaliburnApplication:

<cal:CaliburnApplication xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
             xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
             xmlns:cal="clr-namespace:Caliburn.PresentationFramework.ApplicationModel;assembly=Caliburn.PresentationFramework"
             x:Class="InfragisticsCaliburn.App">
    <Application.Resources>
    </Application.Resources>
</cal:CaliburnApplication>

In App.xaml.cs, we setup MEF as the container and the use MEF to find the ShellViewModel:

protected override IServiceLocator CreateContainer()
{
    return new MEFAdapter(CompositionHost.Initialize(new AssemblyCatalog(Assembly.GetExecutingAssembly())));
}

protected override object CreateRootModel()
{
    var shell = ServiceLocator.Current.GetInstance<IShell>();

    if (IsRunningOutOfBrowser && HasElevatedPermissions)
        MainWindow.Closing += (s, args) => { args.Cancel = !ServiceLocator.Current.GetInstance<IShell>().CanShutdown(); };

    return shell;
}

ViewModels

MEF is able to find ShellViewModel in the container using the IShell type because it implements IShell and Exports itself as IShell:

[Export(typeof(IShell))]
public class ShellViewModel : ScreenConductor<IScreen>, IShell
{
    private readonly MainViewModel _firstScreen;

    [ImportingConstructor]
    public ShellViewModel(MainViewModel firstScreen)
    {
        _firstScreen = firstScreen;
    }

    protected override void OnInitialize()
    {
        this.OpenScreen(_firstScreen);
    }

}

Because of the ImportingConstructor attribute, an instance of MainViewModel is created.  The class is implemented as:

[Export(typeof(MainViewModel))]
public class MainViewModel : ScreenConductor<ISidebarItem>.WithCollection.OneScreenActive
{
    [ImportingConstructor]
    public MainViewModel([ImportMany] IEnumerable<ISidebarItem> sidebars)
    {
        Screens.AddRange(sidebars);
        this.OpenScreen(Screens.First());
    }
}

For the XamWebOutlookBar implementation, the important thing to note is that MainViewModel is setup as a ScreenConductor that manages ISidebarItem instances where only one sidebar screen is active at a time.  The ImportingConstructor attribute then finds all items registered in the MEF container as ISidebarItem.

In this example, both ContentAViewAModel and ContentBViewModel are similar:

[Export(typeof(ISidebarItem))]
public class ContentAViewModel : Screen, ISidebarItem
{
    string message = "ContentA is working";

    public ContentAViewModel()
    {
        DisplayName = "Content A Header";
    }

    public string Message
    {
        get { return message; }
        set
        {
            message = value;
            NotifyOfPropertyChange(() => Message);
        }
    }

    public string Icon
    {
        get { return @"../../Images/briefcase2.png"; }
    }
}

Each of the ViewModels export themselves as ISidebarItem, inherit from Screen, and implement ISidebarItem.

Views

In MainView.xaml, the DisplayName and Icon properties are used to render the group’s header and icon:

<igOB:XamWebOutlookBar x:Name="sidebarOutlookBar" 
        MinimizedWidth="35" AllowMinimized="True" 
        NavigationPaneMinimized="sidebarOutlookBar_NavigationPaneMinimized"
        NavigationPaneExpanding="sidebarOutlookBar_NavigationPaneExpanding"
        VerticalAlignment="Stretch" HorizontalAlignment="Stretch"
        GroupsSource="{Binding Screens}">
    <igOB:XamWebOutlookBar.GroupContentTemplate>
        <DataTemplate>
            <ContentControl cal:View.Model="{Binding}" />
        </DataTemplate>
    </igOB:XamWebOutlookBar.GroupContentTemplate>
    <igOB:XamWebOutlookBar.GroupHeaderTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding DisplayName}" />
        </DataTemplate>
    </igOB:XamWebOutlookBar.GroupHeaderTemplate>
    <igOB:XamWebOutlookBar.DefaultLargeIconTemplate>
        <DataTemplate>
            <Image Source="{Binding Icon, Converter={StaticResource stringToImageSourceConverter}}"/>
        </DataTemplate>
    </igOB:XamWebOutlookBar.DefaultLargeIconTemplate>
    <igOB:XamWebOutlookBar.DefaultSmallIconTemplate>
        <DataTemplate>
            <Image Source="{Binding Icon, Converter={StaticResource stringToImageSourceConverter}}"/>
        </DataTemplate>
    </igOB:XamWebOutlookBar.DefaultSmallIconTemplate>
</igOB:XamWebOutlookBar>

Notice the GroupsSource property is bound to the Screens property that the ViewModel inherits from its base class.  The ContentControl for each group is set to the ViewModel representing the group.  The group header is bound to the DisplayName property and the small and large icons are set to the Icon property.

The Message property is bound in the View for the group content:

<UserControl x:Class="InfragisticsCaliburn.Views.ContentAView"
    xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
    xmlns:xhttp://schemas.microsoft.com/winfx/2006/xaml
    xmlns:d=http://schemas.microsoft.com/expression/blend/2008
    xmlns:mc=http://schemas.openxmlformats.org/markup-compatibility/2006
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    <Grid x:Name="LayoutRoot" Background="White">
        <TextBlock x:Name ="Message"/>
    </Grid>
</UserControl>

Download the source of the project here.

You can download the book from here.

The first chapter is a simple introduction to Caliburn.  Chapter 2 walks you through a simple, Hello Caliburn, application.  Chapter 3 is more ambitious and walks you through various aspects of the framework using the Silverlight GameLibrary sample.  It covers the same topics that Rob Eisenberg covered in his MIX10 talk.  There is also an Appendix included that lists some of the conventions found in Caliburn.

If I decide to write additional chapters, then I would include:

• Adding to Conventions
• Overriding Conventions
• TDD and Caliburn
• Caliburn extensibility points
• IResult implementations
• Coroutines in more depth
• UI patterns besides MVVM

There is likely much more to Caliburn that I don’t even know what I don’t know yet.

Please reply with any feedback, corrections, further explanations, or additional chapter ideas.

If a book is ever published about Caliburn, Rob should be the one to do it.

The code consists of two phone projects.  If you run the first, you will get the application UI. Running the second will bring up the test viewer.

Get the code here.

NOTE:

I told those attending the session that a video of the presentation would be available.  But due to an issue with Camtasia Studio, the video was not recorded.

Thanks again to all those who attended the presentation.  Let me know about the COOL apps you write for WP7.

Ninject

To start off, I downloaded the .NET Framework 3.5 release of Ninject assembly and then reference that as I recompile the Ninject.Web.MVC assembly for .NET 4. Then I created a new ASP.NET MVC 2 project and reference those assemblies:

Next I modified the MvcApplication class in Global.asax.cs to inherit from NinjectHttpApplication and use the OnApplicationStarted and CreateKernal overrides to wire Ninject

public class MvcApplication : NinjectHttpApplication
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapRoute(
            "Default", // Route name
            "{controller}/{action}/{id}", // URL with parameters
            new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
        );

    }

    protected override void OnApplicationStarted()
    {
        AreaRegistration.RegisterAllAreas();
        RegisterRoutes(RouteTable.Routes);

        RegisterAllControllersIn(Assembly.GetExecutingAssembly());
    }

    protected override IKernel CreateKernel()
    {
        var modules = new INinjectModule[]
            {
                new WebModule()
            };

        return new StandardKernel(modules);
    }

 

To associate an interface to an implementation, I create a WebModule class that inherits from NinjectModule:

public class WebModule : NinjectModule
{
    public override void Load()
    {
        Bind<IHelloService>()
            .To<HelloService>();
    }
}

 

The service and interface are very basic:

public interface IHelloService
{
    string GetMessage();
}

public class HelloService : IHelloService
{
    public string GetMessage()
    {
        return "Hello there.";
    }
}

 

Since the Controllers are now wired to use items bound in the module, we can use the interface as a parameter to the constructor or set a property using the [Inject] attribute:

Constructor Injection

public class HomeController : Controller
{
    public IHelloService HelloService { get; set; }

    //Constructor injection
    public HomeController(IHelloService service)
    {
        this.HelloService = service;
    }

    public ActionResult Index()
    {
        ViewData["Message"] = HelloService.GetMessage();

        return View();
    }
}

 

Property Injection

public class HomeController : Controller
{
    //Property injection
    [Inject]
    public IHelloService HelloService { get; set; }

    public ActionResult Index()
    {
        ViewData["Message"] = HelloService.GetMessage();

        return View();
    }
}

So, how would we accomplish the same thing in MEF?

MEF

To make the comparison easier, I created MefHttpApplication and MefControllerFactory classes.

First, add a reference to System.ComponentModel.Composition as that is where MEF lives:

To get similar functionality that Ninject has in its NinjectHttpApplication, I created a MefHttpApplication:

public abstract class MefHttpApplication : HttpApplication
{
    public void Application_Start()
    {
        var catalog = CreateCatalog();
        var container = new CompositionContainer(catalog);

        ControllerBuilder.Current.SetControllerFactory(new MefControllerFactory(container));

        OnApplicationStarted();
    }

    protected virtual void OnApplicationStarted() {}

    protected abstract ComposablePartCatalog CreateCatalog();
}

When the application starts, the derived class gets the specify catalog used to gather composition information. The MefHttpApplication then creates a CompositionContainer based on that catalog, overrides MVC’s default ControllerFactory, and provides an OnApplicationStarted method for the derived class:

public class MvcApplication : MefHttpApplication
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapRoute(
            "Default", // Route name
            "{controller}/{action}/{id}", // URL with parameters
            new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
        );

    }

    protected override void OnApplicationStarted()
    {
        AreaRegistration.RegisterAllAreas();
        RegisterRoutes(RouteTable.Routes);
    }

    protected override ComposablePartCatalog CreateCatalog()
    {
        return new AssemblyCatalog(Assembly.GetExecutingAssembly());
    }
}

Comparing this to the NinjectHttpApplication-derived class, there is no need to register the controllers separately or to create a WebModule to define the mapping between IHelloService and HelloService.  This will be accomplished in a different way.  By creating an AssemblyCatalog for the currently executing assembly, all classes will be scanned to see if there are any Exports to register.  In our case, we have one Export on the HelloService:

public interface IHelloService
{
    string GetMessage();
}

[Export(typeof(IHelloService))]
public class HelloService : IHelloService
{
    public string GetMessage()
    {
        return "Hello there.";
    }
}

In MEF, we need to remember the triad: Export, Import, Compose.  We already have our Export and the corresponding Import can be found in the Controller on the HelloService property:

public class HomeController : Controller
{
     [Import]
     public IHelloService HelloService { get; set; }

     public ActionResult Index()
     {
         ViewData["Message"] = HelloService.GetMessage();

         return View();
     }

     public ActionResult About()
     {
         return View();
     }
}

 

It is also possible to import via a constructor parameter by decorating the constructor with the ImportingConstructor attribute but this would require more work in the MefControllerFactory class:

public class MefControllerFactory : DefaultControllerFactory
{
    private CompositionContainer container;

    public MefControllerFactory(CompositionContainer container)
    {
        this.container = container;
    }

    public override IController CreateController(System.Web.Routing.RequestContext requestContext, string controllerName)
    {
        IController controller = base.CreateController(requestContext, controllerName);

        container.ComposeParts(controller);

        return controller;
    }
}

In the MefHttpApplication we replaced the default ControllerFactory with the MefControllerFactory which is derived from DefaultControllerFactory.  Every time MVC creates a new Controller, it goes through this class which simply calls base to create the Controller.  Just before returning the Controller, the container.ComposeParts method is called passing in the controller which allows any Imports defined in the Controller to be satisfied by any Exports found in the catalog.  All three steps of composition have been completed.

So Which Should I Use?

As always, that depends on your specific situation.  If all you need is injection into your controllers, then Ninject is simple way to get that done.  If you don’t want to rely on a 3rd-party solution, don’t mind creating your own HttpApplication and ControllerFactory classes, or you want to use MEF in other scenarios then MEF might be a better choice.  One example is to use MEF to define a Controller in a separate plug-in.

In this example, we compared MEF to Ninject, but a similar comparison could be done for Unity, StructureMap, Castle Windor, or other.