Mansoor's Collection of .Net Articles

how to build an outlook style application with prism v2 – Part 2

2010-06-01T10:03:00.000-07:00

how to build an outlook style application with prism v2 – Part 2: "

A while ago, I put an example application on my blog on how to build an outlook style application.

The last couple of weeks, I’ve been working on a new version of this app. I’ve done some bugfixes, but also included support for opening use cases in a popup window. It’s turning out to be quite an advanced demo of what’s possible with Prism. But while I’m playing with it, I can’t help but be amazed with the things I can push Prism into doing :)

You will need the following references to make the solution work:

So there are a couple of things I didn’t explain in my previous blog:

How to do ViewModel first development?

How to open a Use Case in a popup?

Why I’m using ObservableObject in my ViewModels?

So here goes:

ViewModel first development

I’m a big van of ViewModel first development. So what does that mean?

I create my ViewModels before i create my Views. This allows me to create testable viewmodels that absolutely don’t rely on any visual aspects.

My application code programs against ViewModels, not Views. Most of my code doesn’t need to know about the views. Only when a ViewModel needs to be displayed should you load up the view to display it.

There are a couple of big advantages to this approach:

You can easily unit test your UI logic, without relying on visual elements.

I can easily reskin my app.

You don’t have to forward data from your views to your view models. This is something I have always found annoying with a View First approach. For example, if you have a view that displays a person and needs a PersonID to do it. With view first, your code has to talk to the view. So the view needs a PersonID property. But actually, the logic of your view needs that PersonID, so it needs to be forwarded to your ViewModel. Annoying, tedious, error prone!!!

I wanted to be able to put ViewModels into my regions and to have some code that would provide the visualization onto it. So the code I want to be able to write is:

// 1: Setup visualizations (typically in Module.Initialize)
// Whenever an EmailMainViewModel is displayed, visualize it with an EmailMainView
modelVisualizationRegistry.Register<EmailMainViewModel, EmailMainView>();

// 2: Add ViewModels to region (view discovery, view injection or any other method)
region.Add(new EmailMainViewModel());

ViewModel First internals

If you’re interested in how I built the ViewModel First code? here it is:

ModelVisualizer

The first step into creating the view model first appraoch was to create a ModelVisualizer class. The reason for this was: 'The prism region adapters will put the content of the regions directly into the control that hosts the region (for example, a contentcontrol). There is no extensionpoint to sit in between that.

So I created something that I could put in a region, that would hold BOTH the View and the ViewModel. It would be the glue between the view and the viewmodel and:

Set the View as the content in the Visual Tree.

Set the ViewModel as the datacontext for the View.

Forward common information between the ViewModel and the View (such as the RegionContext or the IsActive values)

The following diagram explains my ModelVisualizer.

The ModelVisualizer IS a ContentControl. So it can be placed inside the Visual Tree. It will set the View as the content. It will also set the ViewModel as the datacontext of the view (so the view can bind to all the information in the ViewModel). Lastly, the IModelVisualizer implements the IRegionContextAware and IActiveAware interfaces, and will synchronize these interfaces with the View and ViewModel if they implement the interfaces.

Visualizing Region

The ModelVisualizer worked great. However, it demanded that all my code knew about the ModelVisualizer. I didn’t want to do that, because I wanted to make it implicit. There were some issues with that though, because due to the current implementation the region adapters, I didn’t have an extension point to create my visualizations implicitly. I couldn’t change the type of region that was created by adapters and I couldn’t change how the adapters set the content of the region to the hostcontrol. But I solved that with a little trick, that I call my VisualizingRegion.

The trick was: while I couldn’t change what type of region was being created, I could control what type of region was registered to the RegionManager (because there is a regionbehavior that does the registration. So I just wrapped the Region that was created by the regionadapters in my own region (the visualizing region) and registered my own visualizing region to the regionmanager.

The only way a consumer can get access to the Region is through the RegionManager, so that solved the problem :)

Easier Solution to region context

In Prism V2, we introduced the concept of RegionContext. The RegionContext is a way that a view that hosts a region can share some of it’s information with any childviews that are loaded into it’s region. While I really liked the concept of RegionContext, I didn’t really like the implementation of it.

So I created the IRegionContextAware interface. It has one property (the regioncontext as an ObservableObject) and the RegionContextAwareRegionBehavior that would sync the context of the region with the RegionContextAware properties.

Opening a Use Case (or ViewModel) in a popup

One thing I thought was an interesting challenge was opening a viewmodel in a (non modal) popup. So why would this be challenging:

You can have many instances of the same popup open at the same time.

Viewmodels shouldn’t know if they are opened in the main window (perhaps in several tabs) or in a popup. This should be decided by the designer, preferably in XAML.

The code I wanted to be able to write is:

   1: // Create an UseCase to write new email messages   2: NewEmailUseCase newEmailUseCase = ApplicationModel.CreateObjectInScopedRegionManager<NewEmailUseCase>();   3:     4: // Add some data to the Email message use case (in this case, a blank new email)   5: newEmailUseCase.Message = new EmailMessage();   6:     7: // Show the email (in a popup, but the consumer doesn't know that)   8: ApplicationModel.ShowUseCase(newEmailUseCase);

The problem with opening several instances of the same popup is: Regions are identified by name in the regionmanager. If you have several popups of the same type open, each popup needs it’s own RegionManager, or else the region names will collide. In my scenario, I decided that the Popup has most of the same region names as the main shell. That way, any ViewModel or use case could be loaded in either the popup or the main window.

Creating use cases in a scoped regionmanager

Ok, so i need to create a scoped regionmanager. That’s not to hard, just do: RegionManager.CreateRegionManager() and you have one. However, I wanted the consuming code NOT to have to think about this. It should be blissfully ignorant about the fact that it’s in a scoped regionmanager or not.

Since all most of my objects are created by a DI Container, and it injects all of the dependencies to my object, I decided to use that to solve this problem. So I created a scoped Container and registered the scoped regionmanager with that. Then I created my use case from the newly created scoped container, and if it needs a regionmanager, it would automatically get the scoped regionmanager. Pretty neat huh.

So schematic, that looks like this:

So when the use case (in green) get’s created, it and it’s dependencies would get the scoped regionmanager injected. Without knowing about the scoped containers or scoped regionmanager.

Adding use cases to popups

Adding the use case to a popup (in the application model) works like this:

Create the use case.
Your code creates a new use case instance, for example new NewEmailUseCase(); The application model has a method to create a use case within a new RegionManager scope (as described before).

Show use case.
Your code calls the Application model to show the use case.

Add to region.
The application model (which is logic) doesn’t even know if the use case is displayed in a popup or not. It just adds the use case to a region. The region itself is defined in the Shell.XAML.

Visualize the Use case
Just as a visualization (view) can be registered for ViewModels, i’ve also registered a visualization for Use Cases. In this case, I’ve registered a window (called Popup.XAML) as visualization.

Show /Close the popup on activate.
Now that the visualization is there, I had to create some code to show and close the popup. I decided that, if i Activate() the use case, the popup should be displayed. If I deactivate Use case, the popup should be closed and the use case should be removed from the region. This functionality I put in a RegionBehavior, because it can easily monitor if something is added or removed from a region.

Assign scoped region manager to the popup
Lastly, the popup window needs to know the RegionManager that the Use Case wants to use. So I’ve created the IRegionManagerAware interface. If a usecase implements that interface, anything that’s placed inside the region will get this region manager assigned.

As you can see, there are quite a lot of moving bits for showing a use case into a popup. Of course, it would have been A LOT easier to give ‘your code’ (an other use case or something) the knowledge that a view can be opened in popup.

ObservableObject for easier binding

If you look at my viewmodels, you’ll see that I make use of the ObservableObject a LOT. It’s a very simple object, one that just takes a type and wraps it in a INotifyPropertyChanged. The nice thing about this is, that I don’t have to add any INotifyPropertyChanged code in my ViewModels anymore. That makes it soooo much easier to do 2 way databinding in WPF.

The only problem is, that to get to the value, you often have to do: viewModel.MyProperty.Value to get to the actual value of MyProperty. But I thought that’s worth it since now I don’t have to write INotifyPropertyChanged code for my properties anymore.

Conclusion

Like I mentioned, before, this outlook style app has become quite an advanced demo of what’s possible with Prism. But I hope it gives you some idea’s on what’s possible with it. I’m also in the process of creating a video walkthrough of this application. But I’ll let you know when that’s done!

Keep practicing!

_Erwin

[UPDATE]

If you get an System.Threading.SynchronizationLockException from Unity: Don’t worry! I had turned on ‘break on all exceptions’ so the debugger is also breaking on these handled exceptions. Just continue and the app will run fine, or change that debug setting.

how do i do… With the Model-View-ViewModel pattern

2010-06-01T10:02:00.001-07:00

how do i do… With the Model-View-ViewModel pattern: "

While building the Composite Application Guidance for WPF and Silverlight (AKA Prism V2), we relied heavily on the Model View ViewModel pattern. But while this pattern is definitely the best thing ever, it took me a while to come to grips with it:

First of all, I have a mostly Windows Forms and ASP.Net background. With these technologies, I typically applied different separated presentation patterns, such as Model View Presenter. So when I tried to build WPF and Silverlight applications, I tried to apply the same techniques. But what I found was, that building WPF and Silverlight applications is significantly different from those other technologies. When I tried to apply the Model View ViewModel pattern, I kept running into questions. How do I do “X” in this pattern.

At first glance, the Model View ViewModel does not differ that much from other separated patterns such as Model View Presenter. It certainly tries to achieve similar goals, but it does it in subtly different ways.

In this series of blog posts, I’m going to describe how to apply the Model View ViewModel pattern and what kind of challenges you’ll have to overcome and what kind of decisions you’ll have to make. Over the next couple of weeks, I’m going to be writing about these topics:

How do I:

(Inside the MVVM pattern)

Describe the differences between the MVVM pattern and other separated presentation patterns
Implement the Model View ViewModel pattern
Adapt a simple vs complex model to the View
Work with popups and modal dialogs
Trigger animations from the View (without code behind)
Avoid code behind while building Views
Work with asynchronous methods

(When applying the MVVM pattern to an application)

Instantiate my Views / ViewModels
Create a logical ViewModel structure of my application
Implement automatic datatemplate selection in Silverlight

Hope you’ll find these topics interesting. If there are specific things you are struggling with, let me know. If i have time, I’ll try to write something about that as well.

Note, you’ll need to download the following references:

As I’m publishing new blog posts, I’ll keep updating this app, so check back sometimes for updated versions..

the difference between model-view-viewmodel and other separated presentation patterns

2010-06-01T10:02:00.000-07:00

the difference between model-view-viewmodel and other separated presentation patterns: "

