Bnaya Eshet : WPF

Rx - for beginners (part 11): ObserveOn

bnaya — Mon, 29 Mar 2010 15:19:49 GMT

Rx - for beginners (part 11): ObserveOn

this post is the 11th in a series of posts about the new Reactive Framework (Rx).

the series TOC can found here.

in this post we will focus on the ObserveOn…

the code sample for this post can be found here.

sometime it is important that the observation will occurs on specific thread.

for example GUI application like (WinForm, WPF and Silverlight) throw exception whenever

UI component accessed on thread different than its creation thread.

ObserveOn instruct the producer (observable) to call the consumer (observer) on specific thread.

having the following Xaml:

Code Snippet
 <Window x:Class="ObserveOnSample.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <TextBlock x:Name="_txt" Text="Not set"/>
    </Grid>
</Window>
 

if we want to change the Text property of the text box, we mast do it on the Dispatcher thread.

doing it we have to add the ObserveOnDispather, as shown in the next snippet (line 8):

Code Snippet
 public partial class Window1:Window
{
    public Window1()
    {
        InitializeComponent();
 
        var timeStream = Observable.Interval(TimeSpan.FromSeconds(1));
        var timeStreamDispather = timeStream.ObserveOnDispatcher();
        timeStreamDispather.Subscribe(value => _txt.Text = value.ToString());
    }
}
 

the sample create interval producer (observable) on line 7.

then it ensure that observation will occurs at the dispatcher thread (line 8).

and subscribe to the synchronized producer (observable) on line 9.

Summary

you can use Rx to synchronize your operation to the right thread.

the code sample for this post can be found here.

recommending VS 2010 XAML IntelliSense Extension

bnaya — Fri, 26 Mar 2010 18:12:38 GMT

recommending VS 2010 XAML IntelliSense Extension

a pal named Karl had published a very useful plug-in to VS 2010.

this plug-in is making Xaml writing so much better experience with enhanced IntelliSense.

if you doing some Xaml work using VS 2010 you should consider to download this plug-in.

the download is available from the following link:

http://karlshifflett.wordpress.com/2010/03/21/visual-studio-2010-xaml-editor-intellisense-presenter-extension/#comment-2228

Features

Pascal case lookup
Optional narrowing list filter
Filtering based on item type
xmlns IntelliSense options
- Show/hide only solution assemblies
- Show/hide schemas
Filter settings persist for the current Visual Studio session

MEF for Beginner (Import from Xaml) - part 11

bnaya — Sat, 20 Mar 2010 21:28:23 GMT

MEF for Beginner (Import from Xaml) - part 11

this is the 11th post of the MEF for Beginner series, the series TOC is available here.

this post will focus on Importing mef parts directly from the Xaml.

the code sample for this post is available here.

assuming that we have the following exports:

Code Snippet
 class DemoStrings
{
    [Export("MyTag")]
    public string Text1 { get { return "Hello world"; } }
    [Export("MyTag")]
    public string Text2 { get { return "export using custom attribute"; } }
    [Export("NotMyTag")]
    public string Text3 { get { return "not included (Not My Tag contract)"; } }
    [Export("MyTag")]
    public string Text4 { get { return "Wpf markup extension"; } }
    [Export]
    public string Text5 { get { return "not included (have no contract)"; } }
}
 

we may want to have it import into the Xaml as follow:

Code Snippet
 <Window x:Class="Bnaya.Samples.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:mef="clr-namespace:Bnaya.Samples"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <ListBox
                 DataContext="{mef:ImportManyStrings MyTag}" 
                 ItemsSource="{Binding}"/>
    </Grid>
</Window>
 

as you can see at line 8 the data context is using special definition for importing all exported strings that
define the their contract as MyTag (looking at the exports it will import the exports at lines 4,6,10).

what should we have in order to achieve that functionality?

actually very little, all we have to do is to define a markup extension that return the exported parts.

the following code is how the markup extension should be define:

Code Snippet
 [MarkupExtensionReturnType(typeof(IEnumerable<string>))]
public class ImportManyStringsExtension : MarkupExtension
{
    private readonly IEnumerable<string> _dataSource;
    public ImportManyStringsExtension(string contract)
    {
        _dataSource = CompositionHost.Provider.GetExportedValues<string>(contract);
    }
 
    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        return _dataSource;
    }   
}
 

line 1, decorate that our markup extension for returning IEnumerable<string>.

line 2, derive from MarkupExtension.

line 7, at the construction time, dynamically ask mef for any discoverable parts that follow the contract.

the CompositionHost is a very small helper class that was taken from the MEF Silverlight implementation

with some very minor enhancements.

lines 10-13, returning the discoverable parts to the Xaml.

One last thing

we should remove the StartupUri from the App.Xaml and using the OnStartup override instead:

