Friso De Ridder

Using phone 7 capability detection tool

frisoderidder — Tue, 08 Feb 2011 01:45:41 +0000

When you’re developing a phone 7 application you have access to a wide range of capabilities, they enable access to networking, different sensors on your phone device, identity functionality and so forth. When you create a new phone 7 application in visual studio all of them are enabled, check the ‘capabilities’ section in your WMAppManifest.xml file to see which of them are enabled in your application.

When an application is submitted to the phone marketplace it goes through a submission process. One of the steps in this process is the detection of the required capabilities for that particular application. The submission process also replaces the auto-generated capabilities list with the specific capabilities required for your application.

It is strongly recommended to test applications based on the exact phone capabilities required by the application. Various end-user issues can occur if an application is not tested based on the specific capabilities required by your application.. To make this easy, as of the October 2010 update, a capability detection tool is included in the Windows Phone Developer Tools.

Open a command prompt, go to the folder containing the capability detection tool (Program Files (x86)\Microsoft SDKs\Windows Phone\v7.0\Tools\CapDetect) and execute the CapabilityDetection.exe with the Rules.xml file and the path to the output folder of your application containing the binaries. After you’ve run the tool you’ll get a list of the capabilities needed in your application. Go to the capabilities section of the WMAppManifest.xml file and remove the unnecessary ones.

For more information visit: http://msdn.microsoft.com/en-us/library/gg180730(v=VS.92).aspx

Clean up your code behind with behaviors

frisoderidder — Sat, 22 Jan 2011 17:07:38 +0000

I’ve been developing in Silverlight for the last two years now however I never got into the habit of using Expression Blend. Three weeks ago I wrote my first Phone 7 application and while developing it, I also forced myself to use blend more often. To be honest in the beginning I was not really fond of it, I could write xaml quicker by hand than by setting all the properties in blend, but then I discovered all the extras blend has to offer and I was sold. One of those extras that come with Blend are the build in behaviors for managing storyboards, and let that be the subject of this post.

First I’ll show you the xaml and code before I was using the behaviors.

public partial class Advantages
{
   public Advantages()
   {
      InitializeComponent();
      SocialSubHideSb.Completed += delegate
            {
                SocialSubscriptionDataContainer.Visibility = Visibility.Collapsed;
            };
      ViewModel.PropertyChanged += OnViewModelPropertyChanged;
   }
   
   private AdvantagesViewModel ViewModel
   {
       get { return (AdvantagesViewModel)DataContext; }
   }
   
   private void OnViewModelPropertyChanged(object sender, PropertyChangedEventArgs e)
   {
       if (e.PropertyName == "HasSocialSubscription")
       {
            if (ViewModel.HasSocialSubscription)
            {
              SocialSubscriptionDataContainer.Visibility = Visibility.Visible;
              SocialSubShowSb.Begin();
             }
             else
             {
               SocialSubHideSb.Begin();
              }
        }
     }
}

Basically what this code does is, when the toggleswitch gets checked the ‘SocialSubscriptionDataContainer’ will become visible and slide in from the left. When the toggleswitch gets unchecked the ‘SocialSubscriptionDataContainer’ will slide out of view to the left and when this animation is completed it will collapse.

Now lets rewrite this by using behaviors.

All changes were applied to the toggleswitch, so lets break them down.

To do the ‘slide in’ feature I’ve added an EventTrigger that will listen to the Checked event of the toggleswitch. When this event is triggered two behaviors will be executed the first one is a ChangePropertyAction that will set the visibility property of the SocialSubscriptionContainer to Visible. The second one is a ControlStoryboardAction that will start the ‘SocialSubShowSb’ storyboard.

The ‘slide out’ feature requires two triggers. The first one is an EventTrigger that will listen to the Unchecked event of the toggleswitch. This trigger will execute ControlStoryboardAction that will start the ‘SocialSubHideSb’ storyboard. The second trigger is a StoryboardCompletedTrigger that is configured to listen to the Completed event of the ‘SocialSubHideSb’ storyboard. When this trigger is executed a ChangePropertyAction is called that will set the visibility of the SocialSubscriptionContainer to Collapsed.

No lets have a look at the code behind

   public partial class Advantages
    {
        public Advantages()
        {
            InitializeComponent();
        }
    }

Woo hoo no code behind!

Donwload and share process templates for TFS 2010

frisoderidder — Thu, 20 Jan 2011 13:25:02 +0000

While studying for my TFS 2010 certificate I came across this awesome codeplex page where you can download and share process templates. If you want to see which other templates are available besides the ones installed with TFS 2010. Or you’re more the ‘do-it-yourself’ kinda guy and you want to share your own awesome creations with the rest of the world. This: http://templex.codeplex.com/ is the place to be.

Cheers
F.

Important prerequisite for installing a patch for TFS 2O1O

frisoderidder — Thu, 23 Sep 2010 20:26:52 +0000

