silverlight

My take on the ViewModelLocator pattern for MVVM

kellyb — Thu, 01 Apr 2010 01:51:38 GMT

John Papa and Glen Block have recently posted on a topic that touched home for me. They put together a solution to find view models for a given view in a view-first fashion to support Blendability and a clean MVVM presentation pattern. Funny, I put this very pattern together last week after being motivated by what I saw from Rob Eisenberg and Laurent Bugnion at MIX the week before. I too came to the conclusion that it makes a lot of sense to go with a View-first approach if you’re going to make Blend a first class citizen in your development process (as I believe you should).

What John and Glen put together is MEF based (obviously), but what I put together is IoC based. In my case I’m using Unity, but it could be any IoC container. With a very simple convention, I can greatly simplify this entire pattern. That convention is this: The View and the ViewModel will always reside in the same namespaces within the same assembly and the View will always be suffixed with xxxxxView and the ViewModel will always be suffixed with xxxxxViewModel. That’s it. With that convention in place, one line of markup can be used in all views to auto-locate, instantiate, and bind to it’s corresponding ViewModel. No need to Export anything with MEF and no need to have string names on your exports to find by. I like my approach a lot better and my team has been very happy with it so far. It’s very simple, straightforward and requires very little ceremony code.

Below is what the code looks like…

All views have this markup at the root element:

DataContext="{Binding RelativeSource={RelativeSource Self},  Converter={StaticResource LocatorConverter} }"

This is simply binding the View’s DataContext to itself and passing itself to the LocatorConverter. The LocatorConverter looks like this:

    public class ViewModelLocator
    {
        public static object Locate(object view)
        {
            try
            {
                Check.ForNullArg(view, "view");

                Type viewType = view.GetType();
                string viewTypeName = viewType.Name;

                Logger.WriteInfo("Attempting to auto-resolve the view model from the view (type: {0})", viewTypeName);

                if (string.IsNullOrEmpty(viewTypeName) || !viewTypeName.EndsWith("View"))
                {
                    throw new PresentationModelException("Attempting to locate a view model instance for an invalid {0} implementation - expected the type name to be suffixed with 'View'", typeof(IView).Name);
                }

                string viewModelTypeName = string.Concat(viewTypeName, "Model");

                var viewModelTypeFullName = viewType.AssemblyQualifiedName.Replace(viewTypeName, viewModelTypeName);

                var viewModelType = Type.GetType(viewModelTypeFullName);

                if (viewModelType == null)
                {
                    throw new PresentationModelException("Could not find view model type '{0}' in namespace '{1}' within assembly '{2}'.  Auto resolution of the view model requires both the view and the view model to reside within the same namespace.", viewModelTypeName, viewType.Namespace, viewType.Assembly.FullName);
                }

                object resolved = IoC.Resolve(viewModelType);

                if (resolved == null)
                {
                    throw new PresentationModelException("Failed to resolve the view model type '{0}'", viewModelTypeFullName);
                }

                Logger.WriteInfo("Successfully auto-resolved view model (type {0})", viewModelTypeFullName);

                return resolved;
            }
            catch (Exception ex)
            {
                string viewType = view != null ? view.GetType().FullName : "NULL";

                throw new PresentationModelException(ex, "The attempt to auto-instantiate the view model for the view '{0}' threw an exception: {1}.  See the inner exception for details.", viewType, ex.Message);
            }
        }

IoC is a very think shim around Unity that’s setup by our application’s Bootstrapping process:

        public static object Resolve(Type type)
        {
            return _container.Resolve(type);
        }

I love MEF, but this doesn’t feel like a good fit for MEF to me – at least not in it’s current form.

Handy Serialization Extension Method, Clean code with Action<T>

kellyb — Wed, 24 Mar 2010 03:44:34 GMT

Here’s a handy Extension Method in C# that attaches a “ToXml()” method to any and all object instances. I added the capability to dictate whether or not to use the classic XmlSerializer or the DataContractSerializer that came to us with WCF. I made the XmlSerializer the default because typically, when I’m doing this programmatically in my code, it’s intended for human eyes and the XmlSerializer is far more readable, but the DataContractSerializer is what’s actually used at runtime by WCF. So, call the overload the matters to you.

        public static string ToXml<T>(this T obj) where T : class
        {
            return ToXml(obj, false);
        }

        public static string ToXml<T>(this T obj, bool useDataContractSerializer) where T : class
        {
            if (obj != null)
            {
                Type type = typeof (T);

                Action<XmlWriter, object> action;
                
                if (useDataContractSerializer)
                {
                    action = new DataContractSerializer(type).WriteObject;
                }
                else
                {
                    action = new XmlSerializer(type).Serialize;
                }


                using (MemoryStream stream = new MemoryStream())
                {
                    XmlWriterSettings settings = new XmlWriterSettings { Encoding = Encoding.UTF8, Indent = true };
                    XmlWriter writer = XmlWriter.Create(stream, settings);

                    if (writer != null)
                    {
                        byte[] bytes;

                        using (writer)
                        {
                            action(writer, obj);
                            writer.Flush();
                            stream.Flush();

                            bytes = stream.ToArray();
                        }

                        return Encoding.UTF8.GetString(bytes, 0, bytes.Length);
                    }
                }
            }

            return null;
        }

This is a good example of C# generics using Action<T>. Notice I’m assigning the variable “action” to either the XmlSerializer’s Serialize() method, or the DataContractSerializer’s WriteObject() – which both have a method overload of void (XmlWriter writer, object obj). I really like this syntax as it provides yet another way to remove duplication from your code without requiring the types to share a base class or interface, and without having to create a full blown Template Method pattern implementation.

And it works in Silverlight too :)

