Derik Whittaker : HowTo, Silverlight

Using MVVM with the AutoCompleteTextBox in Silverlight 4

Derik Whittaker — Fri, 18 Nov 2011 22:25:00 GMT

The AutoCompleteTextBox is a great tool in Silverlight to allow you to provide relevant information to your users as they are typing as seen below:

But there are a few issues with this control

Pretty much every sample on the net uses the code behind to do the heavy lifting and not binding
It will not update the VM text box in real time, which is needed if you want to do on the fly filtering

In this post I will walk you though how to setup your AutoCompleteText box and we will learn how to do 3 things

Use MVVM to populate and use the control
Use a custom Behavior to allow the property backing the control to be updated in real time
Use a command to trigger background searches on the fly

Using MVVM to populate your control:

In order to populate your AutoCompleteTextBox you will need to bind something to the ItemSource property of the control as such:

ItemsSource="{Binding KeywordSearchSource}"

I am sure you are wondering what the KeywordSearchSource is? Well it is simple a property which returns a IEnumerable<string>

       public IEnumerable KeywordSearchSource
        {
            get
            {
                return SomeListOfValues.Select( x => x.TextValue );
            }
        }

The next thing you will want to do is setup a property in your view to handle the current value inside the control. This is needed because we are binding and not using the code behind. You can do this as below:

Text="{Binding KeywordSearchText, Mode=TwoWay}"

The trick to above is to remember to mark this as being TwoWay or you will not get the results you are expecting

        private string _keywordSearchText;
        public string KeywordSearchText
        {
            get { return _keywordSearchText; }
            set 
            {
                _keywordSearchText = value; 

                NotifyOfPropertyChange(() => KeywordSearchText); 
            }
        }

That does it for the MVVM portion of the setup. However, you may already know that when binding to a text box the actual binding does not trigger until AFTER the user leaves the control, in many cases this is good but not in our case. In our case I want to start the filter process as the user types (which is fine as I have all the filter data local, this is NOT fine if I have to do any type of remote call to filter the data as this will cause a bad user experience).

Triggering the binding in real time:

As I stated above the binding of a text box (or autocomplete text box) does not fire until you leave the control and this is not the desired action for us. In order to get around this we are going to create a custom behavior to allow the text box binding to push the value into our property in real time.

Our custom behavior is going to be called the ImmediateUpdateBehavior and the code can be found below.

    public class ImmediateUpdateBehavior : Behavior
    {
        protected override void OnAttached()
        {
            AssociatedObject.TextChanged += OnTextChanged;
        }

        void OnTextChanged(object sender, RoutedEventArgs e)
        {
            AssociatedObject.GetBindingExpression(AutoCompleteBox.TextProperty).UpdateSource();
        }

        protected override void OnDetaching()
        {
            AssociatedObject.TextChanged -= OnTextChanged;
        }
    }

In the behavior above you can see that all we are pretty much doing is listing for the TextChanged event and forcing the binding to fire. This is a nice way to do it when developing with MVVM.

Once we have our behavior created we need to attach it to our AutoCompleteTextBox and that can be found below.

Triggering the filtering to fire as we type:

I am going to chose to do this via a Command. I guess you could have the changing value of the property do the same thing but I typically am against doing this as I feel it is hiding the implementation details of the filtering. I also feel that this can cause unwanted side effects in your code if you are not careful.

In order to use the command I am going to use the EventTrigger behavior in silverlight to call my command. You can see this XAML below.

In the XAML above you see I am calling the KeywordSearchFilterCommand. This command will end up calling the code below

        private void KeywordSearchFilter()
        {
	    // Key here is i am simply notifying to rebuind these values and allowing the underlying methods to filter the data
            NotifyOfPropertyChange(() => SomeListOfValues);
            NotifyOfPropertyChange(() => PagedSomeListOfValues);
        }

