Archive

Posts Tagged ‘WP7’

Raleigh Code Camp

November 2, 2011 Leave a comment

I will be presenting the following topic “Building a Windows Phone 7 App using JSON/ASP.NET MVC Data Service Layer” at the Raleigh Code Camp this weekend. We will take a look at leveraging ASP.NET MVC and JSON to become your best friend from the point of data serialization. Want to build a simple WP7 application? Want a simple way to pass data back and forth from the server? JSON seems to be the obvious choice when developing web applications, how does it work when developing WP7 applications? I am looking forward to it!

Categories: English Tags: , , , , ,

INotifyPropertyChanged woes? Too much ceremony?

September 27, 2011 14 comments

One of the things that Sivlerlight, Windows Phone 7, Windows Presentation Foundation, and WinRT developers face is the issue of data binding. This is a powerful feature that XAML technologies give us out of the box but there is a painful pattern that you have to implement in any property in order to get two-way binding to work.

First, you must implement the INotifyPropertyChanged event. Next you need to go through all of your properties and make sure you call the OnPropertyChanged method that you have in your implementation. This is a pain and adds no value to the underlying structure of your object. The only reason we need this extra fluff is to support data binding.

Well, there is a better way. There are actually several solutions or products out on the market right now but I prefer one that is the least intrusive and expensive. Let me introduce you to the NotifyPropertyWeaver project.

Here is a sample of what your code has to look like in order to have your properties raise the PropertyChanged event properly:

public class Person : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    public string GivenNames { get; set; }
    public string FamilyName { get; set; }

    public string FullName
    {
        get
        {
            return string.Format("{0} {1}", GivenNames, FamilyName);
        }
    }
}

This is really nice in that you don’t have to worry about any scaffolding or ceremony to get your properties to behave the way you would expect them. It also keeps your domain very clean and tight in that the only real fluff that you are exposing is the PropertyChanged event.

Here is what your code looks like when you compile it:

public class Person : INotifyPropertyChanged
{

    public event PropertyChangedEventHandler PropertyChanged;

    string givenNames;
    public string GivenNames
    {
        get { return givenNames; }
        set
        {
            if (value != givenNames)
            {
                givenNames = value;
                OnPropertyChanged("GivenNames");
                OnPropertyChanged("FullName");
            }
        }
    }

    string familyName;
    public string FamilyName
    {
        get { return familyName; }
        set
        {
            if (value != familyName)
            {
                familyName = value;
                OnPropertyChanged("FamilyName");
                OnPropertyChanged("FullName");
            }
        }
    }

    public string FullName
    {
        get
        {
            return string.Format("{0} {1}", GivenNames, FamilyName);
        }
    }

    public virtual void OnPropertyChanged(string propertyName)
    {
        var propertyChanged = PropertyChanged;
        if (propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

As you can see, this pattern is typically what you would have had to have done in the first place but this now happens during compilation. The cool thing about this is that you have less code to maintain.

You can also have your objects derive from a base class that has the PropertyChanged event defined and anything else that you may want to have exposed in your base. Your base class would look like the following:

public class ModelBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    // Common logic here ....
}

Your derived class would look like the following:

public class Person : ModelBase
{
    public string GivenNames { get; set; }
    public string FamilyName { get; set; }

    public string FullName
    {
        get
        {
            return string.Format("{0} {1}", GivenNames, FamilyName);
        }
    }
}

Finally, your source code would look like the following after it has been compiled:

public class Person : ModelBase
{
    string givenNames;
    public string GivenNames
    {
        get { return givenNames; }
        set
        {
            if (value != givenNames)
            {
                givenNames = value;
                base.OnPropertyChanged("GivenNames");
                base.OnPropertyChanged("FullName");
            }
        }
    }

    string familyName;
    public string FamilyName
    {
        get { return familyName; }
        set
        {
            if (value != familyName)
            {
                familyName = value;
                base.OnPropertyChanged("FamilyName");
                base.OnPropertyChanged("FullName");
            }
        }
    }

    public string FullName
    {
        get
        {
            return string.Format("{0} {1}", GivenNames, FamilyName);
        }
    }
}

This is really nice in that we did not have to do any extra work to get this functionality. It also finds any dependencies and makes sure that the OnPropertyChange method is called for them as well. We can see an example of this with the FullName property. It is readonly but it should still be updated whenever the GivenNames or FamilyName properties are changed.

One of the reasons why I like this solution so much is that it uses a convention to provide the IL weaving. You are not required to have any attributes over your class or properties to get this to work. I find the solution simple and elegant in its assumptions and it typically represents the ways we would end up coding the INotifyPropertyChanged interface any ways.

Another nice aspect to this project is that it already supports the following toolkits:

  • Caliburn.Micro
  • Caliburn
  • MvvmLight
  • Prism
  • Cinch
  • Windows Phone Essentials

You also have the flexibility to use custom Attirbutes to let the compiler know what to weave as well.  I personally, don’t like this since I want to keep my domain as clean as possible but it does give you a lot of flexibility.

In order to get this working for your project, you have several options.  You can either download and install a VSIX Package and have this capability ready for any of your Visual Studio projects.  Or, you can use NuGet and bring in the package on demand in the project that you need.

There are other solutions out there on the market.  The biggest one that comes to mind is PostSharp.  With PostSharp, you can do even more than weaving for the property changed event.  There is a free version with it as well but I didn’t see a single implementation that didn’t require an attribute.

I will be going over the power of PostSharp in a later post so that we can compare the goodness of both implementations.

Hope this helps…

Building a Windows Phone 7 App using JSON/ASP.NET MVC Data Service Layer

May 25, 2011 8 comments

I had a great time speaking at Charlotte’s Enterprise Developers Guild last night. Here is a link to my slides and sample code.

Thanks again to everyone who came out!

Building a Windows Phone 7 App using JSON/ASP.NET MVC Data Service Layer

May 23, 2011 4 comments

I am going to be presenting this Tuesday at the Developers Guild in Charlotte. We will take a look at leveraging ASP.NET MVC and JSON to become your best friend from the point of data serialization. Want to build a simple WP7 application? Want a simple way to pass data back and forth from the server? JSON seems to be the obvious choice when developing web applications, how does it work when developing WP7 applications?

Hope to see you there…