Using MEF in Metro-style applications

Update 23 Aug 2012:

Since I originally wrote this post the standard .Net framework MEF implementation is no longer accessible from Windows 8 Windows Store applications. Instead MEF support is released out-of-band on NuGet as a specific "MEF for web and Windows Store apps" package. Once you have added this to your Windows 8 projects there is a slightly different programming model. For more information see the Microsoft.Compostion documentation.

In brief, you can set up composition with,

var configuration = new ContainerConfiguration()
        .WithAssembly(typeof(App).GetTypeInfo().Assembly);

var compositionHost = configuration.CreateContainer();
compositionHost.SatisfyImports(this);

Original post follows,  

In a slight change from talking about the Cocoon framework, today I’m going to discuss how you may use MEF (the Managed Extensibility Framework) in Windows 8 Metro-style applications. Hopefully the reason for this deviation will become clear in my next post.

What Is MEF?

I’m not going to explain MEF in detail as this has been discussed many times before and is described on MSDN. Succinctly, taken directly from the MEF CodePlex page,

The Managed Extensibility Framework (MEF) is a composition layer for .NET that improves the flexibility, maintainability and testability of large applications. MEF can be used for third-party plugin extensibility, or it can bring the benefits of a loosely-coupled plugin-like architecture to regular applications.

For Windows 8 Metro-style app developers it is the loosely-coupled architecture that is of most interest (since third-party extensibility will not be applicable to application packages delivered through the Windows Store). This allows the individual components of your application to be designed, written and tested separately. The instantiation, lifetimes and connections between components is then managed by MEF at runtime.

Using MEF in Windows 8 Metro-Style Applications

The good news is that MEF is included in the .Net base class libraries as part of the Metro-style application profile so is included in-the-box for all such applications. Unfortunately if you look at the documentation you will see references to ‘Assembly.GetExecutingAssembly()’ that is not available in the Metro-profile,

// Does not work in Metro-style applications

var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly());

All is not lost however, as you can access the main application assembly using,

// This does work in Metro-style applications!

var catalog = new AssemblyCatalog(typeof(App).GetTypeInfo().Assembly);

Note that since GetTypeInfo() is an extension method on 'Type' you will have to add "using System.Reflection;" to the top of your source file. You can also reference other assemblies simply by picking a type contained in that assembly and replacing ‘App’ in the above snippet.

Therefore a more complete snippet that would find and compose all imports in the current class is,

var catalog = new AssemblyCatalog(typeof(App).GetTypeInfo().Assembly);

var compositionService = catalog.CreateCompositionService();

compositionService.SatisfyImportsOnce(this);

Summary

Hopefully this post will help anybody trying to integrate MEF with their Windows 8 Metro-style app development. Ultimately there is an ‘ApplicationCatalog’ that should allow you to generate a catalog from all assemblies within the app package however there is a known bug in the Consumer Preview bits.

Using the Cocoon Data Framework

Over the last series of posts I have discussed the Cocoon data framework. This aims to simplify the retrieval and display of data sets within Windows 8 Metro style applications. In particular it assists with pulling data from remote systems via typical page-based web APIs and displaying them as continuous lists.
The posts so far have covered,

• Introductory post
• SimpleDataListSource (for APIs that return all items from a single call)
• PagedDataListSource (for APIs that return data in a paged format)
• VirtualizingDataList (for data binding to display the data)

The Cocoon Sample Application

Included with the Cocoon source code (available from Codeplex) is a sample application that demonstrates there principles. This application is a simple Flickr viewer that displays the current list of “interesting” photos according to the Flickr API. Note that to compile this application you will need to register for a Flickr API key here and place this in the ‘FLICKR_API_KEY’ constant within the ‘Data/FlickrApi.cs’ file.
In this application the FlickrApi class provides basic access to the Flickr API with a single method GetInterestingPhotos() [Note: This is for demonstration purposes only and is not designed to demonstrate good practice for creating a web API client]

namespace Cocoon.Sample.Data

{

    public partial class FlickrApi

    {

        // *** IMPORTANT : YOU MUST ENTER YOUR API KEY BELOW! ***

        public const string FLICKR_API_KEY = "ENTER YOUR FLICKR API KEY HERE";