This is the second blog post in a series on the Model View ViewModel pattern. Before I’m going to dive into the details of the Model View ViewModel pattern, I thought it is handy to describe the differences and similarities between this pattern and other separated presentation patterns.

<Next: Implement the Model View ViewModel pattern>

There are quite a number of Separated Presentation patterns out there. Model View Controller, Model View Presenter, Presentation Model, Passive View, Supervising Controller, Model- View-ViewModel and many many more:

When you look at these patterns, sure, the arrows are in different directions. But is that the only difference? Is a controller the same as a presenter or a presentation model? How would you compare Model View Presenter vs Model View ViewModel. In this blog post, I’m going to describe these differences and similarities between the most common separated presentation patterns.

Building an UI without Separated presentation patterns

How would you build a UI without using a separated presentation pattern. Typically, you’d create a form or user control, drag your controls on it and put the logic in the code behind. The code in the Code behind is very closely coupled to the UI, because it directly interacts with the controls on the screen. This approach is nice and straight forward, but only for really simple views. Because when the logic becomes more complicated, maintaining such a UI can become a nightmare!

The root of the problem lies in the fact that building a UI this way violates the single responsibility principle. This principle states: “A class should have only a single reason for change.” If a UI component has code for visualization, logic and data, it effectively has several reasons for changing. For example, if you wish to change the type of controls that are used to display the data, that change should not affect the logic. However, because the logic is so closely tied to the controls, it has to change too. This is a ‘code smell’ that signals that the single responsibility principle is violated.

So the Form or User Control holds both the code to draw the UI (controls, etc..), the logic of the UI (What happens when you click a button) and the data of the UI (The data that the UI works with), you’ll run into the following problems

Decreased Maintainability
A change in either the UI, the logic or the data will most likely cause changes in the others. This makes it a lot harder to make changes and decreases maintainability of the UI.
Decreased Testability
The logic and Data of an application can be written in such a way that each component can be unit tested in isolation. However, the UI related code is inherently very hard to Unit Test, because it often needs user interaction to trigger logic in the UI. Also, any visualization often needs to be judged by a human to see if it ‘looks right’. If the UI related code is mixed with Logic and Data, you loose the testability of the Logic and Data. Note, there are automated UI testing solutions available. However, they ‘mimic’ the user interaction. They are typically harder to setup and maintain than unit tests, but also they are often only useable as integration tests, because they need the entire application to be set up.
Decreased Reusability
If your UI related code is mixed with logic and with data, it becomes a lot harder to make that code reusable.

The goals of separated presentation patterns

While the individual patterns are quite different, the goals of these patterns are actually quite similar. Separate UI related code (Views) from Logic related code (Presenters, Controllers, ViewModels, etc..) and from the Data (Models). This allows each of these to evolve independently. For example, you are able to change the Look and Feel of your application, without affecting the logic or the data.

Secondly because the Logic and Data is separated from the visualization, the logic and the data can be unit tested in isolation. For very straightforward applications, this might not be very significant. For example, if your application is a simple data editor. However, if you have more complicated UI logic, it will quickly become very valuable to be able to automatically verify that your UI logic works as expected.

Model View Controller pattern

One of the very first separated presentation patterns was the Model-View-Controller pattern. This pattern was developed by Trygve Reenskaug.

In 1979!!!! (I wasn’t even born then).

Anyway, this pattern was developed for building Smalltalk applications. But in those days, computer programming was a bit different than today. There was no Windows. No graphical user interface. No Controls library. If you wanted a UI, you had to draw it yourself. If you wanted to interact with input devices such as keyboards. (Where there even mice in those days?)

But what Trygve did was quite revolutionary. Where everybody was mixing the visualization code, User interaction code, logic and data together, he came up with a pattern to separate these into separate classes, each with a distinct responsibility.

The problem with the MVC pattern is that it’s very likely the most misunderstood pattern in the world. And I think it’s caused by the naming. Trygne originally called the pattern Model-View-Editor, but later settled on the name Model View Controller. Now I can understand what a Model is (data) and what a View is (Something i can look at, the UI). But what is a controller? Is an ‘Application Controller’ the same controller as the controller in the MVC pattern? (No, but you can see where some of the confusion comes from)

So what are those Models, Views and Controllers

Model
The model typically is the data of your application and the logic to retrieve and persist that data. Often, this is a domain model that can be based on a database or the results from web services. In some cases, that domain model maps perfectly to what you see on the screen, but in other cases it has to be adapted, aggregated or extended to be usable.
View
The View was responsible for drawing the UI on the screen. Without windows or controls, that meant drawing, boxes, buttons, input fields, etc on the screen. The View can also monitor the model and display any data in it or update itself if the data changes.
Controller
The controller is responsible for handling the User Input and then updating the Model or the View. So if the user is interacts with the application, IE: presses a button on the keyboard, moves the mouse, the controller is notified of that user gesture and decides what to do with it. Maybe it should update the view, maybe it should update the model.

I whipped up the following example to illustrate what a Controller would look like in a ‘pure’ MVC implementation. I happened to implement it in normal asp.net (not asp.net Mvc), but without relying on any of the controls. So it’s more traditional asp style. (Ok, I know this is not a pretty example, but I hope it gets the point across of what a controller was meant to do.)

        1: public class Controller

{

    private readonly IView _view;

 

    public Controller(IView view)

    {

        _view = view;

 

        HttpRequest request = HttpContext.Current.Request;

        if (request.Form["ShowPerson"] == "1")

        {

            if (string.IsNullOrEmpty(request.Form["Id"]))

            {

                ShowError("The ID was missing");

                return;

            }

 

            ShowPerson(Convert.ToInt32(request.Form["Id"]));

        }

    }

 

    private void ShowError(string s)

    {

        _view.ShowError(s);

    }

 

    private void ShowPerson(int Id)

    {

        var model = new Repository().GetModel(Id);

 

        _view.ShowPerson(model);

    }

}

After many years, the programming paradigm changed somewhat. The concept of a control emerged. A Control encapsulates both the visualization (It draws itself), but also the user interaction. A button knows what to do if you click it. A textbox knows what to do if you type text in it. This reduces the need for a controller, so the Model View Controller pattern became less relevant. However, since there was still a need for separating out the logic of the application from the Controls and the data, an other pattern called Model View Presenter became more popular.

Most examples of the MVC pattern focus on very small components, such as building a text box or building a button. With a bit more modern UI technologies (Visual basic 3 is modern compared to 1979 smalltalk), you typically don’t need to apply this pattern. Unless you are developing your own control using very low level API’s. For example, if you want to build a completely custom control using Direct X, then you might be interested in this pattern.

The last couple of years MVC pattern became very relevant again, but for a different reason, with the advent of the ASP.Net MVC framework. The ASP.Net MVC framework does not use the concept of controls in the same way as the normal ASP.NET framework does. In the ASP.Net MVC framework, a View is an ASPX control that renders HTML. And the controller again handles the user gestures, because it receives the HTTP requests. Based on the http request, it determines what to do (update a model or display a particular view).

Model View Presenter pattern

So after the rise of visual programming environments and the introduction of controls that encapsulated both the Visualization and the User Interaction code, the need for creating a separate controller class became less. But people still found the need for a form separated presentation, only this time at a higher abstraction level. Because it turned out that if you create a form that is composed out of several controls and also contains the UI logic and the data, The Model View Presenter pattern describes a way to separate out the visual elements (Controls) from the Logic (What happens when you interact with the controls) and the Data (what data is displayed in the view).

Model

The model typically is the data of your application and the logic to retrieve and persist that data. Often, this is a domain model that can be based on a database or the results from web services. In some cases, that domain model maps perfectly to what you see on the screen, but in other cases it has to be adapted, aggregated or extended to be usable.

View

The View is typically a user control or form that combines several (smaller grained controls) into a (part of a) user interface. The user can interact with the controls in the View, but when some logic needs to be started, the view will delegate this to the presenter.

Presenter

The presenter holds all the logic for the view and is responsible for synchronizing the model and the View. When the view notifies the presenter that the user has done something (for example, clicked a button), the presenter will then update the model and synchronize any changes between the Model and the View.

One important thing to mention is that the Presenter doesn’t communicate directly to the view. In stead, it communicates through an interface. This way, the presenter and the model can be tested in isolation.

There are two variations of this pattern, Passive View and Supervising Controller.

Passive View

In the passive view, the view knows nothing about the model, but instead exposes simple properties for all the information it wants to display on the screen. The presenter will read information from the Model and update the properties from the model.

This would be an example of a passive view:

public PersonalDataView : UserControl, IPersonalDataView

{

    TextBox _firstNameTextBox;

 

    public string FirstName

    {

        get

        {

            return _firstNameTextBox.Value;

        }

        set 

        {

            _firstNameTextBox.Value = value;

        }

    }

}

As you can see, this requires quite a lot of coding, both for the View but also for the Presenter. However, it will make the interaction between the View and the Presenter more testable.

Supervising Controller

In supervising controller, the View DOES know about the Model and is responsible for databinding the model to the view. This makes the interaction between the Presenter and the View a lot less chatty, but at the expense of testability of the View-Presenter interaction. Personally i hate the fact that this pattern is called “Controller”. Because the controller is again not the same thing as the controller in the MVC pattern and also not the same as an “Application Controller”.

This would be an example of a view in the Supervising Controller.

public class PersonalDataView : UserControl, IPersonalDataView

{

    protected TextBox _firstNameTextBox;

 

    public void SetPersonalData(PersonalData data)

    {

        _firstNameTextBox.Value = data.FirstName;

    }

 

    public void UpdatePersonalData(PersonalData data)

    {

        data.FirstName = _firstNameTextBox.Value;

    }

}

As you can see, this interface is less granular and puts more responsibilities in the View.

Presentation Model

Martin Fowler describes a different approach on achieving separation of concerns on his site, that’s called Presentation Model. The Presentation Model is a logical representation of the User Interface, without relying on any visual elements.

The presentation model has several responsibilities:

Hold the logic of the UI:

Same as the Presenter, the Presentation Model holds the logic of the UI. When you click a button, that click is forwarded to the Presentation Model, which then decides what to do with it.

Massage the data from the model to be displayed on the screen:

The presentation model can convert the data in the model so it can more easily be displayed on the screen. Often, the information contained in the model cannot directly be used on the screen. You might need to alter the information (IE: convert data types), enrich the information (IE: summations) or aggregate information from several sources. This is especially likely if you don’t have full control over the model. For example, you get information from an 3rd party web service, or from a database of an existing application.

Store the state of the UI:

Often, the UI needs to store additional information that has nothing to do with the domain model. For example, which item is currently selected on the screen? What validation errors have occurred? The presentation model can store this information in properties.