Yesterday I wanted to install the following patch for TFS 2010. I went through the kb article, made sure all the prerequisites were met and did a little search for known issues which ended up empty. In the believe it was save, I went ahead with installing the patch on our application tier. The wizard came up, I went through the screens, the patch started installing and 10 minutes later I received a message claiming that the install was succesful. Great I thought … but then I opened team foundation administration console and I saw the following error appear on my screen.

There went my smiling face. Nothing worked anymore, TFS was dead.

Fast forwarding 24 hours (during those 24 hours: I tried to find the cause myself without any luck, my hair went from brown to gray, I considered a couple of times to throw my pc out of the window and I contacted Microsoft to escalate the problem and provided them with log information and such) … News came from Microsoft that they where able to identify the cause of the problem and had a solution. Finally some good news.

The problem seemed to be that the patch tried to update the tfs_Configuration database but that it was unable to do so because that database was being mirrored. This caused TFS never to recover from servicing mode making it useless. unfortunately the installation wizard completed with success. First thing going through my mind was …

The solution was simple.

Remove the mirroring from the database.
Shut down any running TFS processes and then wait for 16 minutes or more (it seems somebody at Microsoft timed this).
Install the patch again.

30 minutes later it was like nothing ever happened. And there was yet again a smile on my face.

Tip of the day:

Always make sure, before installing a patch for TFS, none of the affected databases is being backed up nor mirrored.

Using MEF as a simple DI-container

frisoderidder — Sun, 15 Aug 2010 18:00:14 +0000

Lately I’ve been looking at MEF, more specifically at how I could use it as a simple DI-container. What I wanted to do was the following:

Register the needed assemblies in the container
Use the container as a factory from which I could request instances from certain types and that would resolve all the underlying dependencies for me

Seems it is not that hard to accomplish. Watch and learn…


    public interface IUserRepository: IRepository
    {
        User Create(string userName, string password);
    }

    public interface IUserService
    {
        User Create(string userName, string password);
    }

    [Export(typeof(IUserService))]
    public class UserService: IUserService
    {
        private readonly IUserRepository _repository;

        [ImportingConstructor]
        public UserService(IUserRepository repository)
        {
            _repository = repository;
        }
        public User Create(string userName, string password)
        {
            return _repository.Create(userName, password);
        }
    }

        private void CreateContainer()
        {
            AggregateCatalog catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(typeof(IUserRepository).Assembly));
            catalog.Catalogs.Add(new AssemblyCatalog(typeof(IUserService).Assembly));

            _container = new CompositionContainer(catalog);
            _container.ComposeParts(this);
        }

Two things are important here:

The [ImportingConstructor] attribuut on the constructor of the UserService will tell MEF that it needs to resolve and inject the constructor parameters.
The [Export(typeof(IUserService))] will make the UserService class discoverable for MEF and more importantly for the problem at hand it will make it possible to get an instance of the UserService from the container.

Now we can ask the container to give us an instance of a registered type that implements IUserService.


        [TestMethod()]
        public void CreateTest()
        {
            var service = _container.GetExportedValue();

            service.Create("friso", "C0mplexPwd");
        }

Material RealDolmen Brains Session: Design Patterns (part 2) online

frisoderidder — Wed, 28 Jul 2010 11:14:02 +0000

The slide deck and code samples of the Design Patterns (part 2) brains session from 30/06/2010 can be downloaded from the RealDolmen portal.

Note: only accessable for RealDolmen employees.

Material RealDolmen Brains Session: Design Patterns (part 1) online

frisoderidder — Tue, 01 Jun 2010 15:32:18 +0000

The slide deck and code of the Design Patterns ( part 1) brains session from 25/05/2010 can be downloaded from the realdolmen portal.

Note: only accessable for RealDolmen employees.

Using the Decorator design pattern to extend your classes behavior

frisoderidder — Mon, 24 May 2010 11:24:39 +0000

“Favor object composition over class inheritance” is one of many software design principles out there . I won’t explain the meaning of the principle in this post, rather I would like to show you one of the ways it can be achieved. For a profound explanation of the principle I suggest you Google it or read about it here, here and here.

The hypothetical car factory example

At this point in time the car factory we’re working on sells two types of cars: the “Sport blaster 2000″ and the “City cruiser 2000″. The class diagram is as follows:

And the classes look like this:

    public abstract class Car
    {
        public abstract string Name { get; set; }
        public abstract string GetOptions();
    }

    public class SportCar: Car
    {
        private string name = "Sport blaster 2000";

        public override string Name
        {
            get{ return name;}
            set{ name = value;}
        }

        public override string GetOptions()
        {
            return string.Empty;
        }
    }

    public class CityCar: Car
    {
        private string name = "City cruiser 2000";

        public override string Name
        {
            get {return name; }
            set{name = value;}
        }

        public override string GetOptions()
        {
            return string.Empty;
        }
    }