Code Snippet
 protected override void OnStartup(StartupEventArgs e)
{
    base.OnStartup(e);
 
    if (!Utils.IsInDesignTool)
    {
        var asmCatalog = new AssemblyCatalog(typeof(App).Assembly);
        var catalogs = new AggregateCatalog(asmCatalog);
        var container = new CompositionContainer(catalogs);
        CompositionHost.Initialize(container);
        container.Compose(new CompositionBatch());
        
        var root = new MainWindow(); 
        root.ShowDialog();
    }
}
 

line 5, preventing MEF operation during design time.

lines 7-9, setting the MEF container.

line 10, setting the MEF container as the main container of the application

(this way it can be reachable anywhere).

line 11, do the composition,

IMPOERANT: the composition should happens before the window instantiation,

because that when the markup extension will be invoke.

the exported part should be available at this time.

lines 13-14, starting the application.

Summary

we can extend the Xaml very easily in order to get better Xaml->Mef experience.

the code sample for this post is available here.

תגים של Technorati:‏ Import,ImportMany,MEF,composition,CLR 4

Recommendation

bnaya — Sat, 20 Mar 2010 15:25:41 GMT

Recommendation

this is a post recommendation about using Rx framework with WPF events,

I'm recommending this post from bobby's blog, the post is demonstrating the

use of creating observable stream from WPF event.

it is a short post with nice little code sample.

bobby did a real good job by wrapping the observable event (Observable.FromEvent)

into more human readable format (using T4 template).

Rx - Reactive Extension – for beginners (part 2)

bnaya — Tue, 23 Feb 2010 01:53:30 GMT

Rx - Reactive Extension (part 2)

this post is the second in a series of posts about the new Reactive Framework (Rx).

the previous post discuss the concept of Rx (Reactive Framework Extension),

this post will focus on some basic practice.

In this post we will create small WPF application that got images from different

image feeds providers (the source code can be found here).

Application layout

The application layout is described in the following diagram.

the image data will be pushed into the PhotoDataSourceProvider class which implement IObserver.

Code Snippet
 public class PhotoDataSourceProvider : DataSourceProvider, IObserver<ImageData>
{
    ...
}
 

the class will take the pushed data and expose it to the UI through the DataSourceProvider overrides.

DataSourceProvider is used as mediator between the UI and the Feeders in order to make the UI data thread safe.

In short the IObserver is where the data get pushed.

The feeders implement IObservable

Code Snippet
 public abstract class ImageFeederBase: IObservable<ImageData>
{
    public IDisposable Subscribe(IObserver<ImageData> observer)
    {
      ..
    }
}
 

all feeders inherit from ImageFeederBase.

IObservable expose the Subscribe method, which can be use for subscribing the

PhotoDataSourceProvider (because it is an observer).

this is how the PhotoDataSourceProvider constructor look like:

Code Snippet
 public PhotoDataSourceProvider()
{
    var picasaFeeder = new PicasaImageFeeder();
    picasaFeeder.Subscribe(this);
    var flickrAircraftFeeder = new FlickrImageFeeder("Aircraft");
    flickrAircraftFeeder.Subscribe(this);
    var flickrFlowerFeeder = new FlickrImageFeeder("Flower");
    flickrFlowerFeeder.Subscribe(this);
    var flickrSmileyFeeder = new FlickrImageFeeder("Smiley");
    flickrSmileyFeeder.Subscribe(this);
    var fileSystemJpgFeeder = new FileSystemImageFeeder("*.jpg");
    fileSystemJpgFeeder.Subscribe(this);
    var fileSystemPngFeeder = new FileSystemImageFeeder("*.png");
    fileSystemPngFeeder.Subscribe(this);
}
 

it subscribing itself for different feeders.

then whenever the feeder Has new image, Complete or Has Error

the PhotoDataSourceProvider will be notify through it IObserver implementation.

Code Snippet
 void IObserver<ImageData>.OnCompleted()
{
    ...
}
void IObserver<ImageData>.OnError(Exception exception)
{
    ...
}
void IObserver<ImageData>.OnNext(ImageData value)
{
    ...
}
 

Summary

the Rx is using the IObservable and IObserver in order to formalize push based operation.

the IObservable is the push supplier, while the IObserver is the push target.

IObserver can be subscribe to one or more IObservable.

Source Code

the source code can be found here.

תגים של Technorati:‏ IObserver,IObservable,Rx

MEF for Beginner (repeatable metadata) - part 9

bnaya — Fri, 29 Jan 2010 20:02:27 GMT

MEF for Beginner (repeatable metadata) - part 9

this is the 9th post of the MEF for Beginner series, the series TOC is available here.

this post will focus on having repeatable metadata definition (cases like definition of multiple categories).

if you not familiar with the MEF metadata concept you may want to read part 8.

Bad practice for repeatable metadata

In order to explain repeatable metadata, we will start by decorating export with

untyped metadata declaration (which consider as bad practice, use typed metadata

whenever you can, it is mach usable and reducing runtime failure).

Code Snippet
 [Export(typeof(IPlug))]
