Ron Gramann

Windows 8: First Impressions

2011-09-19T21:38:00.000+01:00

The wait is over, and by now many of you have had a chance to take Windows 8 Developer Preview for a test drive. I haven't spent a huge amount of time with Win 8, but enough to form some initial opinions.

Start Screen and Touch
It appears Microsoft has opted to bring Touch front and center, as evidenced by the Start screen. Unfortunately the experience is not terribly rewarding for desktop users with a traditional keyboard and mouse. I am being kind here. In fact, after spending a couple of hours with the Start screen I was looking for ways to turn it off. Not because it is bad, just unnecessary. I would liken it to running Media Center has your main shell. Nice to look at, but in terms of productivity and value add, it brings very little to the table. Great for tablets, but please Microsoft, make it optional for desktop users.
Desktop users are desktop users because we use a keyboard and mouse out of necessity; because we are primarily using applications like Visual Studio, Photoshop and Office. I have no intention of running these applications on a tablet. So why impose obvious tablet-design on users who don't need them?

Metro UI
I am a big fan of Metro UI design and Win 8 has it in spades. But again, this is central to the new shell and is of value to tablet users. It feels like the desktop has taken a backseat, with Metro hogging the limelight. On the desktop we see very little Metro influence, which is unfortunate, because Metro design principles could be put to good use. For example, take a look at the newly designed Task Manager.

This design is influenced by Metro and is beautiful. I would like to see the entire desktop adopt a similar look and feel.
Windows has been criticized for being Windows. That rectangular boxes with content that can be minimized and resized were so 90s. So what? It's actually pretty workable, which is maybe why it's been with us for so long. Could it use a facelift? Sure, but I don't see the value in discarding it as a concept. But, with the time I've spent with Win 8 it feels like Microsoft is almost ashamed of its roots. And that Metro represents it's commitment to it's new forward-thinking Un-Window philosophic shift.

The Eco-System
Microsoft's goal of a computing eco-system has been getting a lot of press. I just have to ask Why? Why an eco-system? Why does my phone, tablet, laptop, desktop and TV have to share the same user experience? Are the IT consumers so thick that they just can't cope with differences across these devices? I think not. If Windows 8 is the solution, what is the problem? I've never felt stressed out that I use Android on my phone, Win 7 on the laptop/desktop, Media Center on the TV, and more recently WebOS on the tablet. There are things I like and dislike about each of those. I've never sat there and dreamt of a perfect world where all these devices work and function the same way...ahhh...think of it.

Conclusion
I understand it is early days, but my initial impressions of Win 8 were disappointing. It feels too devoted to touch and IT consumers and less to hardcore computing (software development, databases, CGI, etc). In its current state, I'll be looking for the "run as Win 7" hack.

Metro for Dummies Part 4

2011-07-25T21:12:00.000+01:00

I've adjusted my font sizes, along with my target screen size (1280 x 720).

I'm now going to turn my attention to my colour palette.

Picking your Palette
Because your Metro design is minimalistic, selecting the right font and palette is crucial for the whole design to work.

There are plenty of resources on the web which details the science of colour and colour combinations. I tend to pick my palette based on what looks good or what works. I know this is not terribly precise, and there probably is a methodology to do this.

I like to work with tools like Kuler.

I don't think there is any right or wrong here. Similiar to picking your font, you need to play with it until it seems right.

For my sample application I've chosen this palette for my black background.

Applying my colour palette to my mock-ups...

Next, I will need to nail down colour conventions for various controls and states (Hover, Disabled, Invalid, Selected, etc). This may require expanding my palette, but should not require additional core colours.

Until I am satisfied with a full application screen mock-up, maybe a search screen with search results and a detail dialog, the colour assignments are likely to get shifted around. I think consistency is probably more important than precision when working this out. I'm sure you could find an expert to tell you this colour should or shouldn't be used with that colour. But, at the end of the day, it's about what your client likes and fulfilling the purpose of the application.

Metro for Dummies Part 3

2011-07-24T20:35:00.001+01:00

Font Sizes

Once I've selected my base font I then work out font sizes. This is best done in Photoshop or other graphics application. I prefer to use a Word/HTML/CSS styled naming convention for my font size (H1, H2, H3, etc).

This is often influenced by the target device. In the example above, I'm targeting a laptop/desktop device with a minimum screen resolution of 1024 by 768.

I'll then mock-up some sample uses of these fonts and sizes, still working in Photoshop. This gives me a feel for the sizes, screen real estate and spacings. I'm not sure what you would call this? Feng shui, for a lack of better term. But there seems to be a natural balance of content, space and function.

I usually do this without using a colour palette. I don't want the colours to bias my perception of the content and space. Once I apply my palette, it should enhance my design. But my design should not depend on the palette. So, I make it work without one.

Do as many mock-ups as needed. Time spent in Photoshop is well spent. I find that the simplicity of Metro makes this process quick and painless. What you're really doing is establishing UI conventions for your application.

Metro for Dummies Part 2

2011-07-24T16:32:00.001+01:00

Font Samples

The following is a collection of fonts which are primarily used for public signage. Not all of these would be suitable for a Metro-styled user interface, but will give you some ideas on selecting a base font for your design.

Austria

Brusseline

Calvert

Casey

Clearview

DIN 1451

Drogowskaz

FF Meta

Frutiger

FHWA Series fonts

Futura

Gill Sans

Helvetica

Helvetica Neue

Johnston

Motorway

Myriad

NPS Rawlinson Roadway

Parisine

Rail Alphabet

Rotis Serif

Toronto Subway Font

Transport

Tratex

Univers

Metro for Dummies Part 1

2011-07-24T14:51:00.004+01:00

I have been experimenting with Microsoft’s Metro Design Language for the past couple of months, and wanted to share some ideas and tips I’ve picked up along the way. I do not claim to be an expert on the subject, nor do I consider myself to be a visual designer. I know what I like, but not always able to tell you why.

For those unfamiliar with Metro here is a good place to start:

Metro Design Language of Windows Phone 7

I do not recommend Metro Design Language being sold by Amazon. It is a self-published book which contains about three pages on Metro UI and the rest is a copy and paste from Microsoft’s back catalogue. At £29.00 it is quite simply, a rip-off.

Most references on the web speak of Metro and Windows Phone 7 in the same breath. While it is true WP7 does incorporate the Metro design philosophy, it is however not alone; Zune, Xbox 360 and Windows Media Center utilise Metro to a greater or lesser degree.

What is Metro?
Metro is an internal code name for a typography-based design language created by Microsoft.

Microsoft defines Metro as..
Typography. Type is beautiful. Not only is it attractive to the eye, but it can also be functional. The right balance of weight and positioning can create a visual hierarchy. Additionally, well placed type can help lead you to more content.

Motion is what brings the interface to life. Transitions are just as important as graphical design. By developing a consistent set of motions or animations, a system is created that provides context for usability, extra dimension and depth and improves the perceived performance of the whole interface.

Content not Chrome is one of the more unique principles of Metro. By removing all notions of extra chrome in the UI, the content becomes the main focus. This is especially relevant due to the smaller screen size and gesture-based interactions.

Honesty. Design explicitly for the form factor of a hand held device using touch, a high resolution screen and simplified and expedited forms of interaction. In other words, be “authentically digital”

Gone are the days of Microsoft's User Interface Guidelines for Windows with its precision pixel specifications. Metro represents a dramatic shift away from UI design. Metro is much more fluid and dynamic.