ASP.NET MVC - Unhandled Error in Silverlight Application Code: 2104

kellyb — Thu, 10 Dec 2009 23:52:02 GMT

I’m creating a simple ASP.NET MVC application and on first run I’m getting blasted with this:

Google didn’t turn up the solution as fast as I would have liked, so I thought I’d post it here for the next fool to find :)

Solution:

When you add a Silverlight project to a solution, Visual Studio will ask you if you would like to create new web site to host it, or choose an existing one in your solution. I choose an existing one. By default, Visual Studio creates this in your HTML markup to host a Silverlight application:

    <div id="silverlight">
        <object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
                
          <param name="source" value="ClientBin/MySilverlightApp.xap"/>
          <param name="onError" value="onSilverlightError" />
          <param name="background" value="white" />
          <param name="minRuntimeVersion" value="3.0.40624.0" />
          <param name="autoUpgrade" value="true" />
          <param name="initParams" value="page=UserRegistrationView" />

          <a href="http://go.microsoft.com/fwlink/?LinkID=149156&v=3.0.40624.0" style="text-decoration:none">
               <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style:none"/>
          </a>
          
        </object>
        
        <iframe id="_sl_historyFrame" style="visibility:hidden;height:0px;width:0px;border:0px"></iframe>
    </div>

Visual Studio does not account for the URL rewriting that comes with MVC and by default the path to xap file is wrong. Change the source parameter to be rooted like so:

          <param name="source" value="/ClientBin/MySilverlightApp.xap"/>

One simple slash should fix your problem. Hope this helps someone else (you’re not a fool :)

Debugging Silverlight with Silverlight Spy

kellyb — Mon, 23 Nov 2009 17:47:35 GMT

The debugging experience in Silverlight project using Visual Studio is quite good. However, there are two things that is doesn’t help much with: when data bindings don’t work, and when your XAML doesn’t look like you think it should. Here’s a post about debugging data bindings. The visual part is a little more involved. Yes, yes Expression Blend has a nice visual designer, but it’s fairly common for Blend to show a piece of XAML in one way and for it to actually render in the browser differently (sometime significantly differently). Today I found First Floor Software’s Silverlight Spy. This appears to be a pretty awesome diagnostics tool that allows you to see and alter Silverlight’s Visual Tree at runtime side by side an embedded browser.