// using untyped metadata considered as bad practice
[ExportMetadata("Categories", Category.Travel, IsMultiple = true)]  
[ExportMetadata("Categories", Category.City, IsMultiple = true)]   
public class NewYork : IPlug
{
    public void Write() { Console.WriteLine("New York"); }
}
 

the above code snippet decorate the plug-in with categories metadata for both Travel and City (line 3,4).

notice that we should explicitly declare that those decoration is multiple (IsMultiple=true).

line 1: define the export.

latter on this post we will see the best practice of declaring the metadata using custom attribute.

Metadata view contract for repeatable metadata definition

the metadata view contract properties type, for repeatable metadata decoration, should be Array, or IEnumerable.

the following metadata view contract is capable to handle the above metadata decoration:

Code Snippet
 public interface IMetadataView
{
    Category[] Categories { get; }
}
 

as you can see, line 3, define property that match the name of our metadata decoration (Categories)

and it is using array for its data type.

Best practice for metadata definition

as in the previous part, the best practice for metadata definition is

using typed metadata, which mean to define attribute for the metadata.

Code Snippet
 [MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public class CategoryAttribute : Attribute
{
    public CategoryAttribute(Category category)
    {
        Categories = category;
    }
    public Category Categories { get; private set; }
}
 

as you can see it is almost identical for the definition of non-repeatable metadata attribute,

but with 2 differences:

we should declare that the attribute allow multiple occurrence (at the end of line 2),
this definition is equivalent to the IsMultiple definition on the untyped metadata.
we should derive from Attribute (instead of ExportAttribute, otherwise we will get multiple
instantiation of our plug-in).

the plug-in decoration will look as follow:

Code Snippet
 [Export(typeof(IPlug))]
[Category(Category.Game)]
[Category(Category.News)]
public class Football : IPlug
{
    public void Write() { Console.WriteLine("Football"); }
}
 

in term of code safety typed metadata leaving less margin for errors,

and it is match more usable because it is easier to understand which value are expected.

The Import decoration

our import should use the Lazy<IPlug, IMetadataView> in order to get the metadata information

(through the IMetadataView contract ).

Code Snippet
 [ImportMany]
public Lazy<IPlug, IMetadataView>[] Plugins { get; private set; }
 

Interrogating the metadata

the following code will compose and interrogate the metadata.

Code Snippet
 class Program
{
    static void Main(string[] args)
    {
        var instance = new Program();
        var cat = new AssemblyCatalog(typeof(Program).Assembly);
        var container = new CompositionContainer(cat);
        container.ComposeParts(instance);
 
        foreach (var plug in instance.Plugins)
        {
            plug.Value.Write();
            foreach (var category in plug.Metadata.Categories)
            {
                Console.Write(", {0}", category);
            }
        }
    }
 
    [ImportMany]
    public Lazy<IPlug, IMetadataView>[] Plugins { get; private set; }
}
 

lines 6-8, is handling the composition.

line 10, iterating for each of the discovered plug-in.

line 13, iterating for each of the items in the metadata categories property upon specific plug-in.

Summary

having multiple metadata on the same export is slightly more challenging.

the main difference between working with repeatable metadata relate to the metadata decoration (AllowMultiple=true)

and having Array or IEnumerable at the metadata view properties level.

Download the code

the full code snippet for the samples covered by this post available in here,

full project download for the post sample and for WPF sample that using this post concept for

dynamic filtering of widgets by categories (as shown bellow), is available here for 2008, and here for 2010.

filtering widgets by categories sample (2010, 2008).

Point of interest

do not use setter on your metadata view interface.
do not use the [InheritedExport] because for some some strange reason it doesn't functioning well along with metadata.
if you want to build advance metadata view contract you can use class instead of interface,
but that class must have constructor with the following signature:
public ClassName (IDictionary<string, object> metadata)
inside the constructor you should map the metadata dictionary to the class properties.

תגים של Technorati:‏ MEF,Extensibility,Importmany,Export,Import,IoC,SELA,composition

MEF for Beginner (Metadata) - part 8

bnaya — Wed, 20 Jan 2010 06:33:14 GMT

MEF for Beginner (Metadata) - part 8

this is the 8th post of the MEF for Beginner series, the series TOC is available here.

this post will focus on the basics of MEF metadata capabilities,

the next post discuss the ability of multiple metadata decorations.

What is Metadata?

metadata is piece of compile-time information that can be attached to exported part.

metadata is adding peripheral information to the part,
(metadata information may define which operation system supported by the plug-in).
metadata can be read before the instantiation of the part.

Typed metadata

MEF support both typed and non typed metadata, as is the case in other .net component

the best practice suggest using the typed metadata paradigm.

(our series will focus on the best practice of type metadata).

Which steps is needed for working with typed metadata?

the steps is needed is:

define the metadata (attribute)
decorate the exported part
define the metadata view contract
add the metadata view contract into the import signature

how to define typed metadata

defining metadata is very simple, all its take is to define attribute which

having public properties and is decorated with the [MetadataAttribute]

Code Snippet
 [MetadataAttribute]
public class WeatherAttribute : Attribute
{
    public WeatherConditions Conditions { get; set; }
    public int MinWindLimit { get; set; }
    public int MaxWindLimit { get; set; }
}
 

as you can see it is no different from any other .net attribute definition,

except of the decoration of [MetadataAttribute] in line 1.

Decorate the exported part

Code Snippet
 [Export(typeof(PluginBase))]
[WeatherAttribute(MinWindLimit=0, MaxWindLimit=15,
    Conditions = WeatherConditions.SnowyDays)]
public class Rollerblading : PluginBase {... }
 

as you can see in line 2 the exported part is decorated with some metadata.

line 1 is decorating for the export (see the Improving the usability section for

learning how it can be more usable).

Define the metadata view contract

metadata view present the portion of the metadata that we want to interrogate,

(this contract can be class of interface and it can reflect all or part of the attribute public fields).

Code Snippet
 public interface IWeatherMetadata
{
    WeatherConditions Conditions { get; }
    int MinWindLimit { get; }
    int MaxWindLimit { get; }
}
 

in the above case the metadata view contract is reflecting all of the public properties.

Import signature

the import definition should use Lazy type with 2 generics definitions,

the first definition for the plug-in contract, and the second for the metadata view contract.

Code Snippet
 [ImportMany]
private IEnumerable<Lazy<PluginBase, IWeatherMetadata>> AllPlugIns { get; set; }
 

as you can see in line 2, MEF will create enumerable of lazy plug-ins which having typed weather metadata.

Inquiring the metadata

having the above import we may use Linq query (or any other technique) to filter the plug-in

portion that suite our needs (without having to instantiate the unneeded plug-ins).

Code Snippet
 public IEnumerable<PluginBase> SunnyActivities
{
    get
    {
        var plugins = from lazyPlugin in AllPlugIns
                      let metadata = lazyPlugin.Metadata // typed metadata (IWeatherMetadata)
                      where metadata.Conditions == WeatherConditions.Sunny
                      select lazyPlugin.Value;
        return plugins;
    }
}
 

the above sample is using the typed metadata to filter the sunny activities.

Behind the scenes

what is happening behind the scenes it that MEF is using reflection emit in order to construct

the typed metadata view.

Improving the usability

we can improve the usability of the previous sample by inheriting the ExportAttribute

(instead of Attribute), that way we can have single simple decoration for our export part.

Code Snippet
 [MetadataAttribute]
[AttributeUsage (AttributeTargets.Class)]
public class WeatherAttribute:ExportAttribute
{
    public WeatherAttribute(int minWindLimit, int maxWindLimit, WeatherConditions conditions) :
        base(typeof(PluginBase))
    {
        Conditions = conditions;
        MaxWindLimit = maxWindLimit;
        MinWindLimit = minWindLimit;
    }
 
    public WeatherConditions Conditions { get; private set; }
    public int MinWindLimit { get; private set; }
    public int MaxWindLimit { get; private set; }
}
 

the above attribute define both typed metadata and export for the PluginBase type.

line 3: is inheriting the ExportAttribute.

the exported type decoration can be define using single simple attribute decoration.

Code Snippet
 [WeatherAttribute(0, 15, WeatherConditions.SnowyDays)]
public class Rollerblading : PluginBase {...}
 

you are no longer having to use different attribute for export and metadata,

and as in this case the export type definition is handled by the attribute,

which enhance the consumer usability by having less area for errors.

Code sample

the code sample is demonstrating scenario were we want to present only plug-ins that suit

the current weather (the sample is using Google API for getting the NY weather).

you can download the sample for VS 2010 from here and for VS 2008 from here.

תגים של Technorati:‏ MEF,Extensibility,Importmany,Export,Import,IoC,SELA

MEF for Beginner: TOC

bnaya — Sat, 09 Jan 2010 16:26:22 GMT

MEF for beginner is a blog series for developers that want to learn

How To use the MEF (Manage Extensibility Framework) technology.

the following post is currently available for this series:

Concept

How To build your first MEF application

Hello Silverlight

A-sync Silverlight loading

Import

Part Creation policy

Recomposition policy

Metadata (part 1)

Metadata (part 2 – repeatable)

Catalogs

Import from Xaml

Deployment Catalog

תגים של Technorati:‏ MEF,Beginner,Composition,Extensibility,IoC,SELA,Silverlight,WPF,Plug-in

MEF for Beginner – Part 3 (Hello Silverlight)

bnaya — Sun, 20 Dec 2009 02:21:42 GMT

MEF for Beginner – Part 3 (Hello Silverlight)

in this post we will cover the basic steps that is needed for building your first Silverlight MEF application.

you can find more about the MEF on part 1, part 2 of this series, the series TOC is available here.

the following instructions will lead you through very simple steps of building simple Silverlight shell application

that can consume plug-ins.

this post is written on Visual Studio 2010 and Silverlight 4.0 (using Visual studio 2008 and Silverlight 3

will need some minor modification and download the MEF Silverlight 3 bits from the MEF site).

in the next post on this series, we will extend the current post by learning how to consume external plug-ins using a-sync loading .

the code sample for this post can be download from here.

Step 1: Creating Silverlight Application

Create solution using the Silverlight application template.

Step 2: Setting the Shell layout

the layout of the shell will have 2 area (plug-in command area and main area):

the plug-ins commands will host in StackPanel control

and the main content area will have a Border and TextBlock controls within a Canvas.

add the following Xaml into the Grid element of the main page.

Code Snippet
 <Grid.ColumnDefinitions>
    <ColumnDefinition Width="150" />
    <ColumnDefinition Width="308*" />
</Grid.ColumnDefinitions>
<StackPanel Orientation="Vertical" Grid.Column="0">
</StackPanel>
<Canvas x:Name="_mainContentPlaceHolder" Grid.Column="1" >
    <Border x:Name="_mainBorder" Width="250" Height="100" BorderThickness="1" CornerRadius="1" Margin="4">
        <TextBlock x:Name="_mainText" Text="Some content"/>
    </Border>
</Canvas>
 

Step 3: Binding the StackPanel to plug-ins list

add the ItemControl element into the StackPanel (see it's binding definition)

Code Snippet
 <StackPanel Orientation="Vertical" Grid.Column="0">
    <ItemsControl ItemsSource="{Binding Path=ToolbarItems}" />
</StackPanel>
 

add ObservableCollection of UserControl property called ToolbarItems into the Shell code behind
(the binding definition at the Xaml level refer to this property)

Code Snippet
 public ObservableCollection<UserControl> ToolbarItems { get; set; }
 

initialize the ToolbarItems property and the Context at the constructor,

(the following lines should be add to the constructor).

Code Snippet
 ToolbarItems = new ObservableCollection<UserControl>();
DataContext = this;
 

Step 4: add reference to MEF

before adding the plug-able functionality, we have to add reference to MEF.

add new reference and browse for System.ComponentModel.Composition.dll under the following folder:

64 bit: C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client

32 bit: C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client

Step 5: decorate the ToolbarItems property

decorating the ToolbarItems property with ImportMany attribute, will shift the responsibility of

filling it with UserControl instances to MEF (which is basically saying to MEF

that it should add any item that was Export and match the contract (in our case UserControl).

the ToolbarItems should now look like this:

Code Snippet
 [ImportMany]
public ObservableCollection<UserControl> ToolbarItems { get; set; }
 

Step 6: expose the Element within the main area

the shell will expose the Border and the TextBlock within it main area so it can be

discoverable by the plug-ins.

to achieve this task we will add 2 properties (at the code behind) and decorate it with Export attribute.

Code Snippet
 [Export]
public TextBlock MainText
{
    get { return _mainText; }
}
 
[Export]
public Border MainBorder
{
    get { return _mainBorder; }
}
 

Step 7: Create exportable entities (create plug-ins)

Note: on this post we will add the plug-ins within the same package as our Shell,

but in the next post in this series we will show how to discover exportable

parts within external packages.

Create Parts folder in the project and add Silverlight User Control (PlugableEffect1.xaml)

Step 7.1: Stet the look and feel of the effect command

add the following Xaml into the Grid element (of the effect xaml)

Code Snippet
 <Button Command="{Binding}" Width="Auto" Height="Auto">
    <TextBlock Text="Effect 1"/>
</Button>
 

Step 7.2: Add TextBlock property that present the TextBlock at the Shell main area

also this plug-in is capable of manipulate a TextBlock, it shouldn't be aware of

the TextBlock origin.

to achieve the above requirements we will once again add decorated property,

which will be assigned by MEF at runtime.

this time we expecting single value, therefore we will decorate the property with the Import attribute

rather the ImportMany attribute.

Note: MEF will find the exported TextBlock which we expose at step 6 and assign it into the following property.

Code Snippet
 [Import]
public TextBlock ShellText { get; set; }
 

Step 7.3: Set the effect command

looking at the Xaml of the button we can see that it use the Command="Binding"

this mean that the button expect ICommand implementation within it's data context.

at the code behind of this effect, add the following line to the constructor.

Code Snippet
 DataContext = this;
 

and implement ICommand

Code Snippet
 public partial class PlagableEffect1 : UserControl, ICommand
 

Code Snippet
 public bool CanExecute(object parameter)
{
    return true;
}
 
public event EventHandler CanExecuteChanged;
 
public void Execute(object parameter)
{
    ShellText.Text = "Effect 1";
    ShellText.FontSize = 32.0;
    ShellText.Foreground = new SolidColorBrush(Colors.Red);
    ShellText.FontFamily = new FontFamily("Comic Sans MS");
}
 

Step 7.4: Export our effect

making the effect visible to MEF done by decorating the class with Export attribute.

Code Snippet
 [Export(typeof(UserControl))]
public partial class PlugableEffect1 : UserControl, ICommand
 

Step 8: Create another exportable entities (create plug-ins)

repeat step 7 for Effect 2 (replace the Effect 1 text to Effect 2).

then add another property decorated with Import for the shell Border element.

Code Snippet
 [Import]
public Border ShellBorder { get; set; }
 

replace the Execute method implementation of the Effect 2 command to the following:

Code Snippet
 public void Execute(object parameter)
{
    ShellText.Text = "Effect 2";
    ShellText.FontSize = 24.0;
    ShellText.Foreground = new SolidColorBrush(Color.FromArgb(255, 33, 33, 33));
    ShellText.FontFamily = new FontFamily("Comic Sans MS");
    ShellText.FontWeight = FontWeights.ExtraBold;
    ShellText.VerticalAlignment = System.Windows.VerticalAlignment.Center;
    ShellText.HorizontalAlignment = HorizontalAlignment.Center;
 
    ShellBorder.BorderThickness = new Thickness(8);
    ShellBorder.BorderBrush = new SolidColorBrush(Colors.Gray);
    ShellBorder.CornerRadius = new CornerRadius(10.0);
    ShellBorder.Background = new SolidColorBrush(Colors.Orange);
    ShellBorder.Width = 250;
    var rt = new RotateTransform();
    rt.Angle = 45;
    rt.CenterX = 1.5;
    rt.CenterY = 30;
    ShellBorder.RenderTransform = rt;
}
 

Step 9: Compose it all together

before we continue we have to add reference to System.ComponentModel.Composition.Packaging.Toolkit.dll

this dll is part of the MEF Silverlight Toolkit

after installing the toolkit you can find the System.ComponentModel.Composition.Packaging.Toolkit.dll

at C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Toolkit\Nov09\Bin (for 64 bit)

and at C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Toolkit\Nov09\Bin (for 32 bit)

Step 9.1: Compose

the last step involve is asking MEF to compose.

we will supply MEF with some basics instruction and ask it to assign all the Import with

Export that matches the Import's needs.

Add the following method to the App.xaml code behind.

Code Snippet
 private void InitializeContainer(UIElement mainWin)
{
    var catalogs = new PackageCatalog();
    catalogs.AddPackage(Package.Current);
    var mainWinPart = AttributedModelServices.CreatePart(mainWin);
    var batch = new CompositionBatch(new[] { mainWinPart }, null);
    var container = new CompositionContainer(catalogs);
    container.Compose(batch);
}
 

the above code create a Catalog (at lines 3,4) ,

Catalog used as instruction for where to search for the compose-able parts.

in this case we instruct MEF to look for compose-able parts within the current Silverlight package.

at lines 5,6 we add the current instance of the Shell into CompositionBatch, this will instruct the MEF container

to use this instance rather of creating new one.

line 7, 8 add the Catalog and the CompositionBatch to a CompositionContainer and perform the composition.

the last peace of code is calling the above method from the application startup.

Code Snippet
 private void Application_Startup(object sender, StartupEventArgs e)
{
    this.RootVisual = new MainPage();
    InitializeContainer(this.RootVisual);
}
 

Summary

this post had demonstrate how to build compose-able shell using Silverlight 4.0.

in the next post we will continue to enhance the sample by adding a-sync loading capability

to external Silverlight packages that holding compose-able parts (Plug-ins).

Downloads

the code sample for this post can be download from here.

you will need Silverlight 4 and the Silverlight 4 toolkit. You can download Silverlight 4 beta here and the toolkit here.

Learn More

you can find more information on how to use MEF over Silverlight in the following posts (by Glenn Block):

Building the Hello MEF dashboard in Silverlight 4 - Part I

Building Hello MEF – Part II – Metadata and why being Lazy is a good thing.

Building Hello MEF – Part III – XAP Partitioning (with the host’s permission) and the sweetness of recomposition.

Updates

the MEF API for Silverlight Catalog has changed,

instead using the PackageCatalog you should now use the DeploymentCatalog.

other changes were:

PartIntializer renamed to CompositionInitializer (Silverlight only)

and PartCreator renamed to ExportFactory<T> and moved to System.ComponentModel.Composition.Initialization assembly (Silverlight only)

MEF Recomposition

bnaya — Fri, 06 Nov 2009 04:59:45 GMT

thinking about MEF as another IoC container led us into misconception.
MEF design goal was being a generic extensibility infrastructure,
its just happens that it overlap with the IoC world (and yes it has most of the IoC feature).

this post address the challenge of building extensions over none CLR types (like image files)

from the technical perspective it will discuss the following techniques:

Building Export Providers
Design recomposable extensions
Creating DataSourceProvider (which will used for WPF binding)

the source code for this post can be found here.

Prerequisite

this is advance post which assume basic understanding of the MEF technology (for MEF introduction read this post).

Our Test Case

in order to demonstrate the above techniques I choose common scenario of building
very simple WPF application that display pictures which came from heterogeneous data source providers.

The Solution Modeling

ComponentModel.Initialization.dll

this components design by the MEF team as centric handle for the MEF container functionality

(i did very minor changes to the CompositionHost class, basically exposing the underline container as Export Provider)

ImageExportProviders.dll

this is the heart of this post,.

Export providers (not the catalog) is the underline MEF unit that responsible for the instantiation of the exported parts.

the different providers implementations (local, Picasa, Fickr) has the knowledge of
how to instantiate the discovered photo files into CLR type that implement IPhotoInfo.

MEFPhotoDataSourceProvider

this class is responsible for abstracting the WPF application from it actual photos sources.

WpfImageViewerUI.exe

is the UI implementation

Application flow

from this point i will start to explain the different techniques used in the application,
starting with the UI.

UI (WpfImageViewerUI project)

App.xaml

At the code behind level, it initial the Container with custom MEF Export Providers

and pass the container to the Composition Host (the composition host used as

the default container, it is reachable from anywhere in the code)

Code Snippet

protected override void OnStartup(StartupEventArgs e)

{

    base.OnStartup(e);

    var providers = new ExportProvider[] {

        new LocalImageExportProvider("Images", "*.jpg"),

        new PicasaImageExportProvider(URL_PICASA_GENERAL),

        new FlickrImageExportProvider(URL_FLICKR_PEOPLE)

    };

    var container = new CompositionContainer(providers);

    CompositionHost.InitializeContainer(container);

}

At the Xaml level we embed the Style.xaml

Code Snippet

<Application.Resources>

    <ResourceDictionary>

        <ResourceDictionary.MergedDictionaries>

            <ResourceDictionary Source="Style.xaml" />

        </ResourceDictionary.MergedDictionaries>

    </ResourceDictionary>

</Application.Resources>

     Style.xaml

For better separation between the graphical designer and the developer, I'm using the style.xaml
as the designer own xaml (only the designer should touch this file, he can change styles and templates).

     PictureShell.xaml

this is the developer own xaml, which the designer shouldn't touch.

it should contain the minimal xaml needed, from the functionality perspective

(it should not have any beauty factor actually it should be really ugly without the style.xaml)

Code Snippet

<Window x:Class="Bnaya.Samples.PictureShell"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        xmlns:local="clr-namespace:Bnaya.Samples.Data..."

    Title="PictureShell" Height="300" Width="600">

    <Window.DataContext>

        <local:MEFPhotoDataSourceProvider/>

    </Window.DataContext>

    <ListBox x:Name="_lst" ItemsSource="{Binding IsAsync=True}" />

</Window>


as you can see it kept short, clean and easy to understand.

from the debugging perspective you can disembed the style.xaml and check whether the
bug came from the functionality or the design.

this xaml contain:

    ListBox declaration
    MEFPhotoDataSourceProvider (which is the binding source of the list's ItemSource)

UI.Components (define the MEFPhotoDataSourceProvider class)

as we mention earlier we using data source provider to abstract the actual origin of the data.

the xaml won't have to be changed whenever adding or removing data sources.

another benefit is the ability of a-sync loading (data source that expose hundreds of photos cannot expose synchronously)

Code Snippet
 public class MEFPhotoDataSourceProvider : DataSourceProvider
{
    private ObservableCollection<IPhotoInfo> _photos =
        new ObservableCollection<IPhotoInfo>();
    public MEFPhotoDataSourceProvider()
    {   // register for MEF ewcomposable discovery
        CompositionHost.Host.ExportsChanged += OnPhotosChangedHandler; 
    }
 
    protected override void BeginQuery()
    {   // a-sync initialization
        ThreadPool.QueueUserWorkItem(Init);
    }
 
    [ImportMany(typeof(IPhotoInfo), AllowRecomposition = true)]
    private IEnumerable<Lazy<IPhotoInfo>> PhotosInternal { get; set; }
 
    private void Init(object state)
    {
        PartInitializer.SatisfyImports(this); // load the picture through MEF
        PhotosInternal.ForEach(lazy => _photos.Add(lazy.Value)); // add 
        base.OnQueryFinished(_photos);
    }
 
    private void OnPhotosChangedHandler(object sender,ExportsChangeEventArgs e)
    {
        foreach (var expDef in e.AddedExports) {
            if (expDef.Metadata.ContainsKey("Export")) {
                Invoke(() =>
                {
                    Export exp = expDef.Metadata["Export"] as Export;
                    _photos.Add(exp.Value as IPhotoInfo);
                });
            }
        }
    }
}
 

    at line 15, you can see that we using the ImportMany decoration with AllowRecomposition = true
this is the key of the a-sync capabilities (lazy loading).
you can download the source code from here and run the application with and without AllowRecomposition
in order to see its effect.

    at line 20, PartInitializer.SatisfyImports(this) is actually asking the default MEF container (which we define at the app.xaml)
for the discovered export parts that match the import.

    at line 22, we introduce the base class with our data source collection.

    at the constructor level line 7, CompositionHost.Host.ExportsChanged += OnPhotosChangedHandler we register to the
default MEF container changed event (again the a-sync lazy loading)

    at the OnPhotosChangedHandler, line 25, we adding any new composed instances into the bind-able collection.

Finally we got into the heart of extensibility model, the Export Providers

we use custom Export Provider for discovering none CLR entities (in our case photo files) and introduce it to the CLR world
via the MEF infrastructure as instances that implement IPhotoInfo.

the ImageExportProviders project contain 4 files (one base class and 3 providers)

    ImageExportProviderBase is the provider base class

Code Snippet

public abstract class ImageExportProviderBase : ExportProvider

{

    protected static readonly string CONTRACT_NAME = typeof(IPhotoInfo).FullName;

    protected readonly string _path;

    public ImageExportProviderBase(string path) {

        _path = path;

    }

    protected override IEnumerable<Export> GetExportsCore(

        ImportDefinition definition, AtomicComposition atomicComposition)

    {

        IEnumerable<Export> exports = null;

        if (definition.IsRecomposable) // Async

            ThreadPool.QueueUserWorkItem(LoadPhotos, definition); // we will use recomposition

        else

            exports = OnLoadPhotos(definition);

        return exports;

    }

    protected abstract IEnumerable<Export> OnLoadPhotos(ImportDefinition definition);

    private void LoadPhotos(object state) {

        OnLoadPhotos(state as ImportDefinition);

    }

    protected void IntroduceNewExport(Export e) {

        var metadata = new Dictionary<string, object>();

        metadata.Add("Export", e);

        var expDef = new ExportDefinition(CONTRACT_NAME, metadata);

        using (var atomic = new AtomicComposition())

        {

            var argsChanging = new ExportsChangeEventArgs(

                new ExportDefinition[] { expDef }, new ExportDefinition[0], atomic);

            atomic.AddCompleteAction(() => { });

            base.OnExportsChanging(argsChanging);

            atomic.Complete();

        }

        var argsChanged = new ExportsChangeEventArgs(

            new ExportDefinition[] { expDef }, new ExportDefinition[0], null);

        base.OnExportsChanged(argsChanged);

    }

}

The GetExportsCore is what we have to override when creating custom Export Provider.
you can see at line 12, that we check whether the import definition is recomposable and act accordingly.

in case of recomposable the IntroduceNewExport method is where we notify about the new available exports.

the 3 derived class is just a parser for specific source type.

    LocalImageExportProvider discover and parse file on the local file system.

    FlickrImageExportProvider discover and parse file from the Flickr web site.

Flickr API does not support thumbnails, which results that pictures discovered on Flickr will appear with delay.

    PicasaImageExportProvider discover and parse file from the Picasa web site.

Conclusion

the MEF ability to compose beyond the CLR world is one of its underline extensibility design that
differentiate MEF from typical IoC containers.

and we can use MEF to abstract our data sources achieving a-sync and loosely coupled advantage.

the source code for this post can be found here.

Who own that XAML?

bnaya — Sat, 05 Sep 2009 22:27:20 GMT

This post is about WPF / Silverlight separation of concern and on the continues question Who own that XAML?

Before we begin here is my proper disclosure:
I'm not an expert in WPF nor in Silverlight though take this post as a thought sharing and i would like to get your comments on that subject.

Background

The all subject emerge while i was listening to Herding Code podcast about MVVM.

So i was asking myself, how would i assemble UI team and have them working with great productivity and without ruin each other work?

The problem

The main failure point that everybody going around is that XAML thing, but some time it seem that the questions people asking isn’t the right one.

I’m thinking that the main question should be
who own the XAML? rather then
who’s touching the it and when?

I will go farther and argue that we should separate the XAML into 2 separate XAMLs.

1. Developer XAML

2. Designer XAML

each of the XAML has very clear ownership and very clear goal.

The developer XAML should be limit to hold sheer functionality without any beauty factor (target for the minimal view developer need in order to get it functioning).
Events wiring actions (not animation) will fall under the developer responsibility, MVVM command is even better.

The Designer XAML should target the followings:
- Styling
- Animation
- Enriched data templates

Binding the beauty factor

Farther thinking of switching between the developer view and the designer view, i come to the following idea.
I believe that the code behind should have properties which the data templates and styling should be bind to.
This properties can be initialize form configuration and this way (for testing purpose) we can switch to the developer view to see whether our problem cause by the design or functionality fault.

Summary

I believe that following that pattern we will end up with mach clearer separation of concern and higher productivity and maintainability.

I know that there is lot more aspects that i didn’t touch in this post (like unit testing and other) and i encourage you to leave comment expressing your thought on this subject.