Pattern for Silverlight child window

RAVAGE


I just wanted to convey the enitre motivation of this article in a simple sentence which resulted in the 'keyword like' entry as the title "Pattern for Silverlight child window". As per my observation the UI approach (way of presentation to the end user) for Silverlight varies with that of ASP.Net UI. In most of the Silverlight applications that I visited, I didn't noticed the heavy usage of the child (popup) window for interaction purpose except the light usage of notification purpose such as confirmation / information display dialogs. If we do need to use the child window for interaction purpose, then the first idea that we need to plan is about how to share object between the parent and the child window.


I came across a similar situation in my project where my client wanted to present the child window for interaction purpose in order to produce a native UI approach. I thought of implementing this without breaking the MVVM pattern. To achieve that, first I thought of sharing the same ViewModel object between the parent and child. It got ruled out immediately due to well know reasons of maintainabiltiy and scalability. Not all the members of the object will be common for both parent and child window. Hence sharing same ViewModel / object won't be the right choice.

Next option is to have two seperate view models for parent and child dialog holding reference to each other. This is better than the previous one, but think of the case having more than one child window which will result in the parent holding reference to each of the child window and each child window holds reference to the parent. Going one step forward, think of a case having more than one parent view and multiple child view which are related, might end up with each object having reference to other as a worst case scenario. So, are there any pattern that provides solution for the above case? Yes, as many article over the web  suggests, Mediator pattern provides us the solution.

MEDIATOR FOR PARENT-CHILD VIEW

Mediator holds the instances of the parent and child objects and manage the interactions between the objects. The parent and child objects in turn holds the reference of the mediator and notifies the mediator about the relevant changes. Having received the change notification, the mediator will call the required update / action aginst the objects in relation to the change.

I implemented this change in my project and worked fine for me. But out of curiosity, I further fine tuned this implementation such that the parent and child view objects interact with the mediator using Observer pattern.

The implementation goes something like as follows:
I created an abstract class called Colleague which holds the instance for the Mediator as a property and an Update method which can be overriden by the class that inherits it.
Then I created an Mediator class which provides the methods to Attach, Detach and Notify. The Attach methods takes in an object of type Colleague as parameter and adds to a list of Colleague(to be notified). The Detach method takes in an Colleague type as parameter which removes from the list of Colleague. The Notify method iterates through the list of Colleague object and calls the Update method on each Colleague object.

The parent and child ViewModels inherits the Colleague class and overrides the Update method if needed. For example I was about to pass a selected item from my child ViewModel to my parent ViewModel. To achieve that upon selecting a particluar item from a list of items in the child view, I'll call the Notify method of my Mediator by passing the selected item. My parent ViewModel in its constructor will subscribe to receive the notification by calling and passing itself as paramter to the Attach method of the Mediator object. Upon the Mediator receives the notification from child view, it calls Update method of the Colleague (parent in this case) which got  subscribed to it.

STRUCTURE

SUMMARY

I actually have described an idea about the implementation in my project. Based on my project scenario, I had extended the same concept to handle multiple parent and child view models for which the usage of Observer pattern for interaction with the Medaitor helped me to produce a scalable and maintainable code. On the whole my idea is to implement a Mediator which acts as a change request manager holding the responsibility of interaction between the ViewModels. In my case, since I had only one change request manager (Mediator), I eliminated the introduction of abstract Mediator class. After completing my implementation, I realized that single instance for my Mediator holds good for my scenario. Hence, finally I also implemented Singleton pattern for my Mediator class.

System.Security.SecurityException: Dialogs must be user-initiated.

The Printing API in Silverlight 4 helps us a lot like printing the entire page, printing a specific portion of a page……

In order to get a quick idea on the print API do have a look at this(A look at the Printing API in Silverlight 4) article on silverlightshow.

While implementing this print API in my project I came across the following error in some scenarios.

“ System.Security.SecurityException: Dialogs must be user-initiated.”