As you can see from the above I am not doing anything special in the filter method I am simply notifying of property change and letting the various properties doing their own filtering. The code below is the filtering for my PagedSomeListOfValues property (we are doing client side paging here)

        public ObservableCollection PagedSomeListOfValues
        {
            get
            {
                var skipCount = PageIndex > 0 ? PageIndex * PageSize : 0;
                var takeCount = PageSize;
                var tempItems= SomeListOfValues.Skip(skipCount).Take(takeCount).ToList();

                var observableLinks = new ObservableCollection();
                observableLinks.SetContents(tempItems);

                return observableLinks;
            }
        }

Once you have your 2 properties (list and search field) bound to the AutoCompleteTextBox you are almost there, but not quite. In order to make this fully work you will want to also you the custom behavior and the filter command.

Hope this helps.

Till next time,

Getting around the Caching in the Silverlight Image Control

Derik Whittaker — Fri, 23 Sep 2011 17:24:42 GMT

Today I ran into a very odd issue when trying to reload the Silverlight Image Control with a new image which happened to have the EXACT same URL as the previously loaded image.

See in our application we provide a way to upload an image and also allow the user to not simply create a new image but rather swap out an existing image with a new one but leave the URL the exact same. During my development I really did not pay attention to or care that when I swapped out the image instance and raised the property changed event that the actual image was changing from the old to the new.

When I noticed that this was not working as expected I assumed that I could kill the instance of the object which was being bound to the <Image /> control in Silverlight and reset it w/ the new instance and that would trigger the reloading of the image via its url, however as you may have guessed this did not work. I had setup the binding to the control as follows:

Source="{Binding CurrentImage.SourceUrl}

I liked the binding code above (loading via URL rather than binary data) because I could easily hook into the loaded/failed events of the control in order to indicate to the user that there was something wrong with the image they are using.

It turns out (based on observations and Fiddler traces) that the Silverlight Image control will cache the current image and will NOT refresh/reload the image if the URL does not change. I guess the assumption is that if the same URL is provided multiple times don’t to waste cycles reloading it to only show the same image which is in memory.

This behavior works great in most cases…well until you don’t want it to work like this. I thought of a few ways to get around this issue, such as binding to a BitmapImage or binding to a byte[] array. However I really wanted to reduce the amount of rework or modifications I needed to make to the existing VM.

The solution we found that solved the issue was to bind to a image source url in the VM directly (did not want to dirty the existing SourceUrl Property as others user it and this work around is PURELY as UI issue, not a domain one) to a Url property in the VM and append an arbitrary query string value to the end of the URL.

       public string CurrentImageSourceUrl
        {
            get
            {
                if (CurrentImage != null)
                {
                    return string.Format("{0}?id={1}", CurrentImage.SourceUrl, Guid.NewGuid().ToString());
                }

                return string.Empty;
            }
        }

When I added the querystring value as above I was able to leave my existing VM logic alone and have the Image control reload the image correctly because it assumed that since my URL has changed that the images are different. I know this is a bit of a hack but hey it worked . If anyone knows of a better way to solve this please let me know.

Till next time,

Convention Based View Model Location using Ninject in a MVVM/Silverlight Application

Derik Whittaker — Sat, 02 Jul 2011 11:23:53 GMT

***** UPDATE *****
If you would like to see a video on this topic check out Episode 194 @ Dimecasts.Net
*******************

When building out a Silverlight application (or WPF application for that matter) the MVVM pattern is the pattern of choice for most projects I am aware of. When using MVVM there is a sub pattern which is commonly used which is known as ViewModelLocator. The ViewModelLocator concept basically tries to handle the repetitive task of coupling the View with its ViewModel but doing so in a way which removes any manual coding and it just ‘happens’.

Now if you have done any research on the ViewModel Location I am sure you have run across countless other blog posts out there which explain how to implement in this code, and many of them are great. In fact here are a few which helped me down the path of creating the code I am going to talk about in this post

