Erwin van der Valk's blog: Practicing patterns : Silverlight

writing applications that target both wpf and silverlight with a single codebase

erwinvandervalk — Thu, 03 Sep 2009 23:09:50 GMT

A while back, I wrote an MSDN article on writing multi-targeted programs with Prism.

http://msdn.microsoft.com/en-us/magazine/ee321573.aspx

Hope you like it!

prism v2 – drop 10 (composite application guidance)

erwinvandervalk — Sat, 31 Jan 2009 02:41:41 GMT

Today, we have released what’s likely going to be the last drop of Prism before the final release. You can get the release from:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=22566

During this iteration, we have mostly worked on documentation, implementing a new UI for the Stock Trader Reference Implementation and fixing some last important bugs.

The most important changes are:

Removed .Silverlight and .Desktop extensions from the Assembly names, both in the Library and in all the Quickstarts.

Renamed RegionExtensions class to RegionContext and RegionExtensions.GetRegionContext() method to RegionContext.GetObservableContext()

Moved RegionExtensions.GetObservableRegion() method from RegionExtensions class to RegionManager class.

Integrated new UI design for Stock Trader Reference Implementation.

Many updates to Documentation

Included API CHM file

Added shortcut .Bat files to make it easier to open the solutions.

Bug fixes

Added missing XML comments to the code of the Composite Application Library.

New UI for Stock Trader Reference Implementation

We felt that the original UI of the Stocktrader RI didn’t give a good impression of the capabilities of WPF and Silverlight. Most of the things we were showing before were also possible with Windows Forms. So for this release, we’ve decided to hire a graphical design company to give our RI a complete makeover, complete with some cool animations.

Before:

After:

Looks a lot better huh?

prism v2 – drop 9 (composite application guidance for wpf and silverlight)

erwinvandervalk — Mon, 19 Jan 2009 22:32:29 GMT

It’s been a while since my last post. Not that the Prism team has been sitting idle though.

Last Friday, we’ve released drop 9 of Prism. As we are approaching the end of the Prism v2 project, there are a lot less API changes, as we are mostly focussing on finishing the docs and resolving bugs. We have also spent some time trying to build different application styles (for example, an outlook style app, or a master-detail style app) on top of our library. The results of this exercise was very useful. Unfortunately, they were nothing more than spikes, so we can’t deliver them as part Prism, but we are thinking of doing a bunch of blog posts or webcasts, that describe how to build different application styles on top of Prism.

You can get drop 9 of Prism here:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=21912

What’s in Prism drop 9

New skin for the Stocktrader reference implementation.
We wanted to show a bit more of the power of the WPF and Silverlight platform in our RI, so we have hired an external design bureau to create a new design. It has taken a bit longer to implement than we had hoped. In this drop, we have some of the basic styling in place. Hopefully, we can get the next styling
Desktop only solutions
Not everybody is interested in developing on both WPF and Silverlight. So that’s why we’ve added ‘WPF’ only solutions. We can’t really add Silverlight only solutions as easily, because the Silverlight projects are linking all the files from the WPF projects.
New SingleActiveWindowRegionAdapter in the RI
We are demonstrating how to create an adapter in the RI, in this case how to create a popup window and use that as a region.
Several bugs fixed
Lots of testing, prioritizing, bugfixing, retesting, etc..
Exception stack compression in combination with Unity
Unity is an awesome DI container, but it doesn’t give really clear exception messages if something goes wrong.

The last weeks of a project are always interesting. There are _so_ many ‘little’ things we would have wanted do do, or add to the library. but what seems like a small dev effort, can quickly add up if you also count the test and doc effort. So, we are constantly keeping a critical eye on our prioritized backlog of tasks. Unfortunately, this means there are a bunch of really interesting stuff we would have loved to tackle, but we can’t.

Exception stack compression

While building different application styles on top of Prism, we found an interesting problem.

Suppose the following example: You are creating a simple view. In the Module.Initialize(), you are registering the type of the view against a region that’s displayed in the shell. In the constructor of the view, you have made a small programming error, which causes an exception.

So what’s the result?