The View can then easily read the information from the Presentation Model and get all the information it needs to display the view. One advantage of this approach is that you can create a logical and fully unit testable representation of your UI, without relying on testing visual elements.

The Presentation Model pattern doesn’t really describe how the view then uses the data in the Presentation Model.

Model View ViewModel

And then there is Model View ViewModel, also known as MVVM or just the ViewModel pattern. It looks surprisingly similar to the Presentation Model pattern:

In fact, the pretty much the only difference is the explicit use of the databinding capabilities of WPF and Silverlight. Not surprising, because John Gossman was one of the first persons to mention this pattern on his blog.

The ViewModel doesn’t communicate directly with the View. Instead it exposes easily bindable properties and methods (in the form of Commands). The View can databinding those properties and commands to query information from the ViewModel and call methods on the ViewModel. It’s also not required that the View knows about the ViewModel. XAML Databinding uses a form of reflection to bind properties of the ViewModel, so theoretically you can use any ViewModel with the View that exposes the right properties.

Some of the things I really like about this pattern when applied to Silverlight or WPF are:

You get a fully testable logical model of your application. I’ll talk more about this in further posts.

Because the View Model offers everything the view needs in easily consumed format, the view itself can be fairly simple. In fact, a designer can play with the look and feel in Expression Blend and change it without affecting the UI.

Lastly, you can avoid using code behind. In a later blog post, I’ll describe how to do this in more detail. Now this is a point of debate amongst View Model fans. I personally feel that you often don’t need code behind and that there are often better ways of solving it. Ok, sometimes you’ll need to do some tricks (like create attached behaviors) but they offer really nice and reusable solution. However, I also recognize that not everybody likes XAML markup and the XAML way of expressing databinding. The ViewModel pattern doesn’t force you to use or avoid code behind. Do what feels right to you.

Conclusion

I hope this description of the most common Separated Presentation patterns helps you in understanding their differences.

Implementing the Model View ViewModel pattern

2010-06-01T10:01:00.001-07:00

Implementing the Model View ViewModel pattern: "

In this third part of my series of blog posts on the ViewModel pattern, I’m going to demonstrate how to implement a simple example of the ViewModel pattern. Not to worry, we’ll dive into more exiting examples later.

<Back to intro>

<Back to: The difference between MVVM and other Separated presentation patterns>

<Next: Adapting a simple vs complex model>

The ViewModel

So what is a ViewModel? And how does it differ from a View or the Model. Consider the following example. Suppose you would build Paint using WPF or Silverlight, using the MVVM pattern:

The View obviously determines what is displayed on the Screen. And the Model, well that will likely be the Image. But the application works with more data than ‘just’ the Document. This extra data is mostly the State of the UI. What brush is currently selected? What is the ‘zoom’ percentage? While it is possible to store this information in the View itself, this is usually a bad practice. For example, the zoom slider bar could be the place where you would store the zoom percentage. However, when more elements on the screen need to use the Zoom percentage, this value quickly becomes very hard to manage.

Model for the View

The ViewModel is a model for the view. Therefore, it hold’s all the state of the view as well as the logic that operates on the state. The ViewModel exposes this data and logic in such a way that the View can very easily access it. However, the ViewModel should not expose or interact directly with UI elements.

Another responsibility of the ViewModel is to adapt the Model to the View. Typically the Model is a domain model (we’ll dive into that more in a later blog post). If you have full control over the model, then typically you can build it so that the model itself is very easily databindable. However, if you don’t have control over the model, for example, you are getting it from an external system, then the ViewModel might need to adapt the model to the view. For example, by adding aggregations, combining information from different models or simply by implementing INotifyPropertyChanged to enable the ViewModel notifying the View that properties have changed.

The MVVM pattern

So the following picture shows the MVVM pattern as how you would typically implement it in WPF or Silverlight:

The View is typically implemented as a UserControl or DataTemplate (in WPF). It uses Databinding to read and update information on the ViewModel. For example, the ViewModel can expose a public property Name that can be bound to a textbox.

If the view needs to communicate to the ViewModel, there are several options:

Commands

To route the Click event from a button to a ViewModel, the easiest way is to implement a Command. The Command pattern describes an object that can invoke functionality at a later point in time. In this case, when the user clicks a button. We’ll dive into commands later in this post.

This defines the Commands in XAML:
   1: // Define the Commands
   2: public ICommand ShowCalorieKingInfoCommand { get; private set; }
   3: public ICommand ShowIngredientInfoCommand { get; private set; }
   4:  
   5: // Initialize the commands in the constructor with a delegate command.
   6: public MealDetailsViewModel(IDialogService dialogService)
   7: {
   8:     this.ShowCalorieKingInfoCommand = new DelegateCommand<object>(ShowMealCalorieKing);
   9:     this.ShowIngredientInfoCommand = new DelegateCommand<Ingredient>(ShowIngredientInfo, CanShowIngredientInfo);
  10: } 
  11:  
  12: // The methods called when the commands are invoked
  13: private void ShowMealCalorieKing(object notUsed) {..}
  14: private bool CanShowIngredientInfo(Ingredient selectedIngredient) {..}
  15: private void ShowIngredientInfo(Ingredient selectedIngredient) {..}
This snippet shows an example how to bind a command to a button in XAML
<Button Margin="10, 10, 10, 10" Content="Show information on CalorieKing.Com"
       Commands:Click.Command="{Binding ShowCalorieKingInfoCommand}"/>
Pretty much only buttons allow you to use Commands out of the box. Now it’s possible (and not too hard) to create your own commands using attached behaviors).

2 way bindable properties

You can also use TwoWay databinding to notify the ViewModel that something has changed. For example, the following codesnippet shows how the DataGrid Control has a SelectedItem property. If you TwoWay databind this property to a property on the ViewModel.

Here’s the property in C#:
   1: public Ingredient SelectedIngredient
   2: {
   3:     get { return _selectedIngredient; }
   4:     set
   5:     {
   6:         if (_selectedIngredient == value)
   7:             return;
   8:  
   9:         _selectedIngredient = value;
  10:         OnPropertyChanged("SelectedIngredient");
  11:     }
  12: }
You can see that it also supports the INotifyPropertyChanged event. This means that the View will be notified if this value is changed in the ViewModel. And this is what the XAML would look like:
<data:DataGrid ItemsSource="{Binding Meal.Ingredients}"
              SelectedItem="{Binding SelectedIngredient, Mode=TwoWay}" >
When I first started using the ViewModel pattern, I overlooked this capability. For example, I was looking for a way to attach functionality to the SelectedItemChanged event of the DataGrid. But two way databinding works a lot more directly. Just don’t forget to add the “Mode=TwoWay” tag ;)

Bind ViewModel methods to events from controls

The Caliburn framework allows you to bind public methods on the ViewModel directly to your controls in XAML. While this is a really cool technology, I also believe it makes your XAML more complex, because effectively, you are now programming (calling methods) in XAML. So I would personally try to either use commands, use two way databinding or implement an attached behavior (more on this subject later).

Code behind

It is always possible to use Code Behind to communicate between the View and the ViewModel. Whether this is a good idea is a topic of hot debate. I personally am of the opinion that there are better ways to solve this problem than to use code behind. In a later blog post, I’ll go into details why i think this is a bad idea and how you can avoid this. But there are people who think differently.

ICommand interface

A common way to expose functionality from your ViewModel that your Views can interact with is by exposing Command objects. A command object implements the ICommand interface.

The ICommand interface has two methods:

Execute, which will fire the logic encapsulated by the command

CanExecute, which determines if the command can actually execute.

The CanExecute is interesting. It’s a common scenario that you might wish to disable certain functionality, based on the state of your UI. This can easily be accomplished with a command. Because, when you bind a button to a command and CanExecute returns false, then the button will automatically become disabled.

Commands also have another advantage: They decouple the invocation from the actual logic. This allows for interesting scenario’s:

Binding multiple ui elements to a command

Consider for example a SaveCommand. Often you don’t just have a Save Button, but also a Save menu item, and perhaps a save keyboard shortcut that will fire the same functionality. All these user gestures can be bound to the same command.

Chaining commands together

You might also wish to bind several commands to a single UI element. For example, a certain type of ViewModel can expose a Save Command. However, you can have several instances of that ViewModel (with the corresponding view) open at any given time. A Save All button can be bound to all SaveCommands on all those ViewModels.

Silverlight doesn’t have Commanding support built in. Fortunately, it does support the ICommand interface, so there are several libraries available that provide Silverlight implementations of the ICommand interface. For example Prism (aka the Composite Application Guidance for WPF and Silverlight) and the MVVM Toolkit both provide a DelegateCommand implementation.

In my demo application, I’m also demonstrating the use of the DelegateCommand.

The INotifyPropertyChanged interface

One thing that you’ll find yourself implementing on your ViewModels the time is the INotifyPropertyChanged interface. This interface allows your ViewModel to notify the View of changes to properties.

This code snippet shows how to implement this pattern:
   1: // Public event (for the interface)
   2: public event PropertyChangedEventHandler PropertyChanged;
   3:  
   4: // Protected method for invoking the event from code
   5: protected virtual void OnPropertyChanged(string property)
   6: {
   7:     var handler = PropertyChanged;
   8:     if (handler != null)
   9:     {
  10:         handler(this, new PropertyChangedEventArgs(property));
  11:     }
  12: }
  13:  
  14: // Example property that triggers the property. 
  15: public Ingredient SelectedIngredient
  16:  {
  17:      get { return _selectedIngredient; }
  18:      set
  19:      {
  20:          // IMPORTANT: only trigger the event if someting actually changes!
  21:          if (_selectedIngredient == value)
  22:              return;
  23:  
  24:          _selectedIngredient = value;
  25:          OnPropertyChanged("SelectedIngredient");
  26:      }
  27:  }
One important thing: before invoking the event in the property, check if the value has actually changed. This helps preventing never ending loops when properties are chained together.

If you don’t like the repeating code you’ll get when implementing properties with INotifyPropertyChagned, you can also use ObservableObjects as properties, as I’m describing (among other things) in this blog post:

http://blogs.msdn.com/erwinvandervalk/archive/2009/04/29/how-to-build-an-outlook-style-application-with-prism-v2-part-2.aspx

What not to do in a ViewModel

There are a couple of things you shouldn’t do in your ViewModels:

Expose or interact with visual elements in your ViewModel

Don’t try to expose Visual Elements, such as Buttons or other views from your ViewModel. This ties your UI to Visual Elements and makes it hard to test in isolation. Now you might run into the situation where your ViewModel needs to determine which view to display. In a later blogpost, i’ll describe how your ViewModel can be responsible for the logical ViewModel selection and use a DataTemplate to create the Visualization.