Simple ViewModel Locator for MVVM by John Papa (this is the post which really kick started this pattern)
Wiring up ViewModel Locator w/ Silverlight
MVVM and ViewModel Location
Another MVVM and ViewModel Location
Caliburn.Micro has an implementation
MVVMLight has an implementation

All of the above posts basically show how to implement this pattern in your application and from what I can tell all of them work and will do the job. However, none of those (minus the Caliburn.Micro) implementations fulfills the one requirement I want which is to totally remove the need to ‘wire’ the ViewModel up to your View if even via XAML. I want to remove this wiring from the XAML because in my mind this still leaves me hard wiring the relationship rather than using convention based wiring. One scenario in which the hard wiring could turn around and bite you is in the times where you rename the view and the view model. If you fail to update your wiring code in XAML you will receive runtime errors.

Here are a few examples:
John Papa’s Implementation

DataContext="{Binding Source={StaticResource VMLocator}, Converter={StaticResource VMIndexerConverter}, ConverterParameter=MainPageViewModel}"

ViewModelLocator’s Implementation

    <UserControl.Resources>
        <ViewModels:EditUsersViewModelLocator x:Key="viewModelLocator"  />
    </UserControl.Resources>
    <UserControl.DataContext>
        <Binding Source="{StaticResource viewModelLocator}" Path="ViewModel" />
    </UserControl.DataContext>

I wanted my implementation of toe ViewModelLocator pattern to NOT need to know anything about the actual View or the ViewModel either in the XAML or in the code behind. What I wanted as the following:

DataContext="{Binding Source={StaticResource VMLocator}, Converter={StaticResource VMIndexerConverter}}"

Now you may be looking at my XAML above and comparing it to the XAML from John Papa’s post and be thinking what is really different? The difference is in this segment of code ConverterParameter=MainPageViewModel In his example he ‘hard wires’ the ViewModel which is being used up to the page and I did not want to do that. I wanted to use a standard naming convention (right, convention over configuration) and allow my locator to determine the ViewModel based on the current View.

So how did I implement my ViewModelLocator pattern, well lets take a look.

Code for ViewModelLocator

public class ViewModelLocator
{   
    private static readonly IDictionary<type, type> s_viewModelCache = new Dictionary<type, type>();
        
    public Type GetViewModelTypeForView( Type viewType )
    {
        var viewModelName = ResolveViewModelName(viewType.Name).ToLower();

        // We are try to cache the types in order to remove the assembly scan hit, this is optional of course and 
	// you may not want or need this
	// One thing to point out here is that this code ASSUMES that your view and viewmodel classes are in the 
	//  same assembly.  if this is not true for your project this code will not work as expected.  We made this
	//  assumption because it is true in our project
        var foundViewModelType = GetExistingTypeFromCache(viewType) ?? (from type in viewType.Assembly.GetExportedTypes()
                                                                        where viewModelName.Equals(type.Name.ToLower())
                                                                        select type).FirstOrDefault();
    
        // this will throw a custom exception type, you can use your own if you want
        if (foundViewModelType == null) { throw new ViewModelTypeNotResolvedException(viewModelName, viewType); }

        // Add the found view and viewModel to the cache
        AddToCache(viewType, foundViewModelType);

        return foundViewModelType;
    }

    private void AddToCache(Type viewType, Type foundViewModelType)
    {
        if (!s_viewModelCache.ContainsKey(viewType))
        {
            s_viewModelCache.Add(viewType, foundViewModelType);
        }
    }

    private Type GetExistingTypeFromCache( Type viewType )
    {
        if (s_viewModelCache.ContainsKey(viewType))
        {
            return s_viewModelCache[viewType];
        }

        return null;
    }