Picking a base font
Since typography is central to a Metro design it's good to start with a nice clean font. Your target device may influence what type of font you use. My personal favourites, which look great on mobile devices as well as the desktop are:

Seqoe WP

Avenir

Segoe WP is a member of the Segoe font family specifically designed for WP7

Since Metro borrows heavily from civic and urban design, it is not surprising to find this last font used by the City of Amsterdam, as well as the Dallas airport and Hong Kong airport.

In many ways the design goals of public signage and Metro are alike. They both seek to provide instant communication in a clean, unadulterated way. The “user” has but seconds to understand and duplicate some piece of information while travelling down the motorway or while on a high-speed train. Likewise, we want to provide instant understanding for our mobile user, often at a glance.

I have to admit this whole area of typography is somewhat addictive. If you can recognise the aesthetics of the font, searching and viewing fonts can be time consuming; there are so many fantastic fonts to choose from.

If you’re interested, this is a good jumping off point:

Signage Typeface at Wikipedia

You have been warned.

It is worth spending some time selecting your font. It is going to dominate your Metro design.

MVVM Revisited

2011-04-07T07:22:00.004+01:00

I have been working with MVVM and Prism for a couple of years now and have had some recent revelations which you may find useful. Working with MVVM by itself, is relatively straightforward. Combine it with other patterns, such as MVC and IoC, and things can get complicated.

Here is a common implementation of MVVM:

This example also utilises a CustomerController along with some services, all of which are supplied by the “Model”. If you’ve worked with Prism you’ll probably recognise this rather unorthodox implementation of MVC, something I’ve never been comfortable with. Injecting a controller into a ViewModel seems backasswards to me. I would prefer to have the Controller be aware of the ViewModel and indirectly control/manage the Views.

Aside from being awkward, this approach does work. But don’t expect your modules to be “modular”. Sure, within your solution it will have the appearance of being a module, but it won’t very portable. If you’re persistent and are dedicated, you can try to “reuse” the Customer module above, but be prepared to drag a half dozen dependent assemblies with it.

So, what is modularity without portability? Without portability, modularity is reduced to a code organisation concept.

Looking over this situation it occurred to me that the injection of dependencies in the ViewModel was pretty much unrestrained. If the ViewModel needed it, just add another parameter to the constructor. The entire Model was wide-open for consumption, provided it was registered with Unity. Needless to say, this leads to greater and greater consumption, until finally the ViewModel is entrenched in implementation.

When viewed as a microcosm, MVVM can act like a tiered architecture. And tiered architectures are great for scalable server applications, but pretty much ruin any hopes of portability.

The other undesirable aspect of this is, while the ViewModel may require the ability to display a MessageBox (provided by the IMessageService), it has no use for the other 10+ methods provided by the service. So, why not give it exactly what it needs – and no more.

One way to accomplish this through the introduction of a custom Model class:

Here the CustomerModel class defines exactly what the ViewModel demands of the Model. In effect, it is a subset of the Model and is specific to that ViewModel. It’s the ViewModel’s shopping list – “if you’re going to use me, this is my list of demands”. It is now up to the implementer to provide this functionality – which is where the responsibility belongs.

With this approach the ViewModel has now been liberated and all of the “dependencies” removed. Service methods have been replaced with delegates. The ICustomerService can reside in the module itself, effectively making the CustomerModule a self-contained, standalone assembly.

A side benefit is that the View now contains no code-behind and is no longer dependent on the ViewModel interface.

While working through this I’ve created a new Prism sample solution, which includes a CustomerModule and an OrdersModule, Implementation project and a Shell. I have reduced the module dependency down to a single Core assembly. The Implementation project contains controllers, core services, a persistence manager, etc. It knows about the modules and can orchestrate the workflow and manage the views. The controllers “wire up” the Model and inject them into the ViewModels.

At the moment, CustomerModule + Core is about as portable as it gets.

When isCode != Code?

2010-10-17T13:18:00.010+01:00

You could say there are as many different coding styles as there are coders. One in particular I find perplexing is the "inverse logic" approach. I knew a developer to seemed to think 180 degrees from everyone else on the team. Allow me to explain...

If we were designing a custom control, you may expect to find an IsVisible property. This "inverse coder" would prefer an IsHidden property. IsEnabled becomes IsDisabled, etc.

Within a method you may see something like:

public void SomeMethod()
{
   if(isSomeFlag)
   {
   //do something meaningful...
   }
}

Our "inverse coder" would see it like:

public void SomeMethod()

{

if(!isSomeFlag)

{

return;

}

//do something meaningful...
}

My personal preference is to limit the number of exit points in a method, as in the former. In complex methods, this individual would have several exit points all based upon some inverted logic. Did it work? Technically yes. Was it intuitive and easy to follow? Most times not. The rest of the team, knowingly or unknowningly had to continually shift mental gears when debugging this code. Based on this fact alone, I would say this is bad code, since it was inherently difficult to understand.

Another example...let's say you want to write a method which processes an order, something like:

public void ProcessOrder(IOrder order)