As you can see the Car class has a method “GetOptions” that will return the options for a specific car instance. For starters we want a gps, cruise control and tv option. We also want to keep in mind that in the future new options can be added and others could be removed.

Solution #1

Let’s add a boolean for each option to our base class and give the “GetOptions” method a base implementation. It would look something like this:

    public abstract class Car
    {
        public abstract string Name { get; set; }

        public bool Gps{get;set;}
        public bool Tv{get;set;}
        public bool CruiseControl{get;set;}

        public virtual string GetOptions()
        {
            var options = string.Empty;

            if(Gps)options += "Gps, ";
            if(Tv)options += "Tv, ";
            if(CruiseControl)options += "Cruise control, ";

            return options;
        }
    }

The problem with this approach is that it will quickly become unmaintainable. Every time a new option becomes available or one gets removed we will have to change our Car base class and every subclass that uses these options, this could also have an effect on the consumers of those classes. Also what if we want to add multiple tv’s to one Car? Or what if a Tv can’t be added to all our models than we would have to implement some custom logic in those subclasses. Because the “GetOptions” method is implemented in the Car class, changing this method will have an impact on its subclasses, this change could potentially have unwanted effects for one of those subclasses.

Solution #2

Create a subclass for every possible combination. I’m not going to build this example but by applying some simple math (2^3 *2) you’ll find out that this approach would need 16 classes already, just for the current situation, a real class explosion. Again a maintenance nightmare.

What we would really like is have the ability to extend the Car class (adding new options) without having to touch the Car class itself. I have a feeling that Solution 3 will give us the answer we are searching for.

Solution #3

Meet the Decorator pattern. For a profound theoretical explanation of this pattern look here and here. In a nutshell a decorator extends a class its functionality by wrapping an instance of that class in it and overriding its behavior. Let’s look at our car decorator base class.

    public abstract class CarDecorator: Car
    {
        protected readonly Car car;

        protected CarDecorator(Car car)
        {
            this.car = car;
        }

        public override string Name
        {
            get {return car.Name; }
            set {car.Name = value;}
        }
    }

Two things to point out here.

First: the CarDecorator inherits Car, meaning that it will behave as a Car. If you stick, and actually you should, to the design principle that states that you should always program against an interface (an abstract class or a .Net interface) instead of a concrete implementation you will be able to switch an implementation of a Car by an implementation of a CarDecorator without your consumers noticing it.

Secondly: the CarDecorator receives an instance of a car in its constructor (this could be a SportCar or a CityCar or even another CarDecorator) and uses it to implements its Name property.

Next we are going to implement our concrete CarDecorators.

    public class GpsDecorator: CarDecorator
    {
        public GpsDecorator(Car car):base(car)
        {
        }

        public override string GetOptions()
        {
            return car.GetOptions() + "Gps, ";
        }
    }

    public class TvDecorator: CarDecorator
    {
        public TvDecorator(Car car)
            : base(car)
        {
        }

        public override string GetOptions()
        {
            return car.GetOptions() + "Tv, ";
        }
    }

Both decorators overwrite the “GetOptions” method by first calling the “car.GetOptions” method and then adding their own option.
Let’s see at the result of our little test application.

	class Program
	{
		static void Main(string[] args)
		{
            Car sportCar = new SportCar();
            Car cityCar = new CityCar();

            Console.WriteLine("Cars with no decorations\n");
            Console.WriteLine("Sport car options: "+ sportCar.GetOptions() + "\n");
            Console.WriteLine("City car options: " + cityCar.GetOptions() + "\n");

            sportCar = new CruiseControlDecorator(sportCar);
            cityCar = new TvDecorator(new GpsDecorator(cityCar));

            Console.WriteLine("\n\nCars with decorations\n");
            Console.WriteLine("Sport car options: " + sportCar.GetOptions() + "\n");
            Console.WriteLine("City car options: " + cityCar.GetOptions() + "\n");

            Console.ReadLine();
		}
	}

And when we run this:

The class diagram now looks like this:

Summary

I was able to add functionality to my car implementations without touching those classes and even better, the consumers of my car classes wouldn’t even notice because they are still programming against an instance of Car. In the future when options are added or removed this will have no impact on my Car classes themselves which is a big advantage regarding to maintenance and testing.

I hope I was able to convince you guys that instead of creating large inheritance trees or extending base classes to the limit the Decorator pattern is a nice alternative to be considered next time you face a similar problem.

Hello WordPress

frisoderidder — Sat, 22 May 2010 08:13:46 +0000

Finally I’ve got myself to sit down for an hour and set up my own free WordPress blog.

I’m a big .Net and programming in general enthusiast so you will find me blogging about everything that interests me related to those topics.

While awaiting my first “real” blog post, you can already check out my about page to learn something more about this blogger.

I hope you will enjoy reading my blog and maybe even learn something from it.

Cheers

Friso