    private string ResolveViewModelName(string viewTypeName)
    {
        var asLowerViewTypeName = viewTypeName.ToLower();

	// ***** Below is OUR product's current naming conventions, replace with your own if you want *****
        // check to see if the view ends w/ "View"
        if (asLowerViewTypeName.EndsWith("view"))
        {
            return asLowerViewTypeName.Replace("view", "ViewModel");
        }

        if (asLowerViewTypeName.EndsWith("usercontrol"))
        {
            return asLowerViewTypeName.Replace("usercontrol", "ViewModel");
        }

        if (asLowerViewTypeName.EndsWith("childwindow"))
        {
            return asLowerViewTypeName.Replace("childwindow", "ViewModel");
        }

        return string.Concat(viewTypeName, "ViewModel");
    }

    public static IDictionary<type, type> ViewModelCache { get { return s_viewModelCache; } }
}

Code for IndexConverter

public class IndexerConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture) 
    {
        Contract.Requires<ArgumentNullException>(value != null);

        var locator = value as ViewModelLocator;

        Contract.Assume(locator != null,
                        string.Format(
                            "The provided converter value was expected to be of type {0} but was provided as type {1} which is not acceptable for this converter",
                            typeof(ViewModelLocator).Name,
                            value.GetType().Name));

        var viewType = GetViewType();

        var viewModelType = locator.GetViewModelTypeForView(viewType);

	// We are using the ServiceLocator pattern which is wrapping Ninject
        var viewModelInstance = ServiceLocator.Current.GetInstance(viewModelType);

        return viewModelInstance;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
        
    // This does incur a perf hit by looking at the stack trace, but in 
    //  my opinion this hit is worth it compared to having to manually wire items up
    private Type GetViewType()
    {
        var stack = new StackTrace();

        return stack.GetFrames()
            .Select(f => f.GetMethod())
            .Where(m => m.Name == "InitializeComponent")
            .Select(m => m.DeclaringType)
            .FirstOrDefault();
    }

}

Code needed in your App.Xaml

<MVVMLib:ViewModelLocator x:Key="VMLocator" />
<MVVMLib:IndexerConverter x:Key="VMIndexerConverter" />

Code for the custom Exception ViewModelTypeNotResolvedException

public class ViewModelTypeNotResolvedException : Exception
{
    public string ViewModelName { get; set; }
    public Type ViewName { get; set; }

    // Commented this out because i do not want to be able to create this without the VMName or the VName
    //public ViewModelTypeNotResolvedException() {}

    /// 
    /// Will build an instance of the exception and push in a default message based on the viewModelname and view properties.
    /// *** This is the lazy way to create the message ***
    /// 
    /// The name of the viewModel which was not able to be created or found
    /// The type for the view we were trying to bind the VM to
    public ViewModelTypeNotResolvedException(string viewModelName, Type view)
        : base(string.Format("When trying to resolve the view model {0} it was not found in the same assembly as the view {1}", viewModelName, view.Name))
    {
        ViewModelName = viewModelName;
        ViewName = view;            
    }

    /// 
    /// Will build an instance of the exception
    /// 
    /// The name of the viewModel which was not able to be created or found
    /// The type for the view we were trying to bind the VM to
    /// 
    public ViewModelTypeNotResolvedException(string viewModelName, Type view, string message) : base(message)
    {
        ViewModelName = viewModelName;
        ViewName = view;
    }

    /// 
    /// Will build an instance of the exception
    /// 
    /// The name of the viewModel which was not able to be created or found
    /// The type for the view we were trying to bind the VM to
    /// 
    /// 
    public ViewModelTypeNotResolvedException(string viewModelName, Type view, string message, Exception innerException)
        : base(message, innerException)
    {
        ViewModelName = viewModelName;
        ViewName = view;
    }
}

As you can see the code needed for this is not that complicated or difficult to implement.

One thing to understand with this post, I am NOT saying that the other implementations are bad or they do not work. In fact I am saying the exact opposite, they all are great and they all work and I used all their implementations as baseline for my implementation. What I am saying as the other examples did not meet my EXACT needs.

Please take a look at the code and let me know where I went wrong or what your thoughts are.

Till next time,

How to determine if a View is loaded off of the Backstack in WP7

Derik Whittaker — Tue, 30 Nov 2010 12:46:42 GMT