Try to control the View too directly from your ViewModel

You should try to keep your ViewModel logical, rather than Visual. For example, if you want to color a control red in error situations, you could expose an “IsControlRed” property, or expose a brush in the red color. It’s usually better to expose the logical property, such as “HasError”. Then the UI designer can decide if the color of the control should be red or purple in an error situation.

Summary

This blog post describes the basics about implementing the MVVM pattern. In later blog posts, we’ll dive into more interesting scenario’s.

how to apply a viewmodel to new windows

2010-06-01T10:01:00.000-07:00

how to apply a viewmodel to new windows: "

A colleague asked me a question today. How do you apply the Model View ViewModel pattern to new Windows and Popups. To illustrate that, i wrote a small sample app, which I wanted to share with you.

This post is part of a series:

There are usually two types of windows you might want to open. Modal windows, where the current window is no longer accessible until the modal window is closed, and non modal popups, where both the current window and the popup are opened and usable at the same time.

Modal windows

From the perspective of the ViewModel, opening another viewmodel in a popup is just like a very slow synchronous service. Take for example opening a confirmation dialog. The viewmodel doesn’t care if you ask the confirmation from a user, or from an external service. All it knows is that it needs the confirmation and has to wait until it get’s it.

The following codesnippet shows this:

        1: public class MainWindowViewModel : INotifyPropertyChanged

{

    //...

 

    // At a certain point in time, the MainViewModel want's to open a modal window

    // pass it the number of the window and know the number of the window that was closed last. 

    private void OpenDialogWindow()

    {

        // Create the viewmodel for the child window. This allows us to communicate

        // with the window in the popup

        var viewModel = new ChildViewModel();

 

        // pass the viewmodel some data: in this case, the number of the current window

        viewModel.WindowNumber = ++WindowCount;

    

        // opening a modal dialog is like a synchronous service

        _windowService.ShowViewModelInDialog<ChildView>(viewModel);

 

        // After the window is closed, get the number of the window that was just closed

        LastWindowToBeClosed = viewModel.WindowNumber;

    }

}

You can see how the viewmodel askes a service (The WindowService) to show a particular viewmodel. To keep the implementation of the WindowService, i’m also passing the Template (ChildView) to use to visualize the View. But there are many different ways of solving this, for example the one I’ve demonstrated in my Outlook style sample.

The code for the WindowService is very simple:

public class WindowService : IWindowService

{

    public bool? ShowViewModelInDialog<TViewType>(object viewModel)

        where TViewType : Control, new()

    {

        Window w = new Window();

        TViewType view = new TViewType();

        view.DataContext = viewModel;

        w.Content = view;

        return w.ShowDialog();

    }

}

This is simply a generic way of showing a viewmodel in a window, by using a View to visualize the ViewModel and show the window as a dialog.

Non modal popups

Now in the case of a normal popup, it’s more like an asynchronous service. The code in the ViewModel can continue to execute, but the opened window can raise events to signal status changes. This is very similar to, for example, an asynchronous webservice, that raises events for progress changes or completion.

The following code snippet shows this:

private void OpenPopupWindow()

{

    // Create the ViewModel to communicate with the service

    var viewModel = new ChildViewModel();

 

    // Pass the ViewModel some information

    viewModel.WindowNumber = ++WindowCount;

 

    // Opening a popup is like an asynchronous service. You can listen to change notification events

    // such as the Closed Event i've implemented

    _windowService.ShowViewModelInPopup<ChildView>(viewModel);

 

    // Listen for a change notification, when the window is closed

    viewModel.Closed += viewModel_Closed;

}

 

// This method is called when the window is closed again

void viewModel_Closed(object sender, EventArgs e)

{

    // Get the information from the viewmodel

    var viewModel = (sender as ChildViewModel);

    this.LastWindowToBeClosed = viewModel.WindowNumber;

 

    // Unsubscribe from the event to prevent memory leaks

    viewModel.Closed -= viewModel_Closed;   

}

As you can see, the code is similar to the Modal example. The only difference is, that you have to sign up for an event to get the required information.

The WindowService is slightly more complicated in this case:

public void ShowViewModelInPopup<TViewType>(object viewModel)

    where TViewType : Control, new()

{

    Window window = new Window();

    TViewType view = new TViewType();

    view.DataContext = viewModel;

    window.Content = view;

 

    // If the viewmodel knows about window closing events (IClosedAware) 

    // then forward closing notifications to the viewModel;

    SubScribeToClosedEvent(window, viewModel as IClosedAware);

 

    window.Show();

}

 

private void SubScribeToClosedEvent(Window window, IClosedAware view)

{

    if (view == null)

        return;

 

    window.Closed += (sender, args) => view.OnClosed();

}

I wanted a generic way for the WindowService to notify a viewmodel if the window is closed. So I created the IClosedAware interface, and implemented that on the ViewModel. The WindowService will, if the viewModel implements the IClosedAware, sign up for the ClosedEvent of the window and notify the ViewModel if that event occurs.

Hopefully this explains the way you can work with several Windows when using MVVM.

how to build an outlook style application – part 1

2010-06-01T10:00:00.000-07:00

how to build an outlook style application – part 1: "

[Update] This is part 1 of this post. Read the second post here.

At the end of building prism V2, we have played around with different application styles to see how easy it is to consume our own libraries. In this blog post, I’m going to describe my attempt at creating an outlook style application. My implementation shows the following aspects:

How to create application parts that can be activated and deactivated, can be put in a list, and are very lightweight.
How to use an Application Model?
How to do pure ViewModel first development. In WPF, you can apply implicit Data Templates to visualize objects, but in silverlight that doesn’t work. So I’ll demonstrate two ways to do this.
How to handle RegionContext in a more direct way.

You can download the Source Code here:

You will need the following references to make the solution work:

Prism
Unity

Download prism, compile it, and place the binaries in the lib folder. Also, place the Unity binaries in the lib folder.

Requirements

So what are my requirements for the outlook style app.

Be able to show a list of buttons that can activate parts of an application (like the outlook buttons for Mail, calendar, contacts, etc.)
It should be possible to activate and deactivate ‘Application parts’. If an application part becomes active, It’s initial view should show up in the main area.
Only one ‘application part’ can be active at any point in time.
When a view or an application part becomes active or inactive, other views might also have to be added or removed, such as toolbars.
Show a list of available ‘application parts’, without really instantiating all their views immediately. Only instantiate the views the first time you show them.

Solution

So this is my Outlook style app:

With a little bit of imagination, I hope you can see how this app could resemble outlook ;)

The following diagram shows the overall structure of the application and the most important pieces.

My shell has several regions, each brightly colored to make it clear where they are.

The ApplicationModel defines that the application has a list of UseCases. The ButtonBar (in red) is bound to the list of use cases. Each use case is represented as a button. When you click that button, the ActivateUseCase command is fired which will activate the selected UseCase.

An UseCase (like the MainEmailUseCase) implements the IActiveAwareUseCaseController and likely inherits from ActiveAwareUseCaseController. This makes it activatable (I know, it’s not a word). Lastly, the EmailUseCase itself defines which views it needs and where those views should go.

In the following paragraphs, i’m going to describe some of the moving pieces of this design.

Application model

The approach I took when creating the OutlookStyle app is to have a central ‘application model’ that knows how the application is structured. The modules also know a bit about this application model, through the IApplicationModel interface.

The ApplicationModel has a list of Main Usecases (more on usecases later), that I could bind my list of buttons to. It also has a command that can activate a UseCase when one of the buttons is clicked.

Using an ApplicationModel is kind of a double edged sword. It ties you somewhat down to a specific style of application. This makes your modules less portable, but it also makes the interaction between your modules and your shell more explicit and thus easier to understand. Using an application model is only one approach to creating an outlook style application and there are many others. But I thought it was an elegant solution and since we weren’t showing how to create an ApplicationModel in the Prism RI or the Quickstarts I thought it would be nice to show it here.

Internally, the application model uses a SingleActiveRegion to store the UseCases. This might seem strange, but a Region is nothing more than a model that can store a collection of objects that can be added, removed and activated. The SingleActiveRegion is ideal for this purpose, because it will make sure only one usecase is active at a given time. I choose not to add the region to a regionmanager, because I want the ApplicationModel to control access to this region.

Showing application parts: UseCaseControllers.

My implementation for the ‘application parts’ that can be activated and deactivated are called ‘UseCaseControllers’. This were my requirements for them:

I want to be able to put it in a list bind a collection of buttons to
I want to be able to activate and deactivate it.
It should be very lightweight, because all available controllers will be activated at once.

Motivations for naming the ‘application parts’

It was quite hard to find a right name for the ‘application parts’:

It’s not a module, because a module will likely contain many application parts. Also, a module should be viewed as a unit of deployment.
It’s not a view, because it’s more likely a set of views, working together to fulfill a single use case. These views, can be main views, tool bars, etc..
I considered the term ‘feature’ for a while. However, if you have ever built installers, you’ll know that a feature is also an overloaded term. It also refers more to a unit of deployment than what we’re looking for here.

So called my ‘Application parts’ UseCaseControllers. In my example, the main buttons on the outlook app kind of map to the ‘main’ or initial UseCases in my application.

Why call it controller? Controller is quite an overloaded term, because of the Model View Controller pattern. However, controllers are also commonly used to coordinate some kind of process and couple several pieces together to form a single unit. So because the controller hooks several controls together to perform a single use case, I called it a UseCaseController.

ActiveAwareUseCaseController

The ActiveAwareUseCaseController is a handy base class that you can use to fulfill the IActiveAwareUseCaseController interface. It does the following things for you:

BeforeFirstActivation Method. Have a handy place for the first time you activate this controller. In this method (BeforeFirstActivation), you can create all your Views or ViewModels and perform any eventwiring. For example, tie any toolbar commands to your ViewModels. The ObjectFactory also helps with this.
ViewToRegionBinder. One of the things you are very likely to do is to add views to some regions when the UseCase becomes active, and remove them again when it becomes inactive. Instead of having to put region.Add(view) and matching region.Remove(view) calls in the activate and deactivate methods, I figured it would be handy to create one registration method that takes care of this.

Using the ViewToRegionBinder to add and remove views to and from regions

Adding and removing views from a region whenever something becomes active or inactive can be quite tedious. Whenever a view or usecase (or anything else that implements IActiveAware) becomes active, you probably have to find the right regions, add the views to the regions. And the same if the usecase is deactivated (but then remove the views)

