In April, I was in the UK for speaking at the VBUG conference and I was impressed
by a demo given by Josh Twist. He built using MEF and WPF a “marketplace” application.
The goal of the application was mainly showing the dynamic capabilities of adding
new functionality to an application through MEF (or in full, the Managed Extensibility
Framework for Silverlight 4).
For a presentation I’m giving shortly, I rebuilt something similar but in Silverlight:
the MEF Marketplace in Silverlight. The setup is the following: a user gets an overview
of apps he purchased in the market place and can run these on demand. The market place
app will download the applications available to the user after the application has
started, so this app mainly is a hosting shell for the other ‘purchased” applications
to run in. Of course, the sample is a demo and can be extended quite a lot. For example,
in the current implementation, I hard-coded the list of purchased apps and there’s
no option to buy new ones. Also, it could be extended so that when new apps are purchased,
a duplex service notifies the client of this and MEF downloads the new app in the
background.
But, instead of talking of what could be added, let’s take a look at what I currently
built already! Here’s a screenshot of the application showing the "purchased” applications.
And here’s one of the apps (the Flickr Image search) running inside the "market place
shell”.
Time for some code. Let’s begin with the market place itself.
I defined a contract interface for all applications that can be loaded in the market
place, IMarketPlaceApplication.
public interface IMarketPlaceApplication
{
string ApplicationName
{ get; }
FrameworkElement MarketPlaceIcon { get; }
FrameworkElement MainView { get; }
}
This interface defines that all my apps will (of course) have a name, a default view
which will load as the landing screen when the app is loaded (MainView.xaml) and an
icon to show in the list (MarketPlaceIcon.xaml). As these 2 latest ones are XAML files,
you can put in whatever you like.
A very easy application that will be possible to load from MEF is the HelloWorldApplication.
The project structure of this app is as follows:
As you can see, there’s a class called HelloWorldApplication, which implements the
IMarketPlaceApplication and 2 xaml files. The HelloWorldApplication code is shown
below:
[Export(typeof(IMarketPlaceApplication))]
public class HelloWorldApplication:
IMarketPlaceApplication
{
#region IMarketPlaceApplication
Members
public string ApplicationName
{
get { return "Hello
MEF world"; }
}
[Import(typeof(Icon))]
public FrameworkElement
MarketPlaceIcon
{
get;
set;
}
[Import(typeof(HelloWorldView))]
public FrameworkElement
MainView
{
get;
set;
}
#endregion
}
This is our first encounter with MEF. The first line uses the Export attribute. This
class is saying that it is available for someone to use, when someone requests an
instance of IMarketPlaceApplication. A bit further, we are using the Import attribute
on both the MarketPlaceIcon and the MainView. Here we are saying: MEF, search us a
class that’s exporting itself as type Icon and HelloWorldView respectively.
These 2 latter instances will be inserted by MEF upon executing the application, that
is, if MEF finds the corresponding export. These exports can be found in the 2 XAML
files (in the code-behind). The HelloWorldView.xaml.cs code is shown next. Note the
Export attribute: we’re telling to MEF that this type can be used where an Import
is requested of the HelloWorldView type.
[Export]
public partial class HelloWorldView
: UserControl
{
public HelloWorldView()
{
InitializeComponent();
}
}
The Icon.xaml.cs is pretty similar code-behind-wise (I think I invented that term
here): here alse we are adding an Export attribute.
[Export]
public partial class Icon
: UserControl
{
public Icon()
{
InitializeComponent();
}
}
The HelloWorldApplication is at this point a stand-alone application (it compiles
to its own XAP file), but we’ll now build the Market Place shell that will host this
app. The code download at the end of the article contains several sample applications
(a Flickr app and a Facebook app).
Similar to a real market place application, our implementation will get a list of
apps you purchased previously. Only these are available to you and will be shown.
To get this list, I wrote a basic Silverlight-enabled WCF service that fetches this
list of available applications. This service is hosted in this case in the hosting
website. The code below shows this service, which in this case returns a hard-coded
list of apps (note that I have some more apps already added here).
[ServiceContract(Namespace = "")]
[AspNetCompatibilityRequirements(RequirementsMode =
AspNetCompatibilityRequirementsMode.Allowed)]
public class MarketPlaceService
{
[OperationContract]
public List<MefApplication>
GetAvailableApplicationsForUser()
{
return new List<MefApplication>()
{
new MefApplication(){ApplicationName="Flickr
Image Search",
XapFileName="FlickImageSearch.xap"},
new MefApplication(){ApplicationName="Hello
World",
XapFileName="HelloWorldApplication.xap"},
new MefApplication(){ApplicationName="MEFacebook",
XapFileName="FacebookApplication.xap"}
};
}
//
Add more operations here and mark them with [OperationContract]
}
[DataContract]
public class MefApplication
{
[DataMember]
public string ApplicationName
{ get; set; }
[DataMember]
public string XapFileName
{ get; set; }
}
The service uses the MefApplication class as a helper class: it contains the name
of the application and more importantly, the name of the XAP file (this could easily
be replaced with a Uri to the XAP file).
In the MefMarketPlace, the Silverlight Market Place application, we can create a web
reference to this service. In the App.xaml.cs, I add a call to a new method, DownloadMyApplicationList():
private void Application_Startup(object sender,
StartupEventArgs e)
{
DownloadMyApplicationsList();
this.RootVisual
= new MainPage();
}
This new method makes the service call to get a list of available XAPs that I can
use (apps that I purchased).
void DownloadMyApplicationsList()
{
AggregateCatalog = new AggregateCatalog();
container = new CompositionContainer(this.AggregateCatalog);
CompositionHost.Initialize(container);
MarketPlaceService.MarketPlaceServiceClient client =
new MarketPlaceService.MarketPlaceServiceClient();
client.GetAvailableApplicationsForUserCompleted +=
new EventHandler<MarketPlaceService.GetAvailableApplicationsForUserCompletedEventArgs>
(client_GetAvailableApplicationsForUserCompleted);
client.GetAvailableApplicationsForUserAsync();
}
void client_GetAvailableApplicationsForUserCompleted(object sender,
MarketPlaceService.GetAvailableApplicationsForUserCompletedEventArgs e)
{
if (e.Error
== null)
{
AvailableApplicationsForUser = e.Result;
InitializeCatalog();
}
}
In the callback method of the service, I call InitializeCatalog(). MEF has the concept
of Catalogs: a Catalog can be used to tell MEF where it has to look for Parts. Several
types of catalogs exist in MEF for Silverlight: the TypeCatalog, the AssemblyCatalog,
the DeploymentCatalog and the AggregateCatalog. A TypeCatalog basically allows us
to register a specific type with MEF: if I want MEF to know about a certain Export,
I can register it in a TypeCatalog. An AssemblyCatalog tells MEF to look for parts
in a specific assembly. The DeploymentCatalog allows us to specify a XAP file and
MEF will look in the assemblies therein for parts. It also allows us to asynchronously
download a XAP file. An AggregateCatalog can contain any number of other catalogs
and more catalogs can be added at any time.
By default, if we don’t specify a Catalog for our application, MEF looks at the current
XAP file and for each assembly it finds, it creates an AssemblyCatalog. It then combines
these with an AggregateCatalog. That means that we can omit creating a catalog in
our application: in this case, MEF will create a default one for us, with something
similar to this code:
void InitializeCatalog()
{
AggregateCatalog catalog = new AggregateCatalog();
foreach (var
deployedPart in Deployment.Current.Parts)
{
StreamResourceInfo resourceInfo =
Application.GetResourceStream(new Uri(deployedPart.Source,
UriKind.Relative));
Assembly assembly = deployedPart.Load(resourceInfo.Stream);
catalog.Catalogs.Add(new AssemblyCatalog(assembly));
}
CompositionHost.Initialize(catalog);
}
Back to our application. If we look at the available catalogs in MEF, we can see that
the DeploymentCatalog is a good candidate for what we need: we can use it to download
a XAP file (the application that we want to load). After that, we can add each DeploymentCatalog
to an AggregateCatalog. MEF will then make these available in our application and
we can run the downloaded applications.
In code, this gives the following:
private CompositionContainer
container;
void InitializeCatalog()
{
foreach (var
item in AvailableApplicationsForUser)
{
DeploymentCatalog deploymentCatalog =
new DeploymentCatalog(item.XapFileName);
this.AggregateCatalog.Catalogs.Add(deploymentCatalog);
deploymentCatalog.DownloadCompleted += (s, e) =>
{
//extend
to give meaningful error handling
if (e.Error
!= null)
MessageBox.Show(e.Error.Message);
};
deploymentCatalog.DownloadAsync();
}
container.ComposeParts(this);
}
You can see that I use a CompositionContainer here. The container is well, like the
word says it, a container where MEF puts all the parts, shakes it up and creates/composes
parts.
We now have the code that runs when we start the application: it gets a list of all
the applications we can use over the service and then it downloads the XAP files of
these apps asynchronously. Each XAP file is downloaded using a DeploymentCatalog and
these are added to an AggregateCatalog. This now makes our downloaded applications
available to run.
Let’s now take a look at the UI where we’ll run the apps from. The following screenshot
shows the UI:
The “Load my apps'” button on the top right will execute a command on the viewmodel
that will load all available applications in the ListBox on the left.
When clicking on the “Load app” button, the selected application (here the Flickr
app) is loaded:
Clicking the “Home” button unloads the app and returns us to the list screen.
The complete XAML listing can be found in the code download. The most important part
is shown below. Note that there’s a ContentPresenter used here and it’s bound to the
MainView property of the SelectedApplication. The latter is a property exposed on
the viewmodel (see further). If no view/app is selected, this ContentPresenter won’t
be visible and we’ll see the default UI again.
<Grid x:Name="LayoutRoot" Background="Black">
<Grid.RowDefinitions>
<RowDefinition Height="*"></RowDefinition>
<RowDefinition Height="60"></RowDefinition>
</Grid.RowDefinitions>
<Grid>
...
</Grid>
<ContentPresenter Content="{Binding
SelectedApplication.MainView}">
</ContentPresenter>
<Button Grid.Row="1" Content="Home" Margin="10" Background="#FFABE3FF"
Command="{Binding
HomeCommand}" BorderBrush="#FF00AAFF"
Style="{StaticResource
ButtonStyle1}"
Width="130" Height="40" HorizontalAlignment="Center"
VerticalAlignment="Center"></Button>
</Grid>
Time to look at the viewmodel now. Probably the most important part here is the ObservableCollection<IMarketPlaceApplication>:
[ImportMany(AllowRecomposition=true)]
public ObservableCollection<IMarketPlaceApplication>
Applications
{
get
{
return _applications;
}
}
The ListBox in the UI is bound to this collection and since it’s an ObservableCollection,
the UI will reflect changes to this collection. That’s important here, since the list
of available apps won’t be known after the shell contacted the service. Note that
the collection property is attributed with the ImportMany attribute. This is a sign
for MEF that more than one part that is exposing itself with the same Export attribute
(same type) is allowed. By default, this isn’t allowed since MEF wouldn’t know which
one to use. Here, we want the ImportMany since we know that more than one app will
be available and they all need to be exported as an IMarketPlaceApplication. Another
important thing to note here is the AllowRecomposition option we used here. AllowRecomposition
tells MEF that if during the run of the app more Exports become available for this
Import, it’s OK to add them, in other words, to rebuild the composition.
The ContentPresenter in the UI bound to SelectedApplication.MainView. The SelectedApplication
property is shown next.
private IMarketPlaceApplication
_selectedApplication;
public IMarketPlaceApplication
SelectedApplication
{
get
{
return _selectedApplication;
}
set
{
_selectedApplication = value;
NotifyPropertyChanged("SelectedApplication");
}
}
NotifyPropertyChanged is a simple method that raises the PropertyChanged event of
the INotifyPropertyChanged interface.
private void NotifyPropertyChanged(string p)
{
if (PropertyChanged
!= null)
{
PropertyChanged(this, new PropertyChangedEventArgs(p));
}
}
The “Load apps” button in the UI is bound to the LoadAppsCommand. I use the MVVM Light
RelayCommand here. In the execute code of the ICommand, I ask MEF to satisfy the Imports
of the current class (the viewmodel). This basically tells MEF to look at the catalogs
and bring all the Export(typeof(IMarketPlaceApplication)) into the ImportMany.
public RelayCommand
LoadAppsCommand
{
get
{
if (_loadAppsCommand
== null)
{
_loadAppsCommand = new RelayCommand(
() =>
{
CompositionInitializer.SatisfyImports(this);
loaded = true;
},
() =>
{
if (loaded)
return false;
return true;
}
);
}
return _loadAppsCommand;
}
}
The LoadSelectedApplicationCommand and the HomeCommand respectively set the SelectedApplication
property to the selected application in the list or null.
public RelayCommand<IMarketPlaceApplication>
LoadSelectedAppCommand
{
get
{
if (_loadSelectedAppCommand
== null)
{
_loadSelectedAppCommand = new RelayCommand<IMarketPlaceApplication>(
(a) =>
{
SelectedApplication = a;
}
);
}
return _loadSelectedAppCommand;
}
}
public RelayCommand
HomeCommand
{
get
{
if (_homeCommand
== null)
{
_homeCommand = new RelayCommand(
() =>
{
SelectedApplication = null;
}
);
}
return _homeCommand;
}
}
With that, we have successfully implemented the MEF Marketplace. As said in the very
beginning, this can be extended quite a lot. Add a duplex service and a buying system
that pushes a message to the client and trigger the client to download the linked
XAP file is a nice way to start. The complete file can be downloaded below.
Enjoy!
Code download: MefMarketPlace.zip
(868.99 KB)
Snowball.be - The blog of Gill Cleeren
Click here to see the original post
RSS