You can edit the Visual Studio within Silverlight Spy and see the rendered content change immediately. This is extremely useful. This is to Silverlight apps what Firebug is to web apps.

If this is still useful at the end of the trial period, I’ll be buying a copy of this for myself.

Silverlight ComboBox SelectedItem Not Working

kellyb — Mon, 23 Nov 2009 17:31:54 GMT

I spent well over an hour on Friday with this one and gave up. I spent almost another hour today working on this. I almost gave up, but when I’m in learn-mode like I am with Silverlight, these types of issues can really teach you a lot if you see them through. I had a ComboBox with bindings on it’s ItemSource and SelectedItem like so:

            <ComboBox Name="ComboBoxControl" Style="{StaticResource ComboBoxStyle}"
                SelectedItem="{Binding Path=SelectedOption, Mode=TwoWay}"
                ItemsSource="{Binding Path=Options}"
                IsEnabled="{Binding Path=IsReadOnly}"
                Foreground="{StaticResource SemiDarkTextBrush}"                    
                Height="22" Width="150" Grid.Column="1" Margin="30,0,10,0" HorizontalAlignment="Stretch" >
                <ComboBox.ItemTemplate>
                    <DataTemplate>
                        <TextBlock 
                            Foreground="{StaticResource SemiDarkTextBrush}"                    
                            Text="{Binding Path=Label, Mode=OneWay}" 
                            TextWrapping="Wrap" />
                    </DataTemplate>
                </ComboBox.ItemTemplate>
            </ComboBox>

I put breakpoints in my model’s SelectedOption property and I could see Silverlight calling it. So, I knew there were no hard binding errors. The bindings were working, except… they weren’t. The ComboBox always showed up with no selected item. I kept plugging away, and by accident I discovered the order of the binding occurrences matter. Changing the markup to define the ItemsSource binding before the SelectedItem binding solved the problem. Like so:

            <ComboBox Name="ComboBoxControl" Style="{StaticResource ComboBoxStyle}"
                ItemsSource="{Binding Path=Options}"
                SelectedItem="{Binding Path=SelectedOption, Mode=TwoWay}"
                IsEnabled="{Binding Path=IsReadOnly}"
                Foreground="{StaticResource SemiDarkTextBrush}"                    
                Height="22" Width="150" Grid.Column="1" Margin="30,0,10,0" HorizontalAlignment="Stretch" >
                <ComboBox.ItemTemplate>
                    <DataTemplate>
                        <TextBlock 
                            Foreground="{StaticResource SemiDarkTextBrush}"                    
                            Text="{Binding Path=Label, Mode=OneWay}" 
                            TextWrapping="Wrap" />
                    </DataTemplate>
                </ComboBox.ItemTemplate>
            </ComboBox>

Wow, that’s pretty nasty. I’m lucky stumbled on the solution. I consider this a bug.

Hope this helps someone else out there

Silverlight Lessons Learn – Debugging Data Bindings

kellyb — Mon, 23 Nov 2009 17:23:51 GMT

I’ve been neck deep in Silverlight development for the last couple of weeks. I’m finally starting to feel somewhat competent. Most of my struggles have been with XAML in general, so I think the steep learning curve applies to both Silverlight and WPF. One of the things I’ve been using struggling with the most is troubleshooting data bindings. The data binding system in Silverlight and WPF is pretty awesome, but it’s definitely not intuitive nor discoverable. When you force yourself to learn it, most of those issues melt away, but… buuuuut, debugging binding remains extremely difficult.

Today I discovered something that helps a TON. Binding errors are written to the Visual Studio Output Window! Check this out:

It’s not the most robust solution, but it’s definitely workable.

After discovering this, I did a bit more Googling around and found this handy article: How can I debug WPF bindings. He covers the Output Window approach there as well. For the record, I was not able to get the “Trace Sources” technique to work in Silverlight – only WPF.

Hope this helps someone else out