To make this a bit easier, I have created the ViewToRegionBinder. This object can monitor an IActiveAware object (such as a IActiveAwareUseCaseController or a view or a ViewModel). You can register a list of objects (views or viewmodels) against names of regions so that, when the object you are monitoring becomes active, the views will be added to the right regions and removed when the object becomes inactive.

   1: // Make sure the Toolbar and the mainregion get displayed when this use case is activated

   2: // and removed again when it becomes inactive.

   3: this.ViewToRegionBinder.Add("ToolbarRegion", this.emailToolBarViewModel);

   4: this.ViewToRegionBinder.Add("MainRegion", this.emailViewModel);

Using the ObjectFactory to delay creation of your views until you actually need them

Another interesting challenge I ran into was:I wanted to shows a list of buttons for each usecase in my system. But only when I click one of these buttons do I want my views to be created and initialized. You can imagine, if you have 20 of these ‘main’ usecases and each creates a bunch of views when the application starts, application load time would be dramatic.

This was one of the motivations for creating the UseCaseControllers in the first place. They are very lightweight and I could create the views I needed in the Activate() method. But then I faced an other issue. I really like to create my views and my viewmodels using Constructor Injection. However, since the objects injected the constructor would be created before the usecase would be created, not after, i had to put in some level of indirection.

This is what the ObjectFactory<Type> solves. You can express the dependency on an object in the constructor, and create the object when you need it, by calling the ObjectFactory.CreateInstance() method. You can access the instance created by the objectfactory using the ObjectFactory.Value property.

Now I didn’t want to create member variables for the ObjectFactories, because that would mean that every time I needed to access the view, i would have to go through the ObjectFactory.Value property. I really wanted to have variables of the type of the views. So I created the AddInitializationMethod, where you can add a lambda expression that will set the member variable for the views. The ActiveAwareUseCaseController will call these lambda’s just before the UseCase becomes active for the first time.

The following code snippet shows how this works in the MainEmailUseCase

// The references to these viewmodels will be filled when the app is initialized for the first time. 

private EmailMainViewModel emailViewModel;

private EmailToolBarViewModel emailToolBarViewModel;

 

public EmailMainUseCase(

    // Get the ViewToRegionBinder that the baseclass needs

    IViewToRegionBinder viewtoToRegionBinder

    // Get the factories that can create the viewmodels

    , ObjectFactory<EmailMainViewModel> emailViewFactory

    , ObjectFactory<EmailToolBarViewModel> emailToolBarFactory) : base(viewtoToRegionBinder)

{

    // Just before the view is initialized for the first time

    this.AddInitializationMethods(

            // Create the emailViewModel and assign it to this variable

        () => this.emailViewModel = emailViewFactory.CreateInstance()

            // Create the toolbarViewModel and assign it to this variable

        , () => this.emailToolBarViewModel = emailToolBarFactory.CreateInstance());

}

Why do I like Constructor Injection? It expresses very clearly what the dependencies of my object are, in a single place. Take the previous code snippet. You can clearly see that the EmailUseCase has a dependency on the IViewToRegionBinder, the EmailMainViewModel and the EmailToolBarViewModel. Those are the only objects this class interacts with. Sure, in some cases it might seem easier to get a reference to the service locator and resolve types when you need them, but that makes it very unclear what other types your class depends on and also makes unit testing a lot harder.

Bootstrapper

As usual, the bootstrapper is the glue for all the individual pieces. In the bootstrapper, all the infrastructure pieces are registered in the right way, so the application can use them. You can see that I’m registering the types i need to the container and some of the default regionbehaviors to the RegionBehaviorFactory

What’s next?

In the Outlook style application, i’m also showing a bunch of other things:

How to do ViewModel First development in an elegant way.

How to use RegionContext in a bit easier way

How to show views in a popup in a robust way. Note, in the current version, this is still work in progress.

Since I’ve already spent way to much time on this blogpost, i’m going to address these things in future posts.

As always, I really appreciate your feedback. Any comments or questions are more than welcome.

Happy coding!

_Erwin

[Update: Also read part 2 of this post. ]

how to work with animations in Silverlight in the mvvm pattern

2010-06-01T09:59:00.000-07:00

how to work with animations in Silverlight in the mvvm pattern: "

One of the things I found a bit more challenging than it should have been is working with animations in Silverlight. Often people will resort to code behind and triggering animations from code. However, I don’t really like that approach, because animations are a form of visualization. Visualizations should be created by designers. And I don’t think designers should have to be able to write code. So I’m going to show a pure XAML – databinding based way to trigger animation, by using a very simple attached property.

This post is part of my series on MVVM.

Why use animations?

Using animations is a double edged sword. On the one hand, when abused, they can create a very flashy, but totally unusable UI’s. For example, moving advertising banners on websites can make that website much less usable. They distract from the actual content and make it harder for users to find. On the other hand, when you use animations properly, it can really enhance the user experience. For example, in Windows, if you minimize a window, it doesn’t just vanish. You see it quickly shrink and move to the position on the taskbar where it was minimized to. That makes it easy to see what happened, and where to find your window when you want to get it back.

I typically use the following rules to judge if an animation is valuable:

Animations should call the attention of the users that something has happened and make it very clear what is happening.
Animations should never get in the way of the user:

Animations should not be distracting from what’s important.
Animations should not slow down the user. If the user has to wait until an animation is done, then the animation is hindering.

Who is responsible for animations?

Animations can be an important part of your application. Often animations should be triggered by Business Logic. For example, if your application has network connectivity and you detect that the internet connection is lost, you might wish to start an animation to get the attention of the users and notify them of this state change. In this case, you might argue that the logic (your VieowModel) should trigger the animation. However, animations are also a form of visualization. Often, they are closely tied to visual elements (because they will be animated). So that means the animations should live in the View.

If you start your animations in directly from your ViewModel, you are directly interacting with visual elements from your ViewModel. That means you are breaking the separation of concerns between the Visualization and the Logic of your UI. Basically, you are undoing the benefits of the ViewModel pattern.

When it comes to triggering animations from your ViewModel, I try to split the responsibility between the logical event and the visualization of the animation:

Logical Event that should trigger the animation:
Your ViewModel should raise an event to notify a logical state change. This can either be a pure ‘event’, but it’s typically easier create an observable property (by implementing INotifyPropertyChanged on your VM). If the logical event occurs, you can change the value of that property on your ViewModel. This is something you can test in your Unit Test.
Animated visualization of the event:
The View should define the animation, for example by defining a storyboard. This animation can easily be changed by a designer. Then to visualize the event and start the animation, the view should listen to the event or monitor the property for changes. When the property changes, the animation should be triggered.

You could use the Code-Behind of your views to do this wireup. However, I don’t really like that approach, because there are much simpler ways to do that. I’ll show you how to trigger animations purely from XAML using databinding.

Triggering animations from your ViewModel

First of all, you have to create a logical property on your ViewModel, that will change when the animation should be triggered.

I’m also demonstrating animations in several places in my sample application:

You can see 4 buttons, that demonstrate different aspects of working with ViewModels. When you click a button, the UI for that particular demo should come into View. However, because some of the UI pieces are used for different parts of the demo, I used animations to make it very clear what UI elements are added and removed when you enter a particular demo.

To enable these animations I followed the following steps:

Define a bindable property on your ViewModel

In my sample, I’ve defined a bindable property on my ViewModel, called “State” and a Command that can update the state. Clicking one of the buttons on my app should change the state and trigger an animation.

        1: // Public property that will change

public string State

{

    get { return _state; }

    set

    {

        if (_state == value)

            return;

        _state = value;

 

        OnPropertyChanged("State");

    }

}

 

// In my case, the command that will trigger the state change:

public ICommand GoToStateCommand { get; private set; }

 

private void GoToState(string newState)

{

    this.State = newState;   

}

 

// Create the command object that can trigger the state change

GoToStateCommand = new DelegateCommand<string>(GoToState);

Define animation in my view

The actual animations are defined in the view itself. I decided to use the VisualStateManager for this, but there are other options. Then I’ve created 4 visual states, each corresponding to one of the buttons. Here you can see one example of that:

<VisualState x:Name="SimpleViewModel">

    <Storyboard>

        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="mealDetailsView" Storyboard.TargetProperty="(UIElement.RenderTransform).(TransformGroup.Children)[3].(TranslateTransform.X)">

            <EasingDoubleKeyFrame KeyTime="00:00:00.2000000" Value="592.667"/>

        </DoubleAnimationUsingKeyFrames>

        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="mealDetailsView" Storyboard.TargetProperty="(UIElement.RenderTransform).(TransformGroup.Children)[3].(TranslateTransform.Y)">

            <EasingDoubleKeyFrame KeyTime="00:00:00.2000000" Value="1022"/>

        </DoubleAnimationUsingKeyFrames>

    </Storyboard>

</VisualState>

Trigger the animation when the state changes

Now that i have a property on my ViewModel that raises an INotifyPropertyChanged.PropertyChanged event and I have a storyboard in place, now I have to tie the two together. In WPF this is fairly simple, because you can use a DataTrigger to trigger the animation. However, in Silverlight, this does not work with ViewModels. So I’ve written a small class that allows you to use databinding to trigger animations. This is just an example of how you could accomplish this.

The VisualStateSetter has a bindable dependency property. When you set it to a certain string value, it will access the Visual State Manager and set the state to that string value. And because it’s a implemented as an attached property, you can apply it to any type of control.

public class VisualStateSetter

{

 

    public static readonly DependencyProperty StateProperty =

        DependencyProperty.RegisterAttached("State", typeof(string), typeof(VisualStateSetter), new PropertyMetadata(StateChanged));

 

    public static void SetState(DependencyObject target, string state)

    {

        target.GetValue(StateProperty);

    }

 

    public static string GetState(DependencyObject target)

    {

        return target.GetValue(StateProperty) as string;

    }

 

    private static void StateChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

    {

        Control host = d as Control;

 

        if (host == null)

            return;

 

        VisualStateManager.GoToState(host, e.NewValue as string, true);

    }

}

So this is what using the VisualStateSetter class looks like:

<UserControl UI:VisualStateSetter.State="{Binding State}">

<!-- The content of the control -->

</UserControl>

Here you see me binding the State property of the ViewModel to the Visual States that are defined in my View.

Now it would have been cleaner to have a more logical property on my ViewModel, for example an Enum and implement a converter that converts the Enum values to the Visual States in my View. But that’s not very difficult to do, so I’ll leave that up to you ;)

Hope this helps you to trigger animations in your views from your ViewModels.

_Erwin

Learning Prism (Composite Application Guidance for WPF & Silverlight). How do I start?

2010-06-01T09:19:00.000-07:00

Learning Prism (Composite Application Guidance for WPF & Silverlight). How do I start?: "

A question we get asked frequently is: “How do I start learning Prism? Is there a particular order for the Quickstarts? What other web resources do you recommend to start learning?”. If you are in this situation, or just want to have some more insight on a particular Prism topic, this is the post for you (I always wanted to say that, just like TV announcements :))