This error message initially leads to lot of confusion and upon search found the cause. As all the developers do, I was debugging the code by putting breakpoint. The problem is I put the breakpoint over the line where the object initiation for PrintDocument happens. Something like……
 
 

 
So when the exception “ System.Security.SecurityException: Dialogs must be user-initiated.” got raised while using print API for Silverlight 4 in debug mode, ensure that you didn’t put breakpoint over the code that invokes the Print method.

REFERENCE

http://johnpapa.net/silverlight/printing-tip-ndash-handling-user-initiated-dialogs-exceptions/

System.ServiceModel.FaultException`1 was unhandled by user code

System.ServiceModel.FaultException`1 was unhandled by user code


Handling WCF SOAP Fault exception in Silverlight:

http://msdn.microsoft.com/en-us/library/ee844556(VS.95).aspx

The above specified article helps us on handling WCF SOAP exceptions in Silverlight. In that article it is clearly specified that in order to consume the SOAP faults, we need to adopt either of the following options.

• HTTP status code modification 
• Using alternate client HTTP stack

Similarly the faults are of two types. 

• Declared faults 
• Undeclared faults

In one of my project, I was about to handle faults in Silverlight whose sole purpose is for debugging. To achieve that, among the above, I used HTTP status code modification with undeclared fault type.

Upon implementing the endpoint behavior extensions(as specified in the msdn article) , I was eager to view the exception in Silverlight but resulted in the exception "System.ServiceModel.FaultException`1 was unhandled by user code" at my client(Silverlight app).

After having searched a lot, I found out a solution in a blog. It simply advised to change the following debugging option in the visual studio environment.

Under the Tools> Options menu, uncheck the following: 

• Enable the exception assistant
• Enable Just My Code(Managed only)

REFERENCE

http://msdn.microsoft.com/en-us/library/ee844556(VS.95).aspx

http://sergecalderara.wordpress.com/2008/11/25/systemservicemodelfaultexception1-was-unhandled-by-user-code/

Dependency Injection

RAVAGE

After several years of familiarization of the concepts of Dependency Injection (DI) and Inversion of control (IOC), I just came to know about the existence of those concepts. Thanks to Silverlight, PRISM (CAL) and MEF which made me explore the concepts DI and IOC.

Anybody who wants to write an article or explore in depth about Dependency Injection  will never fail to read Martin Fowler's article Inversion of Control Containers and the Dependency Injection pattern, for which I'm no exception.

Inversion Of Control

To understand from the name, its inverting the control of creation. Let's take the case of using the framework in an application, the framework takes the responsibility of creating objects/elements and the application will be hooked up with the created object as and when needed. Fowler states this with the example of UI framework and the application/program where the UI framework holds the responsibility of creating the graphical elements and the application instead creates the event handlers for those fields/graphical elements.

Dependency Injection

Think of a scenario class A uses class B which means class A depends on class B. In order to make use of class B in class A,  usually what we do is we'll write code to instantiate class B in class A. While instantiating class B, we need to pass the values that class B expects, to be clear, we need to satisfy the dependencies of class B. Say if class B expects and depends on class C, then in class A we need to instantiate class C first and then pass it to class B. Also we need to make sure that we should satisfy the dependencies of class C if any.

Ok, now think of changing the instantiating structure of the dependency object. For that we need to change the code in all the areas where it got used. In our example if class c changes its expectation(expects different parameter), we need to change the source code in class A.

There are situations that we don't know the concrete implementation at the time of writing the code or during compile time for various reasons - like we may need the code developed to be reused and the concrete implementation will be known sometime later.

In the above mentioned cases/paragraphs, just the scenarios are mentioned and the intentions are incomplete. Are there any solution for this? If so what is it? How to handle this? Dependency Injection is one solution to handle that.

Dependency Injection Types

• Constructor injection
• Setter injection
• Interface injection