One of the great features (also one which is not fully implemented in my opinion) is the backstack in WP7. The idea of the back stack is that when you navigate away from a page that page is pushed to this stack so that when the user hits the back button (or it is done via code) the previous page can be reloaded off of the stack rather than being recreated.

This is both a powerful as well as clumsy feature of WP7. I say it is clumsy because there is nothing built into the framework (as far as I can tell) which tells you on page load if the page is being newly constructed or if it is being rehydrated via back navigation.

Because there are cases in our app that I want to know if the page is being accessed off of the backstack vs being newly created I set out to determine how I could build in the ability to detect this. After a bit of research on google I was not able to find any solutions so I built my own. Please note, that this may not be the best solution (I am open to hear about better ones) but it does appear to work.

Before we dive into the logic used to determine how a view is being loaded we need to understand the some page life cycle events and the order in which they fire.

Life cycle events for a newly constructed page (forward navigation)

Page Constructor
Page Loaded event fired
Page Unloaded event fired (when you navigate away from the page)

Life cycle events for a page being rebuild off of the backstack (back navigation)

~~Page Constructor~~ (this is NOT fired when being pulled off of the back stack as the page is not being created again)
Page Loaded event fired
Page Unloaded event fired (when you navigate away from the page)

Now that we understand the page life cycle events how do we determine how the page is being build?

1) Create an enumeration which helps us understand the life stage of the page

/// 
/// Enumeration to provide details on the view stage for a given view.
/// This is used to determine if a view is being newly constructed or if it has been
///     pulled off of the backstack
/// 
public enum ViewLifeStage
{
    /// 
    /// Will indicate that the view has been newly created.
    /// This will be set when the view has been navigated to via forward navigation
    /// 
    Constructed,        

    /// 
    /// Will indicate that the view has been reloaded off of the backstack
    /// This will be set when the view is navigated to via the back button/back stack
    /// 
    Rehydrated          
}

2) Set the initial life stage in the constructor of the page (remember this is ONLY hit on forward navigation)

ViewsLifeStage = ViewLifeStage.Constructed;

3) Update the life stage when you unload the page

ViewsLifeStage = ViewLifeStage.Rehydrated;

4) Check the life stage when you load a page (if needed)

if ( ViewsLifeStage == ViewLifeStage.Rehydrated )
{
    // do something here
}

As you can see from the steps above there is a few lines of code you need to create, but nothing too much. Again the above appears to work, but it may not be as elegant (oh and I am not sure I like the terms used in the enumeration, but that is a simply terminology change). If there is a better/cleaner solution for this please let me know.

Till next time,

My Silverlight Breakpoints are not being hit….How To Resolve this

Derik Whittaker — Fri, 25 Jun 2010 08:35:00 GMT

Today I was working on a Silverlight 4 side application and for some odd reason my breakpoints were not being hit when I was debugging. I took what I thought were the right steps to resolve the issue. I …

Killed the development web service
Killed and restarted Firefox (3.6.4)
Killed and restarted VS 2010

Sadly none of these options worked……hum

Next I hit up google for an answer. My blogger in crime Chris Bennage has a similar post here that I read through, and tried. However, this did not resolve my issue. However when reading through the comments someone said something that sparked a thought. That was to attach the debugger to the browser. So I tried this, however that also did not work, but I was on the right track.

In order for ME (and please note you may have a different end result than I did here) was to do the following.

Start the project without debugging so it would open up in the browser
Open up the Attach to Process dialog in VS
Change the ‘Attach to’ options and explicitly check Silverlight (this option may not be needed, but hey it worked)
Scroll down in the Process dialog until you find something that has the type set to ‘Silverlight’, If it says 'plugin-container.exe’ then you are on the right one (this is what the silverlight plugin runs in when running Firefox).
Click Attach
Debug away

Now again, this worked for me, this may NOT work for you. Also, there may be a better way to do this, but this works until I can find the root cause.

Till next time,