A module initialize error. Ok, that makes sense. But what was the exception message inside that? “Exception occurred at target of invocation.”. And inside that? A bunch of ServiceLocator, Unity and Objectbuilder errors. Only somewhere at the bottom of the inner exception list you find the exception that caused the problem.

All these exceptions are perfectly valid from a technical point of view, but not very useful in understanding what’s going wrong. Ideally, Unity should return a very clear exception message: “Tried to create object X, but could not because of this error message: ‘xyz’”. Unfortunately, Unity does not do this. (After a discussion with the enterprise library team, it turns out that it’s really hard to build this in Unity). I think that developers who are building applications on top of Prism are rarely interested how exactly the DI container builds up it’s objects. So all the technical inner exceptions are just clutter to them, that’s obscuring what’s really going wrong.

So we have built some logic to try and find the error in the stack trace that actually points developers in the right direction. The goal was to be able to get the following exception message: “An exception occurred while initializing module X, in the constructor of View X, with exception message “XYZ”.

So now in Prism, you can use the extension method exception.GetRootException() to try and find the exception that’s actually causing the problem. It won’t be 100% accurate, but it looks like it really helps in getting to the root of the problem more quickly.

Hopefully you will find this useful to!

PRISM v2 – dROP 6 (Composite Application Guidance for WPF and Silverlight

erwinvandervalk — Sat, 22 Nov 2008 04:48:53 GMT

Today, we have released the 6th drop of Prism V2 (affectionately known as Compostite Application Guidance for WPF and Silverlight)

You can download it from:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=19731

What’s new?

We’ve had a busy iteration, where we mainly focused on improving some of the design around regions, bugfixes and some code cleanup. This is the list of new items:

    • RegionContext usable in XAML.
    • Introduced a façade on IRegionManager for adding views to regions (push based) and registering view types (pull based)
    • Expanded the usage of pull based composition in Top Down Composition quickstart
    • Silverlight RI is now using the Silverlight Toolkit Controls for line and pie charts
    • Regions and RegionContext using an expanded behavior mechanisms
    • Have established package load key for project linker
        • known issue: this still requires the SDK to be installed, however.
    • Changed to Add Project Link... dialog
    • Resolved a number of code-analysis rules
    • Stock Trader RI is now using pull-view (or top-down) composition for trend line graph
    • ProjectLinker installer does not have to be started with elevated permissions on Vista

So like always, please check it out and tell us what you think.

There are a couple of topics I’d like to go into a bit deeper:

Façade on IRegionManager

We’ve introduced a façade on the IRegionManager to make it a bit easier to work with Regions, either from a push or pull based perspective. You can use the following calls:

        1: public class MyModule : IModule

       2:  

       3:     public void Initialize()

       4:     {

       5:     

       6:         // Push based composition

       7:         // This code will find "Region1" (it must already be created) and add a new 

       8:         // instance of MyView to it. 

       9:         this.regionManager.AddViewToRegion("Region1", new MyView());

    

        // Pull based composition

        // This code will register a viewtype with a region. Whenever Region2 is 

        // displayed, it will automatically be populated by a new instance of MyView()

        // created by the ServiceLocator. 

        this.regionManager.RegisterTypeWithRegion("Region2", typeof(MyView());

    

        // Variation on pull based composition:

        // This code uses a delegate that creates the view to be pulled. This is great

        // if your presenters are responsible for creating the views. 

        this.regionManager.RegisterTypeWithRegion("Region2", 

               () => new MyViewPresenter().View());

        

    }   

  

    private IRegionManager regionManager;

    

    public MyModule(IRegionManager regionManager)

    {

        this.regionManager = regionManager;

    }

  

}

In the previous drop, we have introduced the IRegionViewRegistry, where you could register views to be pulled (Previously called RegionContentRegistry). This allows you to plug in your own registration module. However, we figured that for simple scenario’s, you don’t need to know about this implementation detail.

RegionContext

An other thing we’ve improved is the RegionContext. Like I mentioned in my previous blogpost, the RegionContext is a way that a view that hosts a region can share some of it’s information with any childviews that are loaded into it’s region. The RegionContext now supports 2 way databinding and is very configurable using RegionBehaviors.

The following codesnippet shows how to use the RegionContext in XAML:

<ContentControl x:Name="SelectionPanel"
                cal:RegionManager.RegionName="{x:Static local:RegionNames.SelectionRegion}"
                cal:RegionManager.RegionContext="{Binding Path=SelectedEmployee, Mode=TwoWay}"
                />

And in the views, you can get access to the regioncontext like this:

// To get the value from the regioncontext, from inside the view in a region:
var regionContextValue = RegionExtensions.GetRegionContext(this).Value

// To change the RegionContext:
RegionExtensions.GetRegionContext(this).Value = newValue

// And to subscribe to change events:
RegionExtensions.GetRegionContext(this).PropertyChanged += RegionContext_PropertyChanged

RegionBehaviors

We’ve received a number of questions from people who liked the functionality where a region would automatically pull in instances of all registered viewtypes. However, they really wanted the ability to influence which views were pulled in. This was one of the reasons why we moved to implement a list of behaviors on a region.

We had the following requirements:

You have to be able to define regions in XAML and Code
You should be able to bind the RegionContext in XAML or set it through code.
The RegionContext should be available for views inside a region. But a view can either be an UserControl (thus a dependencyobject) or a ViewModel (poco)
A region should be able to pull in registered views (but in a way you can influence it)

This lead us to the conclusion a region has a couple of behaviors. We will provide a number of behaviors by default, which you can change globally, or for a specific Region instance.

Default behaviors

We have built a number of behaviors:

For synchronizing the RegionContext, we’ve built two behaviors: SyncRegionContextBehavior, which will synchronize the regioncontext dependency property, defined in XAML with the Context property on the region. To synchronize the Regions Context property with childviews (we only support usercontrols now) we have the BindRegionContextToDependencyObjectBehavior.
For the TopDown (pull based) composition, we’ve created the AutoPopulateBehavior. This will query the RegionViewRegistry for all viewtypes defined on the view and autopopulate it.
To register the region with the regionmanager, we’ve created the RegionManagerRegistrationBehavior.
Some views are aware of the fact that they are ‘active’ or not, by implementing the IActiveAware. The active property is set on them by the RegionActiveAwareBehavior.

This diagram shows the behaviors we have built now:

Customizing the behaviors for all regions

The default behaviortypes are registered in the UnityBootstrapper. By overriding the ConfigureDefaultRegionBehaviors method you can add new behaviortypes, replace existing types or remove behaviors. You can also choose to register a different IRegionBehaviorFactory, if you require custom initialization for your behaviors.

The default behaviors are added by the RegionAdapterBase. In the RegionAdapter you can decide to add behaviors for specific control types. For example, we had to build a behavior to get the TabControl in silverlight to work properly. (It doesn’t derive from selector like in WPF).

Customizing the behaviors for a single region instance

Sometimes, you want to add a behavior to a specific instance of a region. For example, when you want to change the way views are pulled into a region. To do this, you have to detect that the region has been created, but before the default region behaviors are attached. You can do that by hooking up an eventhandler in the constructor of the view that’s hosting a region.

       1: // From the TopDownUIComposition Quickstart

       2: public EmployeesView()

       3: {

       4:     InitializeComponent();

       5:  

       6:     RegionExtensions.GetObservableRegion(this.SelectionPanel).PropertyChanged += delegate(object sender, PropertyChangedEventArgs args)

       7:     {

       8:         if (args.PropertyName == "Value")

       9:         {

      10:             // The region has just been created, but (Very Important), the default behaviors have not been added yet. 

      11:             // This gives you a chance to add your own custom behaviors. If you use the same key as a default behavior

      12:             // it will replace a default behavior. 

      13:             IRegion region = RegionExtensions.GetObservableRegion(this.SelectionPanel).Value;

      14:             region.Behaviors.Add(AutoPopulateRegionBehavior.BehaviorKey, new CustomAutoPopulateBehavior());

      15:         }

      16:     };

The ‘GetObservableRegion’ method will return an object that you can monitor to when the region is created. The .Value property will hold the new region.

Prism V2 – Drop 4

erwinvandervalk — Sat, 25 Oct 2008 01:54:53 GMT

Today, We have put an other drop of Prism V2 (Composite application guidance for WPF and Silverlight) online. You can download it from here:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=18750

New in Prism V2 - Drop 4

This sprint was mainly focused around UI Composition. We have ported the Region functionality from Prism V1 over so it also works in Silverlight. Then we also addressed a different style of visual composition, we’re calling Top Down composition. I’m going to drill into those composition styles later in this post.

Top down vs. Bottom up composition

In the last couple of weeks, we’ve had a lot of discussions around Visual Composition patterns.

Bottom up composition

Prism V1 used a regions to support Bottom Up composition. As a developer, you can define and name regions on your screen. When developing modules, you can use the names of these regions to push views into the regions. At first, we called this “push” based composition, because modules push their views into named regions. The diagram below shows an example of push based composition. We’re also calling this bottom up composition, because lower level modules push their views into the regions of higher level views.

Although this composition model allows for a highly decoupled and modular approach to UI development, we received some feedback that in some scenario’s it can be a bit to complex.

Top down composition

With top down composition we took a different approach. Usually, developers are very comfortable with the usage of UserControls. It’s quite common for developers to split up a view into several UserControls to reduce complexity (divide and conquer) and to improve reuse of visual elements. Now it’s quite easy to create controls and place them in different assemblies. However, in order to use those assemblies, the shell has to have a reference to the assemblies that hold the user controls. This goes against the principles of modular development where modules can be versioned, and deployed seperately.

We wanted to allow a model where you can visually compose your application in the same way as using UserControls, but without sacrificing modularity. To do this, we introduced a Top Down composition model:

So instead of the shell having a hard reference to the CustomerModule and putting a CustomerView directly on the ShellView, you put a ContentControl in the place where you want the user control. Then you use an attached property ViewType to specify what kind of View you want to display here, by specifying the interface of the view to display. The view interfaces can be defined in a seperate (Interface) module or in the shell.

When a module get’s initialized, it typically registers it’s views to the DI container. For example, the CustomerModule will tell the container that it can provide an implementation of the ICustomerView, because it registers the CustomerView type with the ICustomerView interface. Now after module initialization, the ShellView will ask the DI container for an implementation of ICustomerView. This will of course return the CustomerView, so it can then be shown in the ContentControl. Essentially, the ContentControl on the ShellView is pulling the CustomerView in from the CustomerModule, without having a direct reference to that module. We are calling this “Top Down” composition, because the Higher level modules define which views are displayed where.

This is an example (from the TopDownCompositionQuickstart) on how you specify a view that’s pulled into the shell in XAML:

<ContentControl 
    Regions:ContentController.ViewType=
         "TopDownComposition.Modules.Employee.IEmployeesListView, EmployeeModule.Silverlight, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

You might notice 2 things:

The viewtype is a string
At first we wanted to use the type of the interface directly. Unfortunately, this doesn’t work in Silverlight, because you cannot create types in XAML, because {x:Type} doesn’t work. But working with strings isn’t too bad. We’re planning to make the resolving logic pluggable. This way, you could for example use logical names, exported by your modules, to identify and retrieve the views. In fact, the MEF framework also works like that.
The viewtype is a really long string
To make working with those really long strings a bit more bearable, we’re also thinking of building a custom type resolver. Since 99.9% of the times the full typename (Namespace.TypeName) is unique, you can get away with just specifying that and let the framework figure out which assembly the type came from.

We’re also considering moving the View resolving functionality from the ContentController to the RegionManager. Even though technically this has nothing to do with regions, conceptually it’s very similar. A region specifies where you want to display visual elements from other modules. In the top down approach, you specify the content via it’s interface and in the bottom up approach you give it a name so others can push views into it. But it’s still a placeholder for views.

Conclusion

Hopefully you’ve found this post useful in explaining what we’re building. As always, we are very open to feedback. If you don’t like something we do, please tell us! Also if you do like something, tell us that as well! It might just prevent us from changing something you are already happy with :)