The basic question: “How do I start learning Prism?”

The first thing you should do to start learning Prism (assuming you know WPF/Silverlight), is begin with the documentation. It is really clear in what it tries to explain, provides great samples and explains a lot of the common doubts when starting to develop applications with Prism. There is not a particular order to learn Prism, so you should tackle it in the way you feel comfortable. Pay special attention to the Technical Concepts section, as it really helps understand how things come together.

Tip 1: Read the Prism documentation.

If while reading the documentation you have any doubts, or want to dig deeper into any particular topic you have many different options (and search queries in your favorite search engine). However, there are some things I believe you should take a look at:

Prism KB. There you will find links on many different topics (you can find a picture of them below), that could be videos, sample applications or blog post which will help you better understand some of Prism concepts.

Watch videos. There are lots of video tutorials going around, but these two collections are particularly good. Videos from P&P team & 10 Things to Know About Silverlight Prism.

Tip 2: Use the Prism KB and watch videos (these and also these particularly).

Prism KB site

But, what if I have some doubts while learning?

That is why developer communities were created, and as any other p&p asset Prism has its own forum at Codeplex where you can ask questions about any topic (technical concepts, how do I?, etc). The forum has a really active community, and is also monitored by the p&p Client Sustained Engineering Team (which we are part of). So if you have a question that has been bugging you for some time, and have not found the answer anywhere you can always drop by the forum.

Tip 3: Ask questions in the Prism Codeplex forum.

Last, but definitely not least…

There are some frequent Prism bloggers that you should follow, as they have some really interesting posts about how to use Prism and its insides. Below I will provide the list of those I follow (which is probably really short in comparison to the one I should be following), and for some the most interesting/requested post in my opinion:

Blaine’s, Bob’s and David’s blogs, with the latest news about Prism future.

Erwin’s blog. He has a really interesting series about working with MVVM.

Ward Bell. He has some really interesting posts, but the ones I choose are: Birth and Death of M-V-VM Triads & Prism Event Aggregator Subscription Blues.

Southworks blogs: Julian, Ezequiel, Mariano, Matias. The post that is a MUST is Julian’s ICommand For Silverlight with Attached Behaviors.

Glenn’s post: The spirit of MVVM (ViewModel), it’s not a code counting exercise, as this is something we get asked a lot and I share his thoughts on this topic.

As an extra, you can also follow the clientdev twitter, in which we tweet about the latest news about different .Net Client Development technologies (mostly Silverlight & WPF) and can be really useful when learning about Prism.

Tip 4: Read tons of articles about Prism.

I hope this article will help your Prism learning process, and please provide any feedback you might have so I can improve this guidance, like comments on the bloggers.

Learning Prism (Composite Application Guidance for WPF & Silverlight) MVVM Fundamentals

2010-06-01T09:14:00.000-07:00

Learning Prism (Composite Application Guidance for WPF & Silverlight) MVVM Fundamentals: "

On a previous post in this series I talked about a possible approach to take when starting to learn Prism as a whole (the Tip numbering is resumed from the previous post). In this post I will get more specific and talk about one of the most used (if not the most used) pattern when developing Prism applications (either for WPF & Silverlight): MVVM.

Most people are familiar with this pattern (if you are not great places to read about it are here for WPF and over here for Silverlight), so I will not go deep into what is the main idea of it. Instead I will try to go over some core concepts that usually lead to different levels of confusion.

What’s the difference between MVVM and PresentationModel?

The above question is one asked a lot, as people tend to get confused when they hear all the talk about MVVM and then open some Prism Quickstarts or RI and find most of them “implement the PresentationModel pattern”.

Well, there is not a certain answer (and if there was I probably wouldn’t be the one who came up with it), but as far as Prism development is concerned they are synonyms. There is no difference between them, except for the coined term. As Martin Fowler explains in his PresentationModel article: “The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.”, so if you think about it, the way to “project the state of the PresentationModel (or ViewModel) onto the glass is WPF/Silverlight DataBinding in our case (or as Julian likes to explain it: “the ViewModel is a bindable Presenter”).

Always remember the main objective, testability and decoupling.

Tip 5: MVVM and Presentation Model are synonyms.

How do I do pure MVVM?

This is another point of confusion as people tend to relate MVVM with DataTemplates and no View code behind, so they get the idea that the only way to implement the pattern is that one.

In my opinion there is no pure MVVM, it is a design pattern, so it can have many different implementations which will depend mainly on who implements it and what his requirements are. In this particular topic I would like to “branch you” to Glenn’s post “The spirit of MVVM (ViewModel), it’s not a code counting exercise.” as I agree with his point of view in this topic, so there is no point in duplicating the information.

Now that you have finished reading Glenn’s post, I hope you understand what I am trying to explain (not necessarily agree). I for once like the “View First” (you “talk” to the view) implementation to relate the View to its ViewModel in Prism could be the following (using DI):

public class MyView

{

public MyView(IMyViewModel viewModel)

{

this.DataContext = viewModel;

InitializeComponent();

}

}

In the code above, Unity’s DI provides the decoupling between the View and the ViewModel, so the ViewModel “does not have to know anything about the view” and allows you to test the VM in isolation (of course this is just one of the ways to do it).

Tip 6: There is no Silver Bullet MVVM implementation. Use the one that you like best.

How should I manage my View/ViewModel?

This question addresses both creation/destruction of View and ViewModels as well as its interaction with other components in the application. Often it is not “clear” which component should handle a specific action.

Say that when a button is clicked an event should be published. Where should this be done? Well, without information about the application and its patterns it is hard to say. It could be done in the ViewModel or it could be done in a module level controller that manages interaction with other modules, but this depends on how your application is structured.

Instead of expanding on this topic, I would like to branch you (yet again), to these posts from Ward Bell which talk about these common questions and provide some really interesting and thought answers:

Birth and Death of M-V-VM Triads

Screen Factory

Should I always use commands to communicate with the ViewModel?

Before using a command, I usually stop and think: “Can this be done in another way?, Can I achieve this same functionality with binding?”. Well, sometimes the answer is yes, and that is when I think commands are not necessary. The most common example is binding a command to execute every time and item in a Listbox is selected. This same behavior can be achieved by binding the SelectedItem property of the Listbox to your ViewModel (most of the times), and executing the required action on the setter.

Having thought of the above, what if I do need a command? Well, my first recommendation would be understanding how do Commands with attached Behaviors work, a topic explained by Julian in this great post. After that you can use the code snippet I created some time ago to help you with the tedious task of creating the classes required for this to work.

Tip 7: Before using commands, think if there is another option.

Things to add to your reading list

To help you comply with Tip 4, you can find below a couple of articles about MVVM and MVVM with Prism that I think might be of use to better understand this topic (the ones mentioned above would be in this list, but there is not need in duplicating them):

Erwin’s MVVM series (with some more posts to go)

David’s Visual Studio templates

Hopefully, this post has helped you understand a little more about MVVM and how to use it with Prism. As always, your feedback is appreciated, so if you believe any link should be added or anything of the sort, just drop a comment.

Memory Leak removing View with child regions in Prism-v2

2010-06-01T09:13:00.001-07:00

Memory Leak removing View with child regions in Prism-v2: "

About a week ago in the Prism forum we got a question about an issue in the scenario displayed below.

The Issue

When the MainView was removed from the MainRegion, the RightOne and RightTwo regions were not removed from the RegionManager and the views were still being referenced by the region. We were able to reproduce this issue “successfully” both using scoped regions and without them so we started thinking on a possible fix for this.

The Fix

After trying different things out, we took Julian’s suggestions and created a RegionBehavior that would be in charge of this. You can find the complete code for this class below:

public class ClearChildViewsRegionBehavior : RegionBehavior
  {
      public const string BehaviorKey = “ClearChildViews”;

      protected override void OnAttach()
      {
          this.Region.PropertyChanged +=
              new System.ComponentModel.PropertyChangedEventHandler(Region_PropertyChanged);
      }

      void Region_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
      {
          if (e.PropertyName == “RegionManager”)
          {
              if (this.Region.RegionManager == null)
              {
                  foreach (object view in this.Region.Views)
                  {
                      DependencyObject dependencyObject = view as DependencyObject;
                      if (dependencyObject != null)
                      {
                          dependencyObject.ClearValue(RegionManager.RegionManagerProperty);
                      }
                  }
              }
          }
      }
  }

When the RegionManager property of a Region changes to null, the behavior removes the view’s RegionManager attached property of all views in the region. Adding this behavior by overriding the bootstrapper’s ConfigureDefaultRegionBehaviors will enable this behavior for all regions:

protected override IRegionBehaviorFactory ConfigureDefaultRegionBehaviors()
       {
           var regionBehaviorTypesDictionary = base.ConfigureDefaultRegionBehaviors();
           regionBehaviorTypesDictionary.AddIfMissing
               (ClearChildViewsRegionBehavior.BehaviorKey, typeof(ClearChildViewsRegionBehavior));
           return regionBehaviorTypesDictionary;
       }

The Outcome

I have created a sample application showing how the fix works. You can download it from here. The code is provided “AS IS” with no warranties and confers no rights. I hope you can find this behavior useful if you have a similar kind of situation in your application.

As I probably won’t blog anymore until after the holidays, have a merry Christmas and a happy new year .

Creating a multi-shell application in Prism-v2

2010-06-01T09:13:00.000-07:00

Creating a multi-shell application in Prism-v2: "

This thread from the Prism forum presents the following question (this is not an actual quote but a summary): Are there any examples with multiple Shell windows, as the Prism documentation mentions?

First I re-read this article from the Prism documentation so I could get in the same page as the user. I’m not going to quote it here, but the “Implementing a Shell” section is the one where it is explained. Once I read that, the popular Popup Region from the Prism-v2 RI was out of the table so with Ezequiel Jadib we decided to create a small spike to see what changes needed to be done.

Creating Multiple Shells

As in a regular Prism application, using the CreateShell method to create the new Shell seemed like a good approach. However, as the RegionManager is set to the DependencyObject returned by this method, this had to be done manually for any other Shell window.

protected override DependencyObject CreateShell()
     {
         Shell1 shell = new Shell1();
         Shell2 shell2 = new Shell2();
         shell.Show();
         shell2.Show();
         shell.Activate();

         RegionManager.SetRegionManager(shell2, this.Container.Resolve<IRegionManager>());
         RegionManager.UpdateRegions();

         return shell;
     }

When to close the application?

Another thing to determine is when to close the application. This is not something “Prism specific” as WPF provides this option for any application. Since there are multiple Shell Windows, choosing the ShutdownMode=”OnLastWindowClose” seemed like the best approach.