        public async Task<FlickrPhotoPage> GetInterestingPhotos(int page, int perPage)

        {

            ...

        }

    }

}

You will notice that this retrieves data in a paged manner, passing in the page to return as an argument and returning a FlickrPhotoPage as a result. Note also that since this is an asynchronous method call the result is returned as a Task. In the UI however we have a single scrollable list of photos, so we will use the Cocoon data framework to link these together.

Creating a New DataListSource

It is recommended that when you are using the Cocoon data framework you expose the IDataListSource implementations though a data source singleton class. Since data list sources can perform some caching of the data this allows several pages of your application to use the same underlying source. In the sample application this it the FlickrDataSource class.

namespace Cocoon.Sample.Data

{

    public class FlickrDataSource

    {

        // *** Fields ***

        private FlickrApi flickrApi = new FlickrApi();

        private IList<FlickrPhoto> interestingPhotos;

        // *** Methods ***

        public IList<FlickrPhoto> GetInterestingPhotos()

        {

            // Create a single instance of the interesting photos list

            // This can then be shared between multiple view models

            if (interestingPhotos == null)

            {

                InterestingPhotosDataListSource dataListSource = new InterestingPhotosDataListSource(flickrApi);

                interestingPhotos = (IList<FlickrPhoto>)new VirtualizingDataList<FlickrPhoto>(dataListSource);

            }

            return interestingPhotos;

        }

    }

}

Here we simply create an instance of our FlickrApi class along with a lazily generated InterestingPhotosDataListSource object. Whilst you can expose this to your rest of your application as is, here we also create a VirtualizingDataList<FlickrPhoto> passing the data list source into the constructor. Since this implements IList<FlickrPhoto> we can data bind to this in our UI.
The most interesting part of this is the InterestingPhotosDataListSource class – this is the class that you will need to write for each of the lists of data you wish to expose through the Cocoon data framework. As we have already discussed the Flickr API exposes the interesting photos feed as a series of pages, therefore we will derive from PagedDataListSource<FlickrPhoto>.
The three methods that we need to implement are FetchCountAsync, FetchPageSizeAsync and FetchPageAsync. Often however, as in this case, you will find that the number of items and page size are returned as part of the API call for returning the first page. Hence we only need to write an implementation of FetchPageAsync and use this to write the other two methods.

namespace Cocoon.Sample.Data

{

    public class InterestingPhotosDataListSource : PagedDataListSource<FlickrPhoto>

    {

        // *** Fields ***

        private FlickrApi flickrApi;

        // *** Constructors ***

        public InterestingPhotosDataListSource(FlickrApi flickrApi)

        {

            this.flickrApi = flickrApi;

        }

        // *** Overriden Base Methods ***

        protected override Task<DataListPageResult<FlickrPhoto>> FetchCountAsync()

        {

            return FetchPageAsync(1);

        }

        protected override Task<DataListPageResult<FlickrPhoto>> FetchPageSizeAsync()

        {

            return FetchPageAsync(1);

        }

        protected async override Task<DataListPageResult<FlickrPhoto>> FetchPageAsync(int pageNumber)

        {

            FlickrPhotoPage flickrPage = await flickrApi.GetInterestingPhotos(pageNumber, 20);

            return new DataListPageResult<FlickrPhoto>(flickrPage.Total, flickrPage.PerPage, flickrPage.Page, flickrPage.Photos);

        }

    }

}