Constructor injection and setter injection are commonly used injection techniques.

As you guess for constructor injection, we need to specify the dependencies as the parameter for the constructor of the class which requires it. Since we're trying to get rid of the concrete implementation, we need to specify the type (interface) of the dependency which it confirms to.

For setter injection, dependencies are exposed as properties which will be set during the instantiation process.

Ok, who'll hold the responsibility of creating, managing and injecting these dependencies? Builder object or containers will do that for you.

Containers

Containers - Are these containers new to .Net based applications? As quoted in msdn CLR itself is a container. If you think it is more generic, let's take the case of asp.net web applications, where there are times that we've used a common base class for handling security, authentication, common functionalities, etc. These base classes can also be considered as a form of container.

Since the containers will create, manage and inject objects, it avoids tight coupling of objects with its dependencies. Containers acts as a repository or lookup manager that maintains instances. We need to map or configure the containers which instances need to be used on which context. Containers also takes additional responsibilities like managing the lifetime of the objects, so that it supplies singleton or new instances upon requests.

Microsoft patterns and practices provides a lightweight extensible container called Unity Application Block. Prism which is used to create modular WPF or Silverlight applications usually uses this Unity Application Block as container.

SUMMARY

Basically Dependency Injection containers decouples the classes from its dependencies and also the responsibility of managing the dependencies. The issues that we face with DI is it's hard to track while debugging. Also we need to make sure that the container has the ability to resolve the dependency where its required. Previously I've specified in this article that dependency injection is one solution. Other solution generally proposed for this scenario is Service Locator.

REFERENCE

http://martinfowler.com/articles/injection.html
http://msdn.microsoft.com/en-us/library/ff649378.aspx
http://msdn.microsoft.com/en-us/library/aa973811.aspx
http://msdn.microsoft.com/en-us/magazine/cc163739.aspx
http://tutorials.jenkov.com/dependency-injection/when-to-use-dependency-injection.html

Factory Method - Pattern

INTRO

Factory pattern - Here comes the most commonly quoted pattern Factory method (next to Singleton Pattern). Factory method is frequntly used in lot of real time scenarios especially in the framework libraries. While developing a reusable library which contains core/base implementation, there are times where we need to work with or maintain the relationship between objects which will be created later during the implentation of those libraries. I've discussed one such case below under the Implementation in .Net.

Ultimate aim is to create a Product object and work on it which will be available some time later (as specified above). The name Factory resembles the real-world factory since it holds the responsibility of creating the objects (Products). Simply speaking the Client uses the Factory method to create a specific type of Product.

PLOT

Creator is the one who provides the interface for creating an object by holding the Factory method with him.
Factory method in the Creator returns a specific type of object Product.
Creator delegates the responsibility of "which class to be instantiated" to its subclass ConcreteCreator.
ConcreteCreator overrides the Factory method and it is responsible for creating the ConcreteProduct that adheres to the Product type. 

 GOF STRUCTURE

IMPLEMENTATION IN .NET

IEnumerable interface in .Net exposes a Factory method GetEnumerator(). The collection classes in .Net implements this IEnumerable interface to incur enumerator for a collection. Since foreach statement evaluates the type that implements IEnumerable, most of the collection classes will make use of this IEnumerable. ArrayList, HashTable, List,Dictionary are some of the examples.

IEnumerable needs to work on object of type IEnumerator, for iterating over the collection. Object of type IEnumerator knows how to iterate over the collection object of type IEnumerable.

ArrayList implements the IEnumerable and overrides the GetEnumerator method to create the object of ArrayListEnumeratorSimple which implements the IEnumerator.

Participants mapping

Creator : IEnumerable
ConcreteCreator : ArrayList
ConcreteProduct : ArrayListEnumeratorSimple
Product : IEnumerator

SUMMARY

I've just focussed on the case of delegating the responsibility of creating the instances to the subclass. There are also cases where the factory method in the ConcreteCreator defines the default instantiation and parameterized Factory methods used to identify and create specific ConcreteProduct.

REFERENCE

For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software
http://msdn.microsoft.com/en-us/magazine/cc188707.aspx#S5
http://ondotnet.com/pub/a/dotnet/2003/08/11/factorypattern.html
http://msdn.microsoft.com/en-us/library/ee817667.aspx

Builder Pattern

Builder Pattern

RAVAGE

I had a good discussion over the Builder pattern with my friend. Always he tries to map the pattern with a real case scenario and alters the example so as to fit it. So the problem is while discussing with him we need to think more than once before answering him. Also the important part I like with his discussion is that he tries to map the pattern as a pluggable element. That is he tries to identify the extensible part (reusable part for specific abstraction or mode) in order to scale-up the implementation. Actually that extensible part will be the core use of the pattern.

PLOT

A Product that need to be built step by step plays one of core role of this pattern. The ConcreteBuilder holds the functionalities for creating each part and accumulate them into a specific Product. The AbstractBuilder should provide common behaviors that supports different ConcreteBuilders. Director is the one who constructs the Product with the help of the operations specified by the Builder.
In the GOF structure client is not specified explicitly but the client plays an important role which specifies how the internal relationship will be executed. Client takes the responsibility for selecting the particular ConcreteBuilder and sends it to the Director. So the Client knows the ConcreteBuilder, Product and the Director.

GOF STRUCTURE

Please view the GOF structure in dofactory.

MATCHING SCENARIO

To understand simply we can take the common House example specified for this pattern. House is the product that we need to build. The ConcreteBuilder holds the operation for creating part of the object. One such operation is the method for creating room (CreateRoom()). As you know the AbstractBuilder holds the abstract description (simply abstract CreateRoom() here) that mimics the ConcreteBuilder. Now comes the Director which actually constructs the object for House using the AbstractBuilder. Let us consider the Director is going to create 2 bedroom flat, then it calls the CreateRoom() method in the AbstractBuilder (builder.CreateRoom()) twice.
Ok now we concentrate on how this will be implemented. As specified earlier, Client creates an instance for the specific ConcreteBuilder. Usually that ConcreteBuilder instance will be passed as an argument to the method call to the Director which holds the construction process.

EXTENSIONS

It is clear that Client is the one who decides which ConcreteBuilder need to be called. Hence the Client obviously knows which Product will get created. So he calls the construction operation in the Director passing the ConcreteBuilder instance.
Here comes the rival. My friend wants to explain the extension of this pattern by specifying an additional point in the above scenario. In our scenario we discussed about a 2 bedroom flat. He meant to extend it with 3 bedroom flat.
I just tried to extend with builder pattern but then inferred that the 3 bedroom scenario (in addition to 2 bedroom) partially won't suit the intent.
Actually as per the Intent specified by GOF for Builder pattern, the construction of complex object need to be separated from its representation so that the same construction process can be used for different representations. In our case the construction process is meant for a 2 bedroom flat and so in order to extend that, we need to identify a scenario that fits the different representation for the same 2 bed room construction. Hence we decided to go with two different representations of the 2 bedroom flat,
1) ordinary flat - whose CreateRoom() will create wall of thickness 200mm with ceiling height 10ft 2) secured flat - whose CreateRoom() will create wall of thickness 500mm with ceiling height 16ft.
For this we simply need to add a new ConcreteBuilder for the secured flat which uses the same AbstractBuilder as before.
Fine, now let us shift our focus to the 3 bedroom flat. Whether this can't be done with builder pattern? Not like that, it can be. So only previously in this post I specified it as "partially won't suit". Just introduce a separate construction process in the Director for the 3 bedroom flat (CreateRoom() need to be called 3 times). Since the Client is the one who is going to call the Director and also he has the knowledge on ConcreteBuilder and the Product, he'll take care of it and have control over it.

SUMMARY

• Need to identify the parts for building the complex object and ConcreteBuilder should provide the basic operations for creating parts for a specific Product. 
• AbstractBuilder should be common so as to accommodate different ConcreteBuilders.
• Director will construct the object by calling the basic operations for creating the parts.
• Client will decide which ConcreteBuilder instance to be used and pass it as parameter to the operation in the Director. Also Client have the knowledge of which Product to be created.

REFERENCE

For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software
http://www.dofactory.com/Patterns/PatternBuilder.aspx

Abstract Factory Pattern

Abstract Factory Pattern

PLOT
Available are products AbstractProductA, AbstractProductB,….
 Each of the products encompasses different varieties such as ProductA1, ProductA2… for AbstractProductA and ProductB1, ProductB2… for AbstractProductB. These ProductA1, ProductA2 are referred to as related items.


AbstractFactory simply ensures the creation of products. ConcreteFactory decides which type of product instance need to be created. That is ConcreteFactory1 creates ProductA1 and ProductB1, similarly ConcreteFactory2 creates ProductA2 and ProductB2.


So the core is the client creates an instance of the ConcreteFactory (i.e., ConcreteFactory1 / ConcreteFactory2) which is responsible for the creation of product object from the related varieties of Products.


Thus the client is independent of the product got created. Also note that the Concrete subclass (ConcreteProduct) for the Product is not specified.

GOF STRUCTURE

IMPLEMENTATION IN .NET
While exploring about this pattern, though I understood the concepts clearly with some good examples, I expected a better scenario to stick determined on this pattern. At that time I came across an article that describes Abstract Factory with ADO.Net 2.0.
Namespace: System.Data.Common

Participants mapping
AbstractFactory : DbProviderFactory
ConcreteFactory : SqlClientFactory, OracleClientFactory, OleDbFactory,...
AbstractProduct : DbConnection, DbCommand, DbParameter,...
ConcreteProduct : SqlConnection, OracleConnection, SqlCommand,...

Snippet

    1     Dim factory As DbProviderFactory = DbProviderFactories.GetFactory("System.Data.SqlClient")

    2     Dim connection As DbConnection = Nothing

    3 

    4     connection = factory.CreateConnection()

Line 1 - Creates an instance for SqlClientFactory (ConcreteFactory) for "factory" object. Factory pattern is made use over there which we will discuss later.
Line 2 - Defines "connection" as DbConnection (AbstractProduct).
Line 4 - factory.CreateConnection() returns a new instance SqlConnection{System.Data.SqlClient.SqlConnection} for the specific provider SqlClient.

SUMMARY
Simply without specifying the ConcreteProduct - SqlConnection, the instance got created.

REFERENCE
For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software

Design Pattern

All my posts related to design pattern will follow the GOF ideologies. I'm just going to make a note on the things that got raised during my observation and discussion. Also here I want to make note of the scenarios specified in the sites other than GOF. I'm not going to explain the patterns as most of the things will seem to be the replica as described by the GOF.
To be aware of Design Patterns, I tried lot of articles / books though I'm aware of GOF. As I'm passionate about C#, I tried to read books / Articles that explains well about the GOF patterns with C#. DoFactory site fulfilled that partially. But later one of my friend strongly argued with me and presented me with the native GOF "Design Patterns - Elements of Reusable Object-Oriented Software" book and asked me to get into that.
Really that helps me a lot and the approach of the book wins. Each and every pattern is explained by means of:

• Intent
• Also Known As
• Motivation
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns

 

The key items that describes the core ideology of the pattern are the Intent and Structure. Motivation is specified before the Structure which will help us to understand the Structure.

Finally I agree with my friend that to understand about the GOF Design Patterns, definitely we should first need to go through "Design Patterns - Elements of Reusable Object-Oriented Software". Then we can refer other books, articles or blogs in order to fine-tune the knowledge we acquired and to become strong in that.