<Application x:Class=“HelloWorld.App”
   xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”
   xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml” ShutdownMode=“OnLastWindowClose“>

Sample Application

I created a small sample application which publishes an event in one of the Shell views and subscribes to it in the other. You can download it from here. The code is provided “AS IS” with no warranties and confers no rights.

Prism Template Pack for Visual Studio 2010

2010-05-29T23:06:00.000-07:00

Prism Template Pack for Visual Studio 2010: "

Now that we have Release Candidate versions of Visual Studio 2010, as well as WPF and Silverlight 4.0, I’ve updated the Prism Templates so that you can more easily develop Prism applications that target these latest releases.

The templates themselves are similar to those I released a while back – there are templates for Shell and Module projects, as well as ‘QuickStart Solution’ templates that provide a complete, pre-configured, multi-module solution that you can use as a starting point for a complete Prism application. All templates are available for both WPF and Silverlight. They are all in C# at the moment. I’ll work on VB.NET versions soon…

I’ve modified the templates a little to use some of the features that have been introduced since Silverlight 2.0. In particular, I updated the QuickStart Solution to use the Silverlight PagedCollectionView class so that the ViewModel can keep track of the current selection automatically.

The biggest change, though, is that the templates now come in a VSIX package and use the Visual Studio 2010 Extension Manager. This dramatically simplifies the installation and management of the templates!! You can download the VSIX package here – note that you will have to change the file extension from .zip to .vsix in order to install it – or you can find it in the Visual Studio Code Gallery. You can also read the Getting Started release notes here.

You can install the VSIX package by simply double-clicking it (once you’ve changed the file extension to .vsix). You’ll be prompted to accept the license but two clicks is pretty much all it takes. When you run Visual Studio 2010 and open the Extension Manager (from the Tools menu) you’ll see the Prism Template Pack is installed. You can uninstall it or disable it from here too.

The templates show up in the Visual Studio 2010 New Project dialog under the Prism category. There are Shell and Module project templates, as well as the QuickStart Solution templates, for Silverlight and WPF.

Once you’ve created a project using the templates, a ReadMe file will be shown that details the remaining steps you will need to take before the solution will compile and run. This mainly involves updating the project’s references to point to the Prism assemblies on your system. In some cases, you might also have to add Silverlight App References to the Web project so that the projects are linked together properly. I haven’t yet figured out how to do this automatically without requiring some kind of complicated Visual Studio automation but I’m still working on it…

These templates target the Release Candidate versions of Visual Studio 2010, and WPF and Silverlight 4.0. Once they are fully released, I will update the templates with any changes that are required. I’m also hoping that templates like these will be included ‘in the box’ for Prism 4.0.

In the meantime, I hope you find them useful. Let me know what you think!

Silverlight 4 + RIA Services - Ready for Business: Authentication and Personalization

2010-05-29T23:03:00.000-07:00

Silverlight 4 + RIA Services - Ready for Business: Authentication and Personalization: "