In the FetchPageAsync(…) method we directly call the FlickrAPI.GetInterestingPhotos method (using the new C# async support). The result is then returned as a DataListPageResut<T> with the total number of items, the number of items per page, the page number returned, and a list of the items within that page.

Data Binding to the Data List

Since in this sample application we are using the MVVM pattern the user interface is split into two parts, the ‘InterestingPhotosPage.xaml’ and the ‘InterestingPhotosViewModel.cs’. In the view model we simple call FlickrDataSource.GetInterestingPhotos method that we wrote earlier and expose this IList<FlickrPhoto> as a property of the view model.

this.InterestingPhotos = flickrDataSource.GetInterestingPhotos();

And in the XAML we bind to this property as you would any other collection,

<CollectionViewSource

            x:Name="itemsViewSource"

            Source="{Binding InterestingPhotos}"/>

Summary

I hope that I have shown above a brief insight into the power of the Cocoon data framework. We started by writing a simple “data list source” implementation describing how to access data from a paged web UI. The framework then allows you to easily expose this as a list that can be data bound to a UI, with support for virtualization and ISupportPlaceholder for free.

VirtualizingDataList – Displaying Large Datasets

In the last few posts I have introduced a number of features from the data framework included as part of the open-source Cocoon framework for Windows 8 Metro-style apps. Following an introduction to the framework I described the SimpleDataListSource and PagedDataListSource.
To recap, the IDataListSource implementations provide a simple way of accessing data from web APIs. These have been designed to reflect the typical structure of such APIs, generally resulting from a series of stateless HTTP requests to retrieve the data, often a page at a time.
In response to data provided from an IDataListSource, the DataList implementations are designed to request and display the information to the user. The aim here is to provide the user experience expected for a client application, with large scrolling lists of items and suitable support for background on-demand data retrieval.

Introducing The VirtualizingDataList

The first DataList implementation provided in the Cocoon data framework is the VirtualizingDataList<T> class. This can be used for situations where a large scrolling list only displays a small subset of the data at any one time. Only the data in view will be retrieved, with more data being fetched on-demand as the user scrolls through this list. In addition it supports the WinRT ISupportPlaceholder interface to indicate to the displaying UI to display a placeholder element whilst data is being retrieved in the background. This builds on top of Cocoon’s VirtualizingVector class so more information on data virtualization and placeholder support can be found in the associated post.
To use a VirtualizingDataList<T> you simply create a new instance, passing the IDataListSource via its constructor. It can then be bound to any of the many controls for displaying lists of information, most commonly the GridView and ListView controls.
If you are following the MVVM presentation pattern then you will expose the data list via a view model,

public class MyViewModel

{

    // *** Fields ***

    private IList<Person> employees;

    // *** Constructors ***

    public MyViewModel()

    {

        IDataListSource<Person> source = new EmployeesDataListSource();

        employees = new VirtualizingDataList<Person>(source);

    }

    // *** Properties ***

    public IList<Person> Employees

    {

        get

        {

            return employees;

        }

    }

}

Then in your XAML you can define a CollectionViewSource that binds to the data list, and connect that to your items control,

<UserControl.Resources>

    <CollectionViewSource x:Name="itemsViewSource" Source="{Binding Employees}"/>

</UserControl.Resources>

...

<GridView ItemsSource="{Binding Source={StaticResource itemsViewSource}}" ... />

In fact, this is exactly what the Visual Studio 11 Metro-style XAML templates will produce for you.

Summary

In the above discussing I have shown how easy it is to consume any IDataListSource and display it to the user through the fluid scrollable user experience expected of modern applications. When I introduced the Cocoon data framework I discussed “bridging the data divide” between the stateless HTTP calls of web APIs and the continuous scrollable lists displayed to the user. By coding the former as IDataListSource implementations, and the latter as DataLists, Cocoon provides the bridge to span these two worlds.

As usual the code is freely available for download from the Cocoon CodePlex site (to get the latest version go to the “Source Code” tab, select the first change set and use the “Download” link).

Notes

Please note that due to a known issue with the Visual Studio templates in the Consumer Preview (see this forum post) they disable virtualization support for the GridView. Therefore although the VirtualizingVector and VirtualizingDataList classes will still work, they unfortunately fetch all items in the collection rather than on demand. To re-enable the virtualization support you can remove the ScrollViewer that surrounds the GridView, however this will clip elements a little strangely. Hopefully this will be resolved in the final release of Visual Studio, although I am working on a temporary workaround.

Update: Cocoon for Windows Consumer Preview

Following the release of the Windows 8 Consumer preview I would like to announce that the Cocoon framework for Windows 8 Metro-style applications has been updated to support the new bits. As usual the full source code is available for download from the Cocoon CodePlex site (to get the latest version go to the “Source Code” tab, select the first change set and use the “Download” link).

The changes include,

• Code and project system migrated to the Visual Studio 11 Consumer Preview
• Virtualization support converted to use the new ISupportPlaceholder interface rather than IVirtualizingVector
• The VirtualizingVector class is now VirtualizingVector<T> for type-safe access
• Improvements to the internal resource management
• General tidying up of the codebase

Please note that due to a known issue with the Visual Studio templates in the Consumer Preview (see this forum post) they disable virtualization support for the GridView. Therefore although the VirtualizingVector and VirtualizingDataList classes will still work, they unfortunately fetch all items in the collection rather than on demand. To re-enable the virtualization support you can remove the ScrollViewer that surrounds the GridView, however this will clip elements a little strangely. Hopefully this will be resolved in the final release of Visual Studio, although I am working on a temporary workaround.

PagedDataListSource – Consuming Data From Common Web APIs

This is my third post in a series discussing the data framework that is included as part of the open-source Cocoon framework. Previously I have introduced the framework, and detailed the SimpleDataListSource base implementation.

In this post I will describe the more advanced PagedDataListSource base implementation included as part of the framework. This is designed to allow simple integration of data that is retrieved from web APIs as a series of pages. This is a common approach to enable access to large data sets in an efficient manner. In general there will be some way to retrieve the number of items in the data set, and a way to retrieve a single ‘page’ of data (often these can be combined in a single API call).

Consider for example a hypothetical web call,

http://www.example.com/api/getEmployees?page=1

This might return the following XML response,

<PersonResult TotalCount="450" Page="1" PageSize="50">

    <Person Name="Bob"/>

    <Person Name="Dave"/>

    <Person Name="Amy"/>

    ...

</PersonResult>

We can immediately see that there are a total of 450 employees, however the API returns only the first 50 entries. To retrieve subsequent employees you make the same call with the relevant ‘page’ query parameter.

From the point of view of a modern Windows 8 Metro style application, the user does not want to see separate pages of data. Instead they expect a continuous scrolling grid of items, with subsequent data retrieved on demand as it is required to be displayed. It is this mismatch between the paging web API and the desired UI that the PagedDataListSource and the Cocoon data framework sets out to address.

Implementing A PagedDataListSource

The PagedDataListSource<T> class in marked as abstract so you must derive a domain specific custom class for the type of data that you wish to retrieve. There are then three methods that you should override,

• FetchCountAsync – This should retrieve the number of items in the data set


• FetchPageSizeAsync – This should return the number of items per page


• FetchPageAsync – This should return the items for a specified page

Note that each of these returns a Task<DataListPageResult<T>> as their response. DataListPageResult<T> is defined as,

public struct DataListPageResult<T>

{

    // *** Constructors ***

    public DataListPageResult(int? totalItemCount, int? itemsPerPage,

                              int? pageNumber, IList<T> page)

        : this()

    {

        this.TotalItemCount = totalItemCount;

        this.ItemsPerPage = itemsPerPage;

        this.PageNumber = pageNumber;

        this.Page = page;

    }

    // *** Properties ***

    public int? TotalItemCount { get; private set; }

    public int? ItemsPerPage { get; private set;}

    public int? PageNumber { get; private set; }

    public IList<T> Page { get; private set; }

}

This contains all the data that could be returned from any of the above methods. Whilst the requested information must always be present (e.g. a call to FetchCountAsync() must always return a ‘TotalItemCount’) any of the other values may be ‘null’ if they are not known.

The reason for this approach is that in many cases several of these items are returned from a single web API call – for example in the ‘getEmployees’ example above an initial call to GetFetchAsync() will not only return the number of items, but also the page size and the contents of the first page. Hence the implementation can often write FetchCountAsync() and FetchPageSizeAsync() as a simple call to FetchPageAsync(…).

So for our hypothetical ‘getEmployees’ web call we could write,

public class EmployeesDataListSource : PagedDataListSource<Person>

{

    // *** Overriden Base Methods ***

    protected override Task<DataListPageResult<Person>>
                           FetchCountAsync()

    {

        return FetchPageAsync(1);

    }

    protected override Task<DataListPageResult<Person>>
                           FetchPageSizeAsync()

    {

        return FetchPageAsync(1);

    }

    protected async override Task<DataListPageResult<Person>>
                                 FetchPageAsync(int pageNumber)

    {

        PersonResult result = await ExampleEmployeesApi.
                                         GetEmployees(pageNumber);

        return new DataListPageResult<FlickrPhoto>
                      (result.TotalCount, result.PageSize,
                       result.Page, result.Items);

    }

}

The Cocoon framework will then ensure that the correct pages are retrieved as required and that each web API call is only made once, with the results cached for future use.

Summary

Here I have discussed the PagedDataListSource<T> implementation of the Cocoon data framework. As usual the code is freely available for download from the Cocoon CodePlex site (to get the latest version go to the “Source Code” tab, select the first change set and use the “Download” link).

Next time I will show how you link these IDataListSource implementations with a DataList that can then be bound to your Windows 8 Metro style app’s UI. Following this I will show an end-to-end sample of how to the data framework to access a real web API and display it to the end user (Note: If you are really eager, the sample application is available from the latest code drop on the Cocoon CodePlex site).

SimpleDataListSource – Consuming Data From Simple Services

In my last post I introduced the data framework exposed as part of the Cocoon framework project. Whilst the same principles could be applied to any presentation layer, this framework is designed from the ground up to work great with Windows 8 Metro applications written in managed .Net languages. This includes support for several of the advanced features of WinRT based UIs, such as data virtualization (which I discussed in this post).

As I discussed, Cocoon splits the passing of data from a data source into the UI with two parts. The DataListSource (represented by the IDataListSource<T> interface) describes how the data is retrieved and maps well onto the typical web service API calls to do so. At the other end of the pipeline is the DataList whose responsibility it is to determine when to retrieve the data and to present it in a format that is easily bound to the UI.

Whilst this system is designed to be easily extensible, there are a number of typical use-cases that are provided out of the box with the Cocoon framework. In this post I will describe the SimpleDataListSource.

The SimpleDataListSource Class

The SimpleDataListSource<T>, as its name suggests, is an implementation of the IDataListSource<T> interface for use with simple web APIs that return all items in a list with a single API call.

As an example consider the Flickr API method flickr.photos.people.getList that returns all the people that are tagged in a given photo. Since the number of people is likely to be relatively small the API simply takes a photo ID and returns all the people in one go, and is an ideal candidate for the SimpleDataListSource<T>. This is in contrast to a method such as flickr.interestingness.getList that returns all the interesting photos for the current day. In this case they may be many hundred items so the Flickr API splits these into several pages that are returned one at a time.

In code form we could consider this as,

public class FlickrApi

{

    public Task<IList<PeopleTag>> GetPeopleInPhoto(string photoId)

    {

        ...

    }

    public Task<IList<Photo>> GetInterestingPhotos(int page)

    {

        ...

    }

}

Implementing A Simple Data Source

Since SimpleDataSource<T> is an abstract class you must first derive a custom class for a specific data type. The only method you then are required to implement is the FetchItemsAsync() method that will initiate the call to the web API to retrieve all the items.

For our Flickr photo tagging example,

public class TaggedPeopleDataListSource : SimpleDataSource<PeopleTag>

{

    // *** Fields ***

    private FlickrApi flickrApi;

    private string photoId;

    // *** Constructors ***

    public TaggedPeopleDataListSource(string photoId, FlickrApi flickrApi)

    {

        this.flickrApi = flickrApi;

        this.photoId = photoId;

    }

    // *** Overriden Methods ***

    protected override Task<IList<PeopleTag>> FetchItemsAsync()

    {

        return flickrApi.GetPeopleInPhoto(string photoId);

    }

}

Here we firstly derive from ‘SimpleDataListSource<PeopleTag>’ (since every item in the list is of type ‘PeopleTag’). In the constructor we take the photo ID to retrieve the tagged people, and a reference to the ‘FlickrApi’ implementation. In the FetchItemsAsync() method we simply call the API method and return the result.

The underlying SimpleDataListSource<T> implementation will ensure that the web API is only called once, and will cache the results in memory for future use.

As usual the code is freely available for download from the Cocoon CodePlex site (to get the latest version go to the “Source Code” tab, select the first change set and use the “Download” link).

Next Time

Whilst simple scenarios such as those supported by the SimpleDataListSource are relatively basic to implement without the support provided by the Cocoon framework, many web APIs return paged results that are much more difficult to consume. For a fast and responsive UI these should be retrieved asynchronously and on demand as the user scrolls through a long list of items.

Next time I will introduce the PagedDataListSource that allows you to support this with minimal code. After that I will introduce the final piece in the puzzle – the DataList that can be connected to any of these DataListSources for binding to the UI. Finally I will describe a simple end-to-end example of how to use the data framework to bind to a real web service.

Bridging the Data Divide–An Introduction to Cocoon Data Lists

When I first introduced the Cocoon framework one of the targets was to improve the ease at which data retrieval APIs (primarily web APIs) could be integrated into modern desktop applications. In this post I will introduce two concepts, the “data list” and the “data list source”, that are used in the Cocoon framework to simplify this process when writing Windows 8 Metro-style applications, in particular those implementing the MVVM design pattern.

The Data Divide

Let us first consider a typical web API that will return a list of information in response to a web request from a desktop application. In many cases there may be a large number of items in the list, so the API will split the results into several “pages”. For example, the hypothetical web call,

public Task<PersonResult> GetEmployeesAsync(int pageNumber) {...}

Might return the resulting data for pageNumber=1,

<PersonResult TotalCount="450" Page="1" PageSize="50">

    <Person Name="Bob"/>

    <Person Name="Dave"/>

    <Person Name="Amy"/>

    ...

</PersonResult>

Here, whilst there are a total of 450 items in the data set, only the first 50 are returned. If you then require any further items then additional calls must be made for the second, third, etc. pages as required.

In contrast let us consider a modern Windows 8 Metro-style UI. Here the user generally expects to see a single list of all items that can be scrolled through as desired. For performance reasons this list should take advantage of data virtualisation to retrieve data on demand, filling in the UI smoothly as the results are retrieved (see my last post on VirtualizingVector for more information).

It is this “data divide” between the state-less paged result sets of web APIs and the fluid continuous lists of desktop applications that often require much code to implement correctly. This is the problem that “data lists” and “data list sources” in the Cocoon framework are desired to solve.

“Data Lists” and “Data List Sources”

The approach taken by the Cocoon framework is to separate the two concerns of the web API calls (or any other data access call) and the resulting lists to display in the UI into separate components. These can then be developed separately using their own conventions, with the Cocoon framework bridging the divide.

In this model a web API call (or calls) that return information on a list of information is represented as part of a “data list source”. This understands how to query the source API to retrieve the list of data as required. In addition it is your application’s own representation of what it knows about the list of data – the length of the data set, and any items that have already been downloaded. This can be reused amongst different parts of your application and in some ways acts as a local cache of the data. Multiple data list sources will be available, for simple cases where all data is returned at once and for data that is returned by pages, as well as the option for custom implementations.

At the other end of the chain is the “data list”. This is the IList<T> implementation that is bound to the UI, either via the code behind or through a view model. Multiple data lists can be attached to the same data list source so that the application’s view of the data is consistent. Different data list implementations can determine how the data is retrieved for display; for example,

• StaticDataList – This will retrieve all the information before display to the user
• VirtualizingDataList – This will use data virtualization to only retrieve the data items that are currently visible to the user
• IncrementalLoadingDataList – This will initially show a fixed number of items, but allow the user to expand the list if they wish to see more items
• DynamicDataList – This will start with an empty list, with items being added as they are retrieved from the data list source

Between the data list and the data list source are a number of optional processing steps. For example these could constrain the list to only the first 50 items for preview, they could filter the items based on a search term, or could group the items to display as part of a grouped grid view.

The IDataListSource Interface

All of the above is orchestrated by the Cocoon.Data.IDataListSource<T> interface.

public interface IDataListSource<T>

{

    Task<int> GetCountAsync();

    Task<T> GetItemAsync(int index);

}

You can think of this as an asynchronous version of IList<T>, albeit a minimal version. There are two methods:

• GetCountAsync() – Returns a task that results in the number of items in the list.


• GetItemAsync(int index) – Returns a task that results in the item at the specified index.

Note that the GetItemAsync(…) method should throw an exception if ‘index’ is less than zero, however if ‘index’ is greater than the last item it should return default(T) (for reference types this will be null).

Summary

To summarize, the Cocoon framework supplies an infrastructure designed to bridge the gap between state-less web APIs and modern fluid Windows 8 Metro style applications. Over the next few blog posts (and associated code drops) I will provide a number of generic implementations of data lists and data list sources to make consuming lists of data from the web quick and easy.