{

if(order.Status == OrderStatus.Open)

{

//order processing logic here...

}

Pretty straightforward. Our inverted coder sees it completely different, and goes has far to pervert the name of the method itself.

public void ProcessNonOpenOrder(IOrder order)

{

if(order.Status == OrderStatus.Open)

{

return;

}

Difficult where to begin to say what is wrong with that, other than it is more complicated than it needs to be. As a coder I would expect to find an additional ProcessOpenOrder method to compliment this one, unfortunately not.

Another common inverse is:
if(null == someInstance)

as oppose to the more generally agreed upon:

if(someInstance == null)

or, my personal pet peeve:

if(0 >= myCollection.Count)

I simply have a bone-deep rejection of this. And whenever I encounter it I have to stop and think about what it means. Perhaps this is due to my own training patterns, years and years of well established coding practices, commonly agreed upon by most coders. And I have to ask "What is the advantage of this? What does it buy me to do it this way?" I've searched and cannot find a reason.

I always strive to make my code simple, obvious and self-documenting. Cryptic code is bad code, complex code is bad code. When writing code as part of a team, self-expression or personal preferences have nothing to do with it. What is important is that it is in alignment with the standards and practices of the rest of the team.

Including the way they "think".

Update

2010-09-20T11:01:00.001+01:00

After months of defect resolution and testing our code finally shipped this morning. The effort to deliver this product was beyond anyone's estimation. The difficulty was not so much on the .Net front, but more in the area of system coordination.

Some background...we set out to develop a WPF/Prism application which would be run on a mobile handheld device (think fat, rugged iPad). That, in itself, is not terribly difficult, it was everything else that proved to be challenging. Namely four separate SAP systems, all contributing data which get bundled up and distributed to the mobile device via SAP's NetWeaver. And then back up again...

On a good day it's hard enough to get SAP to play with SAP, raise that to the fourth power and add SAP's own client synchronization framework in the mix...well, you get the idea. It's a minor miracle it works at all.

This is my second large SAP/.Net development project, and this one being the largest and most complex of the two. Now, I'm the first to admit that I can be a techno-bigot. I love working with C# and .Net and frameworks like Prism and MEF. There is a real elegance that can be achieved and when you get it right it's poetry in motion.

Compare that with SAP...well, it's a dinosaur. A plodding, kludgey artifact from the Stone Age. I'm sorry, it's not my intention to offend, but it's true. I sometimes wonder how long SAP can continue, while the rest of the world races ahead with more and more sophisticated development tools? Not to mention the inherent complexity and true cost of ownership.

That said, I can say SAP does what it says on the tin, often times with a half dozen SAP Consultants hovering over scratching their chins. I have to admire these guys, namely because they have the patience and persistence to work with these types of systems. I don't know if I could do what they do. If the technology I'm working with becomes too restrictive or cumbersome or complex I simply find another. Not so in the world of SAP. What you see is what you get...warts and all.

Enough of that. In the end, after shedding blood, sweat and tears, we got there and it was a real team effort of two very different IT cultures.

Now onto version 2...

Some Observations...

2010-05-03T19:03:00.000+01:00

Sorry for neglecting this blog, I'm in the throes of delivering a large mobile application, which has consumed all my waking hours.

In our big push to get this product out the door, we've brought on-board additional developers. Unfortunately, they were not sufficiently grooved in to our architecture and coding standards. As you can imagine, the result was less than expected. One of the purposes of having a known architecture, in my opinion, is that it serves as a point of agreement within the team. It defines where things are located, what function it performs, what its relationship is to other parts of the system. In short, it establishes order and structure to a large number of projects and should bring about simplicity.

When someone does not adhere to the agreed upon architecture they can be counted upon to introduce complexity. To the uninitiated faced with a solution with 40-50 projects, all is complex. Any changes they introduce will undoubted contain that complexity.

On a similar note, regarding WPF....

Whenever I see Xaml loaded up with Alignment, dimension attributes, etc, or StackPanels within StackPanels within Grids within StackPanels...ad nauseum, I know what the developer was experiencing. He is using more and more settings and properties to force the Xaml to behave a certain way. This brute force approach always bloats your code and is always inefficient. If the UI does not bend to your will, the compulsion is to add more settings - this is almost always a mistake.

My golden rule when working with Xaml is: Less is More.

If I'm faced with sorting out some misbehaving Xaml, the first thing I do is delete all the unnecessary properties and work with the core object.

Anyway...just some observations. I'm hoping to be more active on this blog once I've completed this current project.

One new development effort I've been working on in the evening, is creating a Win 7 Media Center Add-in using Visual Studio 2010 and the Media Center SDK. It's my first attempt, so I hope to have something worthwhile to report.

New Composite/Pattern Forum

2010-03-24T13:03:00.000Z

A new developer forum has been launched dedicated to composite technologies and design patterns, including Prism, MEF and MVVM.

http://www.compositedevpatterns.com/forum.php

Prism Guidelines

2010-02-10T15:29:00.011Z

Introduction
Due to the number of projects and files which can make up a Prism solution, it is important to adhere to conventions which are intuitive and sensible. Maintaining these conventions takes the guesswork out of working with Prism and makes navigating through a solution predictable.
This document assumes a basic understanding of Prism, the Model-View-ViewModel (MVVM) design pattern, the Model-View-Controller (MVC) design pattern and Windows Presentation Foundation (WPF).

Modules
Prism requires that each module contain a class which implements IModule. This effectively serves as a stub, allowing Unity to load the module. IModule has an Initialize method that is often overridden and is used to register items in the container.

Avoid using the Initialize method to register the module’s items, instead create an entry in your unity.config file. It is easier to maintain and does not involve code.

Views

GOAL: To maintain a separation of UI and business logic.

It is rare that a UI requirement cannot be expressed using Xaml alone. Effort should be made to eliminate any UI logic contained in the View.

Views always have a corresponding ViewModel.

Setting the ViewModel

Each View should contain a setter for its ViewModel, as shown below.

This property uses the Microsoft.Practices.Unity.DependencyAttribute, which gets picked up by Unity and automatically set.

Use of Styles

Avoid defining custom styles which effect appearance within your module or view. Instead, use styles defined in your application resource assembly. If you need to modify a control’s behaviour through the use of a Trigger, use the BasedOn property of the Style, referencing the resource Style.

Always reference the resource Style by using a ComponentResourceKey defined in your Interfaces assembly.

Style="{StaticResource {ComponentResourceKey TypeInTargetAssembly={x:Type Resources:Styles}, ResourceId=DialogBorderStyleKey}}"

Use of Converters

Avoid excessive use of custom converters (IValueConverter). Often the same can be accomplished using Triggers or DataBinding. Converters can act as “hidden” code-behind, making testing difficult. Always look for a Xaml solution before resorting to the use of converters.

Naming Conventions

TYPE	NAMING RULE	EXAMPLE
View	<name>View	CustomerDetailView
Interface	I<name>View	ICustomerDetailView

ViewModels
GOAL: To encapsulate all UI-related logic in a single, testable class.

The ViewModel exists to serve the View, so use it. Instead of using custom Converters do it in your ViewModel.

Avoid passing the IUnityContainer (or an abstract version) in your ViewModel constructor. This hides the actual dependency and makes testing difficult.

Consider implementing INotifyPropertyChanged on your ViewModel so your View can respond to changes in the ViewModel.

Naming Conventions

TYPE	NAMING RULE	EXAMPLE
ViewModel	<name>ViewModel	CustomerDetailViewModel
Interface	I<name>ViewModel	ICustomerDetailViewModel

Interfaces
GOAL: To provide contracts that define a public interface, separate from its implementation.

Prism relies heavily on the use of interfaces. All entities registered in the UnityContainer must include an interface and an entity that implements the interface.

Do not include public interfaces in your implementation assemblies, as this defeats the purpose of decoupling interface from implementation.

UserControls
GOAL: To provide reusable UI elements independent of implementation.

WPF UserControls differ from Views in that they do not have a related ViewModel.

Consider adding DependencyProperties to your UserControl to take advantage of DataBinding and Triggers, this makes your UserControl more versatile and reusable.

Avoid including binding to specific properties in your UserControl as this can greatly limit its reuse.

Naming Conventions

TYPE	NAMING RULE	EXAMPLE
UserControl	<name>UserControl	AddressUserControl

Services
GOAL: To provide static, stateless business logic and functionality across domains.

Services are normally registered in Unity as a singleton.

It is best to think of Services as a static library of methods. If state persistency is required consider using a Controller (MVC pattern).

When consuming Services, avoid accessing them through IServiceLocator, instead explicitly use the service interface in your class constructor. This makes for predictable testing and does not hide functionality or dependencies.

Naming Conventions

TYPE	NAMING RULE	EXAMPLE
Service	<name>Service	LoggingService
Interface	I<name>Service	ILoggingService

Events
GOAL: To provide multicast notifications across domains.

Note: The events referred to here are to be used by the EventAggregator, not standard .Net events.

Do not define events in your implementation assemblies. Since other assemblies will need to reference your event class placing them in an implementation assembly forces you to create a strong reference. Instead, place it in your interface assembly or, if appropriate, a shared core assembly.

Naming Conventions

TYPE	NAMING RULE	EXAMPLE
Event	<name>Event	SaveCustomerEvent
Handler	<name>EventHandler	SaveCustomerEventHandler

Commands
GOAL: To provide an input mechanism which allows for multiple and disparate sources to invoke the same command logic.

Include command logic in your ViewModel, or if using a Controller you may want to defer execution to the Controller.

Consider using a Command Behavior AttachedProperty to convert events to Commands on controls that do not natively support ICommand.

Naming Conventions

TYPE	NAMING RULE	EXAMPLE
Command	<name>Command	SaveCommand
Handler	<name>CommandExecute	SaveCommandExecute
	<name>CommandCanExecute	SaveCommandCanExecute

Conclusion
Prediction and consistency go a long way in working with Prism. Not subscribing to agreed upon conventions adds confusion and slows down development.

Code Complexity and Prism

2010-01-25T21:40:00.001Z

I've recently had to review a number of problem areas of a large Prism project. In the course of review, I had a number of realisations regarding design patterns, WPF and code complexity. We use MVVM and MVC design patterns throughout our project. Not surprising, many of our problem areas were related to divergence from these patterns.

In our implementation of MVVM we strive to have a complete decoupling of our Xaml views and any business logic. So, finding views riddled with code-behind indicated a lack of understanding of:

The MVVM design pattern, or
The benefits of code separation

Or as I was to find out, a limited understanding of Xaml. The view in question utilised over ten custom converters. Not that converters are inherently evil, however, these converters were being used where Triggers or Data Binding could have easily gotten the job done. But, if one is unfamiliar with these, they tend to use techniques they are familiar with -- in this case, IValueConverter. Poor use of custom converters effectively becomes "hidden code-behind," and is difficult to debug and test.

Additionally, I found the ViewModel being underused and misused, providing a sparse selection of high level properties for binding. This, in part, prompted the excessive use of custom converters.

The offending code-behind was an unusual solution brought about by a lack of Xaml know-how. All of this code could have been expressed using Xaml. Conclusion: Knowing a little about Xaml can reek havoc on a well-structured Prism project.

The hallmark of these decisions is code complexity, your first clue things have gone astray.

After much refactoring, including the removal of all the custom converters, the code-behind and reworking the ViewModel, the whole area straighten out and was greatly simplified. It was a prime example of the power and importance of design patterns in maintaining good form and structure.

MEF Presentation Video

2010-01-02T01:09:00.001Z

A work colleague recently turned me on to Microsoft's Managed Extensibility Framework (MEF) [see http://mef.codeplex.com/]. For anyone into Prism, MEF is worth a look. Headed up by Glenn Block of Prism fame, MEF is an impressive technology.

Glenn gives an hour long MEF presentation at PDC 09 at http://microsoftpdc.com/Sessions/FT24.

In addition to an MEF orientation, there is a short presentation on MEF + Prism.

Exciting stuff, in a geeky sort of way.

Prism Sample: Resources

2009-12-27T11:23:00.003Z

An area of Prism development that often gets overlooked is the management of resources. I mentioned in a previous blog that View reuse is unlikely, but that doesn't mean you should create unnecessary dependencies to a resource assembly.

Similar to modules, resource assemblies can have an accompanying interface assembly. This is done by defining ComponentResourceKeys in your interface assembly and using them as resource keys in your resource dictionary and in your Views.

public static class Styles
{
    public static ComponentResourceKey LargeTextStyleKey
    {
        get { return new ComponentResourceKey(typeof (Styles), "LargeTextStyle"); }
     }
}

and in your Xaml...

<textblock text="My Sample TextBlock Style"
           Style="{StaticResource {ComponentResourceKey TypeInTargetAssembly={x:Type Interfaces:Styles}, ResourceId=LargeTextStyleKey}}" />

Taking this approach decouples your modules from the resource assembly. The advantage to do this is not so much in the area of reuse, but more in the implementation of themes. Any Views that require the use of a resource can simply refer to it by its ComponentResourceKey.

Additionally, I would only have the Shell load the external resources, since the View modules are now unaware of the external resource. The only draw back in doing this is you will lose your Visual Designer when editing your Xaml, because the designer cannot resolve the resource to render it.

It is also worth setting up default styles based on control types, by using the control type as the resource key (e.g. {x:Type TextBlock}). This does not require the use of ComponentResourceKeys.

The area of theming WPF applications is a common one and there are a number of resources on CodePlex which address this area. One example is the Razre WPF Framework, or you can build your own ThemeManager.

Conclusion
I think this pretty much concludes the PrismSample articles. This was meant as an introduction for developers starting out with Prism and to provide some guidelines in setting up a Prism solution. I hope this was of some use. I'm certain others will have differing opinions, and that's okay too. I'm always on the hunt for new approaches and new ideas.

I think Prism has a real future in WPF development. Once you get into it and see the benefits, it changes how you think about and view WPF development; afterwards it is difficult not to think and develop that way, which is a good thing.

As always, comments/feedback welcome...

Prism Sample: Services

2009-12-26T16:32:00.002Z

In addition to Views and ViewModels, your Prism application will likely have one or more Services. Per the CAL documentation, a service is defined as:

A service is an object that provides functionality to other components in a loosely coupled way through an interface and is often a singleton.

This is a fitting definition, but doesn't indicate belongs in a service or when something should be service. Services reside outside the View-ViewModel pattern and provide functionality to anything that needs it. In practice a service should address an area of business logic and have an appropriate name which describes the functionality it contains, like CustomerService or DataService, etc.

Avoid making a service a dumping ground for functionality you don't know where to put. I tend to view services as static libraries of functionality, generally consisting of methods (think WCF Service Contracts). My personal preference is to avoid storing state or exposing properties in services. I don't use services to control workflow. Instead I would implement a Controller to govern the workflow, and have the Controller consume the service.

On one Prism project, we would have regular design meetings where we would discuss where a given piece of functionality should reside. The governing rule that came about, was that the ViewModel is directly concerned with the View and servicing the View; code that belongs in the ViewModel is there because of some requirement dictated by the View. If that wasn't the case, we were probably looking at a general piece of business logic which likely belonged in a service (or Controller, if one existed).

Following this line of thinking, we found more and more of our code moving to services, until we had a robust services layer, and a lean ViewModel which simply became a consumer of the services. This approach prevented business logic getting lost or hidden in ViewModels. It also supported our decision to separate out our services into their own assemblies, which I would highly recommend.

Prism Sample: Modules

2009-12-20T12:17:00.003Z

Central to Prism is the concept of modules and modular design, therefore it's worth spending some time defining exactly what a module is, what it contains and what it shouldn't contain. Per the Prism documentation:

A module in the Composite Application Library is a logical unit in your application. Modules assist in implementing a modular design. These modules are defined in such a way that they can be discovered and loaded by the application at run time. Because modules are self-contained, they promote separation of concerns in your application. Modules can communicate with other modules and access services in a loosely coupled fashion. They reduce the friction of maintaining, adding, and removing system functionality. Modules also aid in testing and deployment.

Having worked on a number of Prism projects with a wide range of developers, each interpreting this from their own perspective and experience.

Two of the guiding principles behind this are:
Single Responsibility Principle
Separation of Concerns

While most can agree on these principles, views differ on the depth and extent to which they are applied. On one end of the spectrum we have the theorist, whose motivation may be to strictly adhere to these (some times with religious fervor). And on the other end we have the realist, who simply wants to build a working piece of software that meets the business requirements.

The theorist looks beyond the business requirement, while the realist may argue that strict allegiance to these principles is outside the scope of the requirements. Somewhere, somehow these views are resolved, usually by an architect or team lead; and the result usually falls somewhere in the middle.

Personally, I fall in the middle, and maybe lean towards the realist. I don't feel software development should be an academic exercise. If someone entertains the idea of using a certain design pattern, I'm always interested in "what problem does this solve?" and "what does it buy me?" Unacceptable answers are "because Fowler said so" or "because that's what the Prism team does".

Enough of this, let's talk about modules...

In an earlier post, I talked about creating an Advertising module for Blogger and said I would create the following modules:

Blogger.Advertising.Interfaces
Blogger.Advertising.Views
Blogger.Advertising.ViewModels
Blogger.Advertising.Services
Blogger.Advertising.Services.Interfaces

Some developers would be tempted to bundle these up into two assemblies:
Blogger.Advertising
Blogger.Advertising.Interfaces

storing their Views, ViewModels and Services in a single assembly.

And I could be convinced of this. It's certainly easier to maintain. But I would argue that Views/ViewModels and Services are logically separate and warrant their own assemblies. It's not inconceivable that another module or system could be a consumer of these services, without the need for Views or ViewModels.

So, why separate out Views from ViewModels?

I think it is somewhat idealistic to expect Views designed for Product A to be simply dropped into Product B (two different implementations). In theory this is possible, but in practice I've never seen it happen. Here we get into areas of look and feel and layouts. While we can do a lot to make a view generic and use themes and skins to alter its appearance, at the end of the day there is always going to be something different or required which makes the view unusable. So why bother?

I always assume my views are not going to be reusable; that they're part and parcel to a specific implementation. My ViewModels, however, are completely reusable. I would also argue that mocking up Views is far less time consuming than the creation of ViewModels.

Regardless of what I think, your design decisions are going to be driven by a number of factors. I think its important to consider all views and options, and decide which is suitable.

Prism Sample: Basic Concepts

2009-12-17T22:14:00.007Z

As stated in my earlier post, this model solution attempts to illustrate how Prism and Unity are used, what is a module, what belongs in one and what doesn’t, the use of interfaces and design patterns.
One of the most basic aspects of code organisation is knowing “what goes where”. This is especially true with Prism projects. Given you will likely have a dozen or more projects in your solution, it’s pretty important to sort out early on where things belong.
I always try to minimise dependencies between my assemblies; and from time-to-time work-out what would be required to take a module and drop it into another application. I’m always looking for ways to remove a dependency or decouple. Even if I don’t have an immediate requirement to do that, as a general rule it’s a good idea.

Namespaces
Picking the right naming convention for your projects and namespaces is pretty important. I would spend ample time on this before embarking on any serious coding. Maybe start with a prototype solution and put in some basic modules, a shell, some services, and their accompanying interfaces. Play around with it and massage it into something you're comfortable with. I think there is a natural order and organisation for these various projects and components.

Microsoft's recommended namespace convention is:
Company.(Product|Technology)[.Feature][.Subnamespace]

for example, if I were creating an advertising module for Blogger, I would see something like...

Blogger.Advertising.Interfaces
Blogger.Advertising.Views
Blogger.Advertising.ViewModels
Blogger.Advertising.Services
Blogger.Advertising.Services.Interfaces

Microsoft has an excellent guideline for create .Net components at: http://msdn.microsoft.com/en-us/library/ms229026.aspx

Implementation vs Interface
It's important to understand the difference between implementation and interface as it applies to modular development. An interface is simply a public contract that defines an exposed surface. Whereas, implementation deals with the deploy or realisation of the interface. Interfaces do not contain business logic, simply a definition of what something will look like once it is implemented.
Prism and Unity makes heavy use of interfaces. Interfaces are mapped to your implementation classes, either in code or in a configuration file.

The following tips may be obvious to some, but I felt it was worth mentioning:

Tip #1 - Do not create strong references to implementation assemblies.
The exception to this are assemblies which comprise your Model.

Tip #2 - Do not place anything in your implementation assemblies which forces other assemblies to create a strong reference.
An example of this are Event classes. You may have a module which publishes events, presumably to be subscribed to by other modules. Do not include the Event class in your module assembly, instead place it in your module's interface assembly. This makes it available to other assemblies though the interface reference. Another common example are enumerations.

Tip #3 - Do not register your implementation classes in the Module Initialize method.
Registering classes in the Initialize method implies a specific implementation, but not all implementations. Instead map your classes in a Unity configuration file.

Tip #4 - Do not inject views into regions in the Module Initialize method.
I never understood why anyone would want to do this, as it pretty much ruins any chance of reusing the module. Instead, delegate view orchestration to another module, layer or layout manager.

In fact, I can't think of good reason to put any code in the Module Initialize method.

These tips address some hidden or covert implementation that commonly occurs in Prism development.

Prism Sample: Introduction

2009-12-16T21:38:00.002Z

I had a request to post some sample code illustrating the use of Model-View-ViewModel pattern, Controllers and DelegateCommands. This lead to the creation of a sample Prism solution. An interesting exercise, since it gave me a chance to incorporate many of what I consider to be Prism best practices.
I consider proper solution setup and organisation to be critical in working with Prism. Mistakes made in this area often come back to haunt you. There are many ways to organise your projects and code. What is probably more important is pick a solution structure that everyone can agree with and stick with it. A lack of agreement or ignorance of architecture can make team development a nightmare.

I intend to write a series of postings detailing out what I consider to be areas of interest, and why I've organised things as I did.
You can download the solution here (408kb). You will require Visual Studio 2008 SP1. I've stripped out all XML documentation and PDBs to keep the file size down.

Please let me know if you run into any problems loading and running this solution.

Some Agile thoughts...

2009-12-03T22:08:00.001Z

Is it me, or have others found Agile development projects to be chaotic? I will not profess to be an expert in this area. I've been a developer on about four Agile-based projects, ranging from a handful of developers to a team of 20. And, on the larger projects, the more Agile is pushed the more chaos seems to result.

At worst it feels like a mad coding free-for-all, in an effort to meet development targets, while abandoning or ignoring coding conventions and best practices. The idea being, "if we just get the cards done...the project will get done".

I don't know how many times I've coded up a piece of functionality, written tests, etc., only to find weeks later, that someone else on the team "refactored" it, rendering it unusable. One step forward, two steps back. I've only really experienced this on Agile projects.

Don't get me wrong, when I first encountered Agile I felt it had merit; and I still do. But somewhere between theory and execution the plot can get lost.

I've always consider myself to be self-managing. You give me a spec and I will methodically design, develop, test and document it to a finished product. Maybe that's a bit old-school, but it got the job done.

I would be interested in what others think about this.

Win 7 Anti-Virus

2009-10-20T17:43:00.000+01:00

For those of you running Win 7, you may have found it frustrating finding a suitable anti-virus product. From experience, major players promoting Win 7 compatibility have proven anything but.
A friend told me about Microsoft's new Security Essentials, which handles anti-virus, spyware and malware detection. Best of all, it's free! You can download it here:

http://www.microsoft.com/security_essentials/default.aspx

Unlike other products, Security Essentials has a remarkably small footprint and has negligible impact on performance. Highly recommended.

The Golden Age of UI Design

2009-10-16T16:04:00.002+01:00

If you’ve been using computers as long as I have, you will be familiar with the evolution of Windows, from the humble 3.x on up to Win 7. A lot has changed over the years. As developers we have had to shift gears with each new incarnation. I’m probably dating myself if I mention Windows 3.1 and VB 3.0, but given the time, VB 3 practically ushered in RAD and allowed developers to create respectable UIs for the platform.

With regards to the Windows User Interface, I can still remember the release of Windows 95 and all the fervour it created. There were developers and IT pros complaining bitterly about the change, citing their preference for 3.1 and their dislike for the new battleship grey 95. Those of us who embraced 95 in all its greyness, found new UI controls in our toolbox, most notably the Windows Common Controls. Enthusiasts, like myself, poured over Microsoft’s Windows 95 User Interface Guidelines book, a tome containing pixel by pixel specifications for creating standard Windows applications.

If you were like me, this wasn’t enough. The next rung on the ladder was exploiting (some times questionable) Win API and GDI hacks, all in the attempt to enhance our application interfaces.

The advent of .Net put an end to much of this. Designing WinForm applications certainly got easier and custom UIs no longer required slimy hacks. But, we were still limited to XP styled desktop applications.

Concurrent with the advancements in Windows programming, the internet exploded and took centre stage. Graphic designers and illustrators sat side-by-side with application developers to create a new breed of user interface. User expectations were raised; not only did a UI have to be functional, but it had to be sexy as well. Flash and Shockwave designers and developers expanded this further, raising the bar even higher.

All of these advancements made WinForms look rather antiquated.

All this was about to change with the release of .Net 3.0 and the introduction of Windows Presentation Foundation (WPF). For those unfamiliar with WPF, WPF is a XAML-based framework for creating Vista-styled desktop applications. Think XHTML meets WinForms and you’re almost there.

Not only was WPF structurally different from its WinForms cousin, but included new resources and functionality WinForm developers only dreamed of. At last, desktop developers could create dynamic, sexy user interfaces that rivalled their contemporaries. The capabilities of WPF are so vast, that if you can dream it, you probably can build it.

Gone are the stringent interface guidelines dictated by Microsoft; in its place are new collaborations between graphic designers and artists and software developers to produce user-centric software. All-in-all, this change is rather liberating. Where its headed I don’t know; will it be different from the past? Guaranteed.

However, this is no Holy Grail. Designers and developers will still manage to produce repulsive, poorly designed software. But this is a chance we’re going to have to take.

Using OnValidate method in LINQ to SQL

2009-10-07T13:58:00.005+01:00

If you are using LINQ to SQL you may have noticed the OnValidate partial method.

public partial class Person : INotifyPropertyChanging,
                  INotifyPropertyChanged
{
     ...
     partial void OnValidate(ChangeAction action);
     ...
}

This method gets automatically called when the class participates in the DataContext SubmitChanges.

When working with LINQ to SQL classes I prefer to keep my code generated classes separated from any modifications or customisations. Normally, I will create a folder in my project called ExtendedClasses, there I can extend my business objects, giving them a <classname>.extended.cs file name. This allows me to regenerate my business objects without fear of losing these customisations.

So, in my extended class file I will include...

partial void OnValidate(ChangeAction action)
{
    if (action == ChangeAction.Insert)
    {
        //Do validation for inserts
    }
   
    if (action==ChangeAction.Insert ||
        action==ChangeAction.Update)
    {
        //Do basic validation for inserts and updates
    }
}

I avoid including any business rules in this class level validation, and stick to data related validation, such as field lengths, data ranges and required fields all based on my data model. Any validation errors get raised by throwing an exception.
Because the OnValidate method is private, you may want to include a public Validate method.

public void Validate()
{
    if (PersonId==Guid.Empty)
    {
        OnValidate(ChangeAction.Insert);
    }
    else
    {
        OnValidate(ChangeAction.Update);
    }
}

With the public Validate method I can validate my business object from the UI layer before passing it down to my services layer.

try
{
    person.Validate();
}
catch (Exception e)
{
    MessageBox.Show(e.Message + "\n\n" + e.StackTrace);
    return;
}

UK Post Code Search using LINQ to XML

2009-09-15T17:36:00.002+01:00

I recently delved into working with UK Post Codes, including validation and searching. This is not my first contact with this area, and in the past it has always involved large SQL tables or by using third-party products.

This time, I was looking for something a bit more portable, like XML.

I was able to find freeware downloads of UK Post Codes including their longitude and latitude, which was easily imported into a SQL Server database.

I've created a class library called PostCodes.UK, which contains useful methods for validating post codes and determining which post codes fall within a given radial distance from a target post code. All of the search and validation routines utilise LINQ to XML to query the XDocument.

The class library relies on a PostCodes.xml file (supplied in the Test Harness project), which gets loaded as an XDocument. I've included a small WPF Test Harness application which illustrates how this library is used.

To run this solution you will need Visual Studio 2008 SP1. The source code is available here.

For those interested in this area, there is an informative government page on Postal Geography, which explains the structure of the UK post codes. You should be aware that UK post codes are always changing; however, if all you need is outward code resolution (e.g. PO6 ), chances are you can make do with public domain data.

Another site with useful information is: http://www.easypeasy.com/guides/article.php?article=64

Juan Enriquez Video

2009-09-10T18:46:00.000+01:00

A friend recently sent me this link to a presentation made by Juan Enriquez on TED.

http://www.ted.com/talks/juan_enriquez_shares_mindboggling_new_science.html

Enriquez has a unique viewpoint on recent global events, namely with the economy and technological advancements. And he has a sense of humour which appears to be a rare commodity nowadays.

Worth having a look.

IsIn Extension Method

2009-09-08T12:21:00.003+01:00

Another useful extension method I've found is the IsIn() method. This is comes in handy when you have to test for enumeration values, for example:

public enum StatusValues
{
 Open,
 Closed,
 Pending,
 Cancelled,
 Expired,
 Suspended
}

   ...

if(myObject.Status == StatusValues.Closed ||
   myObject.Status == StatusValues.Pending ||
   myObject.Status == StatusValues.Expired)
{  
   ...
}

This can become cumbersome when testing for a number of values.

The IsIn Extension Method simplifies this by taking a param list of values.

public static bool IsIn<T>(this T thisObject, params T[] values)
{
    if (thisObject != null && values != null && values.Length > 0)
    {
        foreach (var value in values)
        {
            if (thisObject.Equals(value))
            {
                return true;
            }
        }
    }

    return false;
}

Using this method, the above code can be rewritten as follows:

//using the IsIn Extension Method
if(myObject.Status.IsIn(StatusValues.Closed,
                        StatusValues.Pending,
                        StatusValues.Expired))
{
   ...
}

Retro Flip Clock WPF Control

2009-08-31T11:24:00.001+01:00

I know, I know...I last thing we need is another WPF Clock. However, I recently went looking for a Flip Clock control and found surprisingly few - in fact, no usable ones. So, it was back to the drawing board.

Most of the attention has been on appearance, rather than functionality. Feel free to modify and enhance.

You can download the source code with sample project here.

Ethics and IT

2009-08-26T22:25:00.007+01:00

I was recently offered employment at an investment bank in London, to which I respectfully declined. The agent I was dealing with was somewhat surprised and wanted to know why. I told him that I couldn't bring myself to work for the banksters. He was amused and replied "should my moral compass change..." the offer still stood. Interesting.

I never considered my moral compass to be so fluid, to actually consider assisting corporate criminals rape the general public. What? Bigger? Better? Faster? More Efficiently? I suppose I could find a way to justify it, but I couldn't see myself telling someone that is what I did for a living.

I, like the next guy, seeks to be well rewarded for their work. That doesn't automatically mean I do anything just because the rate is high. I consider my services to be valuable and the products I produce hopefully forward the goals and aims of my client. I mean, why do it at all if some good doesn't come out of it?

I was discussing this point with some friends; where do you draw the line? I knew where my line was. But it occurred to me that I shouldn't assume everyone has or is even aware of "The Line". That there may be some people in the IT industry who will simply work on any project provided the price was right.

Would you design software which assisted a pharmaceutical company to develop new mind-altering drugs which may result in suicide or mayhem?

Or how about software which controls a guided missile that has an impressive kill-ratio? (no, it's not the X-Box)

No? Well somebody does.

Now, these are not new questions. While at engineering school we had a Technology and Ethics course, but it never delved into these types of issues (which may have had something to do with the Department of Defence contracts). Maybe no course can answer these questions, maybe only you can come up with an answer you can live with.

So, in addition to the legalised drug pushers and the war-mongers we add a new villain (well, not new, just newly exposed) - the Banker, purveyors of economic chaos and destruction. The respected banker, pillar of the community. Lovely.

If your love of banking is so strong, why not work for the Financial Services Authority? I hear they're quite busy and need all the help they can get.

Layout Manager for Prism v2

2009-08-25T12:32:00.010+01:00

One of the issues you may encounter when working on a Prism project is the management of regions and views within your application. While the RegionManager does an adequate job of managing regions, the orchestration of views and regions is pretty much left up to the developer.

A common approach is to define string constants in a common infrastructure assembly and injecting views into regions using these constants. This gets the job done, but adds rigidity to your application. For applications which require multiple layouts, coordinating regions and views can be a bit tedious.

One common approach I would not recommend is injecting your views in your module's Initialize method.

public void Initialize()
{
    var view = new MyView();
    _Container.RegisterInstance<IMyView>(view);
    _RegionManager.Regions[RegionNames.Shell].Add(view);
}

This violates the encapsulation of the module, restricting the reuse of the module.

On one project, we opted to create a "layout module". The sole purpose of this module was to load a layout UserControl into the Shell region of the main application window, and injecting the views into its own defined regions. Definitely a step in the right direction by decoupling the module views from the regions. The layout module was defined and loaded like any other module, but had to be the last module loaded due to its dependencies. One drawback to this approach was the increasing number of dependencies. The layout module had to reference all the infrastructure assemblies of the views it was required to manage.

Still this solution felt a bit too purpose-built. And other issues quickly arose, such as multiple layout support. Ideally we were looking for a complete decoupling of regions and views with the ability to dynamically load layouts as required.

We quite liked the idea of using layout views, views whose sole purpose was to define regions, and providing no business or UI logic. But, the source and introduction of these views needed to be dynamic and flexible. The LayoutManager is my first attempt at tackling this issue. Its purpose is to dynamically manage one or more layout configurations for a Prism application.

To compile and run the LayoutManager you will need Visual Studio 2008 SP1 and the latest version of the Composite Application Guidance for WPF and Silverlight - February 2009.

The solution is fairly standard Prism solution, consisting of an Infrastructure, Shell and Modules projects. For the sake of simplicity, I've only included a single Modules project, where normally there would be more.

The LayoutManager maintains a collection of Layout objects, which define layout controls, along with the views that will reside in the layout.

Configuration
The LayoutManager is configured by a LayoutProvider specified in your app.config file.

<section name="layoutProvider" type="Composite.Layout.Configuration.LayoutProviderSection, Composite.Layout"/>

Currently, two providers are available: ConfigLayoutProvider and XamlLayoutProvider. Custom providers can be used by inheriting from LayoutProviderBase.

ConfigLayoutProvider
Defines the LayoutManager in the app.config file as shown below:

<layoutProvider name="ConfigLayoutProvider" type="Composite.Layout.Configuration.ConfigLayoutProvider, Composite.Layout">
    <layoutManager shellName="Shell" >
      <layouts>
        <layout name="FirstLayout" 
              filename="Layouts\FirstLayout.xaml" 
              fullname="First Layout" 
              isDefault="True"
              description="This is the default layout" 
              thumbnailSource="pack://application:,,,/LayoutManager.Infrastructure;component/Resources/Images/layout1.png">
          <views>
            <view typeName="LayoutManager.Infrastructure.IViewA, LayoutManager.Infrastructure" regionName="Left"  />
            <view typeName="LayoutManager.Infrastructure.IViewB, LayoutManager.Infrastructure" regionName="Right" />
            <viewModel typeName="LayoutManager.Infrastructure.IMenuViewModel, LayoutManager.Infrastructure" regionName="Menu"  viewProperty="View"/>
          </views>
        </layout>
        ...
          </layouts>
    </layoutManager>
</layoutProvider>

XamlLayoutProvider
Defines the LayoutManager in Xaml

The source of the Xaml can be specified by type or by filename.

<Layout:LayoutManager xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                      xmlns:Layout="clr-namespace:Composite.Layout;assembly=Composite.Layout"
                      xmlns:Infrastructure="clr-namespace:LayoutManager.Infrastructure;assembly=LayoutManager.Infrastructure"
                      ShellName="Shell">
    <Layout:LayoutManager.Layouts>
        <Layout:Layout x:Name="FirstLayout"
                       Fullname="First Layout"
                       Filename="Layouts\FirstLayout.xaml"
                       Description="This is the default layout"
                       ThumbnailSource="pack://application:,,,/LayoutManager.Infrastructure;component/Resources/Images/layout1.png"
                       IsDefault="True">
            <Layout:Layout.Views>
                <Layout:ViewModel RegionName="Menu"
                                  Type="{x:Type Infrastructure:IMenuViewModel}"
                                  ViewProperty="View" />
                <Layout:View RegionName="Left"
                             Type="{x:Type Infrastructure:IViewA}" />
                <Layout:View RegionName="Right"
                             Type="{x:Type Infrastructure:IViewB}" />
            </Layout:Layout.Views>
        </Layout:Layout>
 ...
    </Layout:LayoutManager.Layouts>
</Layout:LayoutManager>

Each Layout contains a Views collection. The views collection accommodates both Views and ViewModels. The View specifies what view control is to be loaded and what region it is to be placed in. You can also set the visibility for the view. Use the ViewProperty of the ViewModel to specify the name of the property on your ViewModel which holds the View.

The LayoutManager is loaded after all of the modules have initialized. In the Bootstrapper.cs:

protected override void InitializeModules()
{
     base.InitializeModules();
     InitializeLayoutManager();
}

private void InitializeLayoutManager()
{
     var layoutManager = LayoutConfigurationManager.LayoutManager;
     layoutManager.Initialize(Container);
     Container.RegisterInstance(layoutManager, new ContainerControlledLifetimeManager());
     //parameterless LoadLayout loads the default Layout into the Shell
     layoutManager.LoadLayout();
}

The LayoutManager requires use of the Container. Once your layouts have been loaded, call the Initialize method passing in the container.

Once that is done, you can register the LayoutManager in the container making it accessible to other modules.

Loading a Layout
Layouts are loaded by calling the LoadLayout method of the LayoutManager.

LoadLayout() loads the default layout in the Shell

LoadLayout(string layoutName) loads the named layout in the Shell

The MenuViewModel.cs illustrates the use of LoadLayout:

private void LayoutCommandExecute(ILayout layout)
{
var layoutManager = _Container.Resolve<ILayoutManager>(); 
layoutManager.LoadLayout(layout.Name);
}

The basic sequence of loading a layout is:

If there is a current layout, remove it from the RegionManager.
Clear out any controls that were bound to any regions. This step is necessary otherwise you will get an InvalidOperationException ("This control is being associated with a region, but the control is already bound to something else") when you try to reload it in the future. Currently, the LayoutManager only supports ItemsControls, ContentControls and Panels using the RegionManager.RegionName attached property.
Add the new Layout Control to the RegionManager.
Register any Regions contained within the Layout Control.
Load any views associated with the new layout.

Events
There are several events raised by the LayoutManager:

LayoutManagerInitializedEvent raised at the end of Initialize (see MenuViewModel.cs for an example of subscribing to this event)
LayoutLoadingEvent raised at the beginning of LoadLayout
LayoutLoadedEvent raised at the end of LoadLayout
LayoutUnloadingEvent raised before the current layout is about to be unloaded
LayoutUnloadedEvent raised after the current layout has been unloaded

All of these events are published through the EventAggregator.

Limitations
Currently there are several limitations with the LayoutManager, these are:
LayoutManager currently only supports UserControls as layout controls. There is also the basic assumption that your application main window has a single region defined, where layout controls are injected. Regions must be defined in XAML using the RegionManager.RegionName attached property.

Other Considerations
While the LayoutManager does decouple the regions from the views, it does not entirely do away with string-based region names. Dynamic manipulation of regions and views in code will still rely on region names (see the AddCommandExecute method in MenuViewModel.cs on how to programmatically add layouts). And region name attributes must match actual region names in the Layout control.

A possible approach to addressing this dependency may be to introduce a RegionType enumeration such as Top, Bottom, Left, Right, Center, StatusBar, Menu, Toolbar, etc. In which case, the LayoutManager could resolve these regions regardless of string names.

I have not tested the LayoutManager in all possible scenarios, such as nested layouts and custom RegionAdapters, or with Silverlight.

You can download the LayoutManager source code here.

StringBuilder Extensions

2009-08-24T13:58:00.007+01:00

I recently had a requirement to modify some Html-based reports. These reports were built up in code using a StringBuilder, along with report content data. The plus-point is that it worked and delivered the desired reports. On the downside, the code was tedious and verbose. For example:

StringBuilder stringBuilder = new StringBuilder();
stringBuilder.Append("<TABLE id=\"Table2\" width=\"100%\">");
stringBuilder.Append("<TR style=\"page-break-inside : avoid\"><TD class=\"reportHeaderTitle\" >" + ResourceManager.GetString("ReportTitle", culture) + "</TD></TR>");
stringBuilder.Append("<TR><TD style=\"PADDING-LEFT: 5px; PADDING-BOTTOM:10px\" width=\"100%\">");
stringBuilder.Append("<TABLE id=\"Table2\" width=\"100%\">");
stringBuilder.Append("<TR style=\"page-break-inside : avoid\"><TD class='reportHeader' align=\"center\" width=\"50%\">" + ResourceManager.GetString("ReportSubTitle", culture) + "</TD>");
stringBuilder.Append("<TD class='reportHeader' align=\"center\" width=\"50%\">" + ResourceManager.GetString("ReportResults", culture) + "</TD></TR>");
...

I was staring at 1000s of lines of code like this. After a while it was all a blur.

My first impulse was to subclass the StringBuilder and build up some Html-specific methods. Unfortunately, the StringBuilder class is sealed. I also looked at the HtmlTextWriter class, a class primarily used when working with custom server controls. But, this seemed overkill for the purpose. I just needed a clean way to build-up an Html string in code.

I then turned to writing a set of Extensions Methods to provide this functionality.

#region Using Directives

using System.Text;

#endregion

namespace Common.Extensions
{
    public static class StringBuilderExtensions
    {
        public static void BeginTable(this StringBuilder stringBuilder)
        {
            stringBuilder.Append("<table>");
        }

        public static void EndTable(this StringBuilder stringBuilder)
        {
            stringBuilder.Append("</table>");
        }

        public static void BeginRow(this StringBuilder stringBuilder)
        {
            stringBuilder.Append("<tr>");
        }
        ...
    }
}

In refactoring the code I first pulled all of the inline styles out and into style classes. Then I began migrating the existing code over to use the new extension methods. The refactored code looks something like this:

var stringBuilder = new StringBuilder();
stringBuilder.HorizontalRule();
stringBuilder.BeginH2();
stringBuilder.Append(ResourceManager.GetString("ReportTitle", _Culture));
stringBuilder.EndH2();

stringBuilder.BeginTable();
stringBuilder.BeginTHead();
stringBuilder.BeginRow();
stringBuilder.BeginCell("reportHeader");
stringBuilder.Append(ResourceManager.GetString("ReportSubTitle", _Culture));
stringBuilder.EndCell();
stringBuilder.BeginCell();
stringBuilder.Append(ResourceManager.GetString("ReportResults", _Culture));
stringBuilder.EndCell();
stringBuilder.EndRow();
stringBuilder.EndTHead();
...

In it's current state, the extensions only supply the Html tags that were required, but could easily be expanded to support all of the commonly used tags. I personally find this refactored code much easier to read and maintain.

You can download the StringBuilderExtensions.zip here.
I hope this may be of some use.

Extension Method Usage

2009-08-24T10:46:00.007+01:00

If you are like me, once you have the Big Extension Method Realisation you tend to go overboard on their use. This is eventually followed by the more practical Extension Method Usage Realisation. This second realisation puts Extension Methods into perspective.

For example, you could quite easily create an extension method like this:

public static bool IsNull(this object thisObject)
{
return thisObject == null;
}

This method can replace
if(myObject==null)

with...

if(myObject.IsNull())

But is it worth it? Is there anything wrong with myObject==null? Of course not. So why change it or replace it with an extension method. It adds no new functionality, just a change of syntax.
Additionally, you will often collect your extension methods and place them in a common assembly. Use of the above extension method creates an dependency on this assembly. But what does it buy you? I would argue, nothing. So, lose it.
From my experience in working with extension methods, I've found the most valuable to be methods that supply missing functionality or ones that encapsulate often repeated code.
An example of this is checking if a collection contains any items, kind of like a cousin of String.IsNullOrEmpty. For me, this is a prime candidate for an extension method, and should have been included in the IList interface (IMHO).

public static bool HasItems(this IList collection)
{
return collection != null && collection.Count > 0;
}

So we reduce
if(myCollection!=null && myCollection.Count>0)

to a clean and simple

if(myCollection.HasItems())

I know there is not a shortage of resources on the web regarding extension methods. However, after working with them for a few years, I have managed to collect a few "must have" extension methods, which I will be posting over time.

CodeProject Articles

2009-08-24T10:12:00.001+01:00

I have authored two CodeProject articles on WPF and Prism.

WPF Gadget Container Control
http://www.codeproject.com/KB/WPF/WPFGadget.aspx

Layout Manager for Prism v2
http://www.codeproject.com/KB/WPF/PrismLayoutManager.aspx

If you are interested in this area of .Net, check them out and let me know what you think.

Introduction

2009-08-24T09:33:00.001+01:00

This is my second blogging attempt, the first failed due to blogger's guilt. Now I have a renewed sense of purpose and dedication and have allocated time to make this a respectable blog. Round Two...