To continue our series, In real business applications our data is often very valuable and as such we need to know who is accessing what data and control certain data access to only users with privilege. Luckily this is very easy to do with RIA Services. For example, say we want to let only authenticated users access our data in this example. That is as easy to accomplish as adding an attribute, see line 2 below.

  1:     [EnableClientAccess]
  2:     [RequiresAuthentication]
  3:     public class DishViewDomainService : LinqToEntitiesDomainService<DishViewEntities>
  4:     {
  5:

When we run the application, we now get an error. Clearly you can do a bit better from a user experience angle… but the message is clear enough.

Notice there is a login option, so we can log in…

and even create a new user.

and with a refresh we now get our data

And the application knows who i am on the client and gives me a way to log out.

Now you can also easily interact with the current user on the server. So for example, only return records that they have edited, or, in this case, log every access:

  1:         public IQueryable<Restaurant> GetRestaurants()
  2:         {
  3:             File.AppendAllLines(@"C:\Users\brada\Desktop\log.txt", new string[] {
  4:                 String.Format("{0}:{1}", DateTime.Now,
  5:                 this.ServiceContext.User.Identity.Name)});
  6:             return this.ObjectContext.Restaurants
  7:                 .Where (r=>r.Region != "NC")
  8:                 .OrderBy(r=>r.ID);
  9:         }
 10:

Line 5 is the key one.. we are accessing the current users on the server. This gives us a nice simple log.

3/7/2010 9:42:57 PM:darb

3/7/2010 9:43:05 PM:darb

Now we can also personalize this a bit. Say we want our users to be able to give us a favorite color and we keep track of that on the server and the client, so it works seamlessly from any machine.

First we need to add BackgroundColor to our backing store. I this case I am using ASP.NET profile storage, so I add the right stuff to web.config

Then I need to access this from the Silverlight client, so I add a property to the User instance in the Models\User.cs

    public partial class User : UserBase
    {
        public string FriendlyName { get; set; }
        public string BackgroundColor { get; set; }
    }

Finally, we need to access it on the client. In main.xaml add lines 2 and 3..

  1:   <Grid x:Name="LayoutRoot" Style="{StaticResource LayoutRootGridStyle}"
  2:         Background="{Binding Path=User.BackgroundColor}"
  3:         DataContext="{StaticResource WebContext}">
  4:
  5:

Run it and we get our great default background color!

Now, that is nice, but it would be even better to give the user a chance to actually edit their settings. So in About.xaml, we use a very similar model as above.

  <Grid x:Name="LayoutRoot"
        DataContext="{StaticResource WebContext}">

and

<sdk:Label Content="Background Color:" />
<TextBox Text="{Binding Path=User.BackgroundColor, Mode=TwoWay}" Height="23" />

Then wire up a save button

        private void button1_Click(object sender, System.Windows.RoutedEventArgs e)
        {
            WebContext.Current.Authentication.SaveUser(false);
        }

And it works!

And what’s better is if you run it from another browser, on another machine, once you log in you get the exact same preferences!

On Being a Bad Client

2010-05-29T23:02:00.000-07:00

On Being a Bad Client: "

I love these posts. But the thing is, they always come from the agency or designer's side. Here, I intend to give you a little insight from the bad client's side. Because even though I think most of my agency partners find me pleasurable to work with, I sometimes see myself in these 'bad clients' posts. I thought maybe I could help bring some perspective to the relationship.

Bad Client Behavior #1: They Want a Ton of Changes At the Last Minute

You, the designer, probably did exactly what you should do. You went through a business requirements gathering exercise, then talked to some actual users (yes, you were that lucky) and delivered an amazing set of wireframes (on time!). And what did you hear from your client? Crickets.

So you pressed ahead. You sent over the visual comp of the homepage expecting everything to go smoothly, when BAM! Suddenly Mr. Bad Client's feedback is flowing and he's telling you, 'We're way off track here!' You get more and more frustrated as the delivery date looms heavily and you have to cancel your plans to see the Human Centipede movie this weekend.

Here's the problem: Most of the time, your bad clients are super busy and just can't wrap their heads around a wireframe. In fact, they probably scanned it for about two minutes and declared it good. The visual comp is the closest thing to a real site in their heads, so that's when they begin providing the feedback you needed earlier in the process.

The fix? I recommend getting to the visual comp phase as fast as possible, and allowing room in the schedule to deal with feedback on the design.

Bad Client Behavior #2: Ugh! They Want You to Build a Site Without Content!

Ok, I'll admit it. I'm guilty of this. I've actually read Kristina Halvorson's book, Content Strategy for the Web. But I've been in situations where I was the primary contact with the agency, and my stakeholders just didn't have the content ready before putting together the site. Sorry Kristina!

After I apologized profusely, the great agency I worked with did the next best thing: They asked what kind of content would go in the various content blocks, and tried to use existing content instead of lorem ipsum. It actually worked out pretty well.

I was able to give them some guidance and examples of content we used in the past. For example, Microsoft is notorious for using long product names, titles of posts and titles of session for our events. So the typical 'Lorem Ipsum' filler text wouldn't work for us. We were able to plan for that.

I believe that you should have your content prior to building a site. But sometimes reality sets in, and you have to adjust to the situation. This agency has a special place in my heart for working with me vs. lecturing me.

Bad Client Behavior #3: They Want To See 10 Different Comps

As a client, I have to admit I like the idea of having choices. And yes, I will always want a Frankenstein of a web site that combines the best of the three you have shown me. Sorry!

But you have to remember: Most clients are not keeping up-to-date on the latest design trends. Helping give them exposure is a good thing.

Also, remember there are a ton of stakeholders (especially in a large company) that have a say-so in the design (or at least who sign my paycheck). So although you may have created one concept to rule them all, it may be more fruitful in the end to let me choose from different concepts.

Bad Client Behavior #4: They're Obsessed With 'Above The Fold'

First of all, let me just say: I'm with you on this one. Also in this bucket is:

Can you make the logo bigger?
It just doesn't 'pop' for me.
Can you make it more clean?
Hey! You left some empty space! Can we put a blog roll or a puppy picture there to fill it up?

These are critical moments for educating the client. Explain the 'why'. Another great agency I worked with was really good about explaining what was not on the page, and why. This made it very easy to go back to the stakeholders and explain why something was done (or NOT done).

Bad Client Behavior #5: They're Just Idiots

First, your clients are not idiots. They probably know their knowledge space just as much as you know yours.

That said, I do believe in firing really bad clients. If they don't pay up, if they don't respect you, if they burn you—by all means, you should never do anything for them again. I recommend Zeldman's 20 Signs You Don't Want That Web Design Project.

But take time when you are frustrated to look at it from the client's side.

Now Say You…

Do you agree? Do you disagree? Please let me know what you think in the comments below. I would be particularly interested in bad clients you have dealt with. Did you 'fire' them? Did you have a Jedi-trick you used to get over a rough patch? Please tell me about it below!

Also, follow me or MIX Online on Twitter if you like.

MSDN Video: Introduction to ASP.NET 3.5 (Level 200)

2010-05-29T23:01:00.000-07:00

MSDN Video: Introduction to ASP.NET 3.5 (Level 200): "While many developers have enjoyed success with ASP.NET development, and have learned the new capabilities with each successive release, there is a significant group of developers out there who did not get involved with ASP.NET from the beginning, and find it hard to uncover a solid learning path for both current and mature ASP.NET technology. This talk assumes no ASP.NET background, and introduces many of the flagship capabilities of the framework, allowing the vast audience of developers who did not start with ASP.NET 1.0 to get on board. At the end of the talk you will have seen many of the core elements of ASP.NET development, with practical examples to help get you started building solutions with the ASP.NET Framework."

MSDN Video: Introduction to Entity Framework (Level 100)

2010-05-29T22:59:00.000-07:00

MSDN Video: Introduction to Entity Framework (Level 100): "This is an introduction to the Microsoft ADO.NET Entity Framework, it covers the basics that will help you get started. "

Prism V2.2 Posted to Codeplex

2010-05-29T00:16:00.000-07:00

Prism V2.2 Posted to Codeplex: "

The updates to the Prism source outlined here, have been packaged as downloadable release on Codeplex.

This is largely the same code, with these additional items:

Added the Quickstarts and Acceptance test projects back in. These are the same as the ones available in version 2.1.
A more complete test pass.
A smoke test when targeting all projects to .Net 4.0

Additionally, we’ve posted the source to the ProjectLinker that can also work in VS2010. We plan on shortly posting the ProjectLinker to the Visual Studio Gallery, to make it a bit easier to consume.

My Favorite Quotations

2010-02-14T01:19:00.000-08:00

Mansoor Mehmood's favorite Quotations

Smile, it makes people wonder what you're thinking.

There are two theories to arguing with women. Neither one works.

A bus station is where a bus stops. A train station is where a train stops. On my desk I have a work station.

When you lose, don't lose the lesson.

I talk to myself because I like dealing with a better class of people.

If you're too lazy to start anything, you may get a reputation for patience.

I am not in competition with anybody but myself.My goal is to beat my last performance.

Never take a problem to your boss unless you have a solution.

I feel that the greatest reward for doing is the opportunity to do more.\

Well done is better than well said

All easy problems have already been solved

Anyone can count the seeds in an apple. No one can count the apples in a seed

Computers are not intelligent. They only think they are.

Confidence is the feeling you have before you understand the situation

Foresight is knowing when to shut your mouth before someone suggests it.

He is truly wise who gains wisdom from another's mishap.

If all you have is a hammer, everything looks like a nail.

If everything is coming your way, then you're in the wrong lane

It's hard to make a program foolproof because fools are so ingenious

Never appeal to a man's "better nature." he might not have one

You can discover what your enemy fears most by observing the means he uses to frighten you.

Sometimes what's right isn't as important as what's profitable.

SMS Poetry , Funny SMS , Urdu Only

2010-02-14T01:08:00.000-08:00

SMS Poetry

MUJH may khusbu basi ussi ki hai
jese ye zingagiussi ki hai
wo kahin aas paas hai mojod,
ho-na-ho ye hansi ussi ki hain ,
dukha rah hon dil is main lekin khushi usi ki hai
yani koi kami nahi mujh main,
yahi mujh main kami usi ki hai,
kya mere khuwab b nahi mare?
kya meri neend b usi ki hai?

jin se kismat ke sitare root jate hain
badal jati hain dunya magar sahare root jate hai,
wo kashti jis ki kismat main ho doob jana,
agar tofah se bach b nikle to kinare root jate hain

jab tanha tumhari shaamain hon,
jub moonh morh le duniya tum se
udaas tumhari raatain hon
her khushiroote jaya tum se
pukaar lana tum mujhey
ek muqa dena tum mujhey
tumhare zakum zakum badan ko
apnay kayal ka marham doon ga
jaltay haye daman ko
tamman;on ka sangam doon ga
samhaal loon ga tumhare toote dil ko
main taam loon ga har ek pal ko
ke phir kaheen tum kabhi toott kar bikhro
bikhar ke sulgo
tanha na tumhari zaat ho
tumhare saath main bhi toottoon tooth kar bikharoon
aur bikar ker sulgoon

mari hatheli tum apne pass rakh loo
jab dua mango tu isse b utta lena
khushi mile to apni hatheli agay karna..
gham milen to meri hatheli main sameet daina

NA JAANE KYUN DIL KI YE KHWAHISH HA
WO MERI HAR BAAT JAAN JAE BINA KUCH KHE

AASUON KO BAHOT SAMJHAYA,
KE TANHAIYON MAIN AAYA KARO,
MEHFIL MAIN HUMARA MAZAK MAT URAYA KARO,
IS PER AANSOO TARAP KER BOLE, Copyright www.lovelysms.com
ITNE LOGO MAIN BHI AAPKO TANHA PAATE HAI,
ISILIYE TUMHARA SAATH DENE CHALE AATE HAI..

Phoolon Say Pyaar Hai....?
Magar Jab Phool Khiltay Hain To Unhain Tehni Say Tor Dalti Ho....
Tum Kehti Ho Mujhay Baarishoon Say Pyaar Hai...?
Magar Jab Baarish Hoti Hai To Chuppti Phirti Ho....
Tum Kehti Ho Mujhay Hawaoon Say Pyaar Hai....?
Magar Jab Hawa Chalti Hai Tu Khirkiyan Band Kar Leti Ho...
Phir Us Waqt
Main Khof Zada Sa Ho Jata Hoon Jab Tum.....
Mujh Se Kehti Ho Mujhay Tum Say Pyar Hai......

Dil mein basa tha pyaar tera,
Wo dil to kabhi ka tod dia,
Badnaam na hone deinge tujhe,
Tera naam bhi lena chod dia.....!

Hame maut per bhi hai yaqeen,
Pyaar per bhi hai aetbaar hai,
Dekhte hain pehle kaun aata hai,
Hamein to dono ka intezar hai..........!

Socha tha us bewakuf ko bhul jaayeinge,
Dekh ker bhi andekha ker jaayeinge,Per
,Jaise hi wo saamne aaye wo hasi chehra,
Socha is baar dekh lein agli baar bhul jaayeinge............!

palbhar me toot jaye wo kasam nahi,dosto ko bhool jaye wo hum nahi,
hum tumhe bhul jaye is baat me dum nahi,aur tum Hume bhul jaao
itne bure hum nahi.

Chand utra tha hamare angan me,
yeh sitaro ko gawara na hua,
hum bhi sitaron se kya gila kare,
jab chand hi hamra na hua

meri ankhien rakh lo mujey kuch khab dey du.
jis mien tumhari jhalak ho aisi sharab de du
chalo choro sari batien ek baat maan jao
meri sari umer ley lo bus ek pal ka saath dey du..

Na aana usse leke mere janaze mein, Meri Mohabbat ki tauhin hogi, Main 4 logon ke kandhe pe hounga, Aur
meri jaan paidal hogi

Rah rah kar aapki yad aye to kya karun,
Yaad dil se na jay to kya karun,
Socha tha khawaboo me hogi mulakat,
Par neend hi na aye to main kya karun.

Apne dil ki suno, jazbat se kam na lo... Muje yad rakho beshak mera naam na lo... Apka vehem hai k hum bhul
gaye AAPKO, Aisa soch k mere pyar ka imtihan na lo

Funny SMS

Shaadi karni thi par kismat khuli nahin.......
Tajmahal banana tha par Mumtaz mili nahin....
Ek din... kismat khuli,.....shaadi hui,........
Ab Taj banana hai par yeh Mumtaz marti hi nahin.

Zara gaur se................
Lohe ko Loha kat ta hai ,
Sone Ko Sona Kat ta hai,
Zaher ko Zaher kat ta hai,
Isliye apko Kutta katega..

Hamaare Dil ke arman aansuon me beh gaye,
Hum gali me thay gali me reh gaye,,,,,,,,,,,,,,,,,,,,,
Kambakhat light chali gayi,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Jo baat unse kehni thi wo unki mummy se keh gaye..

Ager dum hai tu is sawal ka jawab yes or no me deke batao ... .... ... kya aapko pagalpan ke dure padhne band ho gaye hai?

Do U know the fullform of COLLEGE- C-Come,O-On,L-Lets, L-Love, E-Each,G-Girl,E-Equally......Thats why boys go to college regularly....

Who said english is easy???Fill in the blank with YES or No... 1.-----I dont have brain... 2.-----I dont have sence... 3.-----I am stupid....

Ye Keh Kar India Ne Pakistan Ka Paani Khol Diya Faraz...
K Hum Larki Ki Susraal Ka Pani Nahi Peetay. :-)

itne to burey na the jitne ilzaam lagaye logon ne faraz
kuch us ne humain badnaam kiya aag lagai apno ne...

Us ki Zulfon Mai Jab Se Soya Hon
Faraz...
Qasam Se Mujhe To Jooen hi Nahi Chortin!

About Mansoor Mehmood

2010-02-13T23:49:00.000-08:00

Mansoor Mehmood

Software Engineer at F3

Pakistan

Mansoor Mehmood’s Summary

I am a software engineer by profession.I am Developing software since 2005.My goal or aim is to become one of the best dot net specialist around the world. I am very hard working and I am always willing to learn to improve my skills in software development.

I have been awarded the best employee at MTBC for the month of June 2007. I have secured 1st position in my master degree

Mansoor Mehmood’s Education:

I have done master's in computer science from the University of Arid Agriculture, Rawalpindi in year 2007.I have done BCS from the Newport Institute of communication and economics in year 2004.I have took my initial level studies from the Islamabad model colleges, specifically Islamabad model college for boys G 8/4.I have topped my university during my masters degree(MCS).

My Websites/Projects:

I have develop few projects during my studies which are as under.
Website of trading company , Online furniture sale shop
PC Ludo game (using turbo C language)
Shortest job first algorithm simulation (using turbo C language)
GSM network simulation (using .NET C#)

My Interests:

I love developing desktop and web applications.I have developed desktop and web application for my employer and keep developing,. I love reading books related to history of Islam . I love playing computer games and watching movies.I have played a lot of cricket during my studies but now a days only watch cricket on TV (because of my very busy professional schedule).

About My Family

We are six (6) brothers and I am the eldest . My father (Manzoor Hussain Qureshi)has served in Pakistan government service for thirty (30) years.We belong from Mandra , a town in Tehsil Gujar Khan and district Rawalpindi.

My Recent Activities

I am working with a team whose goal is to develop or suggest the suitable software architecture for the next five (5) years. Developing or suggesting an architecture is really a very difficult job as all the new projects are going to follow it in future.We are studying and analyzing few of the best architectures and best practices already in use, through out the world. We worked in SOA based applications in past, now we are trying to improve current SOA by introducing few new technologies like PRISM , WCF and .net frame work 4.

I am also looking into WPF and Silverlight technologies.I have studied the Microsoft Enterprise Library blocks.I am very impressed with these blocks as they are covering very important crosscutting concern of application.The block are related to logging, exception handling, caching, cryptography, validation and security. I do recommend all .Net developers to study and use the enterprise library.

Recently I have been awarded the 2nd best software engineer of the year. I am very happy to receive the award, this will encourage me more to work hard and efficiently in future. Here are few pictures from the ceremony.

Mansoor receiving 2nd best software engineer prize in above picture. My team also get declared as the best team of the year 2009-2010.

In above picture Mansoor is in group photo with his team.