Search
Recent Tweets

Entries in Silverlight (9)

Sunday
Feb192012

Windows Phone Login Navigation

A common desire for a mobile application is showing a welcome / login type screen initially when an account is required and the user first runs the app. My past two Windows Phone apps have not needed this but my current one does. I thought it would be very simple and straightforward; just check some user settings in App.xaml.cs and conditionally navigate to a different page depending on whether validated credentials are present.

Some Problems

It turns out it was not quite that straightforward. First of all the process of navigating to MainPage.xaml (or whatever startup page you use) is already underway in App.xaml.cs. Navigating to another page required either cancelling that navigation or using UriMapper to setup the initial page. This post by Peter Torr provided a great starting point. I chose the UriMapper approach and it worked in terms of conditionally changing the initial page.

However, after initially navigating to the welcome / logon page when credentials were missing, I tried redirecting back to MainPage.xaml after credentials were validated but nothing happened. The welcome page remained on screen and it was not obvious why the navigation to MainPage.xaml was not working.

Solutions

In turning to a programmer's best friend (Stack Overflow), I found this WP7 sign-in redirect post. That post suggested that the only real option was making the main page conditionally show a login control or pop-up. I was not fond of that approach; for one it did not seem like a good separation of responsibilities. For another it meant dynamically hiding/showing or covering/uncovering content and it felt like the experience would be worse for both the end user and myself.

Late last night I decided to experiment a bit more with the separate welcome screen approach and did manage to get it working, though there may be a better approach.

The main class looks like this:
public class StartupNavigator : IStartupNavigator
{
	private readonly UserSettings _userSettings;
	private PhoneApplicationFrame _rootFrame;

	private const string MainPage = "/MainPage.xaml";

	public StartupNavigator(UserSettings userSettings)
	{
		_userSettings = userSettings;
	}

	public void Initialize()
	{
		_rootFrame = ((App) Application.Current).RootFrame;
		SetupUriMapper();
	}

	private void SetupUriMapper()
	{
		var map = new UriMapper();
		map.UriMappings.Add(new UriMapping {Uri = new Uri(MainPage, UriKind.Relative)});
		_rootFrame.UriMapper = map;

		var navPath = _userSettings.HasValidatedCredentials ? MainPage 
			: "/Pages/WelcomePage.xaml";
		map.UriMappings[0].MappedUri = new Uri(navPath, UriKind.Relative);
	}

	public void GoHome()
	{
		_rootFrame.Dispatcher.BeginInvoke(() =>
		{
			// recalculate URI mapping - should have a different answer now 
			// on validated credentials. this is needed
			SetupUriMapper();
			// we need to vary the query string, otherwise OS doesn't think we 
			// are navigating to different page and won't do anything. Despite 
			// changing the initial Uri mapping from Main Page to login/welcome, 
			// _rootFrame.CurrentSource remained as /MainPage.xaml the whole time.
			_rootFrame.Navigate(new Uri(MainPage + "?fromLogin=true", UriKind.Relative));
		});
	}
}

Keys to the Solution

The SetupUriMapper method takes care of setting the correct initial page to be navigated to according to whether validated credentials exist in settings. The less obvious part is the GoHome method which will later get invoked from the welcome / login page's ViewModel once the user's credentials have been validated. As the comments indicate, the root frame's UriMapper needed to be set again now that MainPage.xaml is now the starting point instead of WelcomePage.xaml.

Next, when navigating to MainPage.xaml, I had to add a query string parameter just so the Uri changed a bit. Despite changing the initial Uri mapping before, RootFrame.CurrrentSource remained as /MainPage.xaml during the process (set in WMAppManifest.xml). Windows Phone appeared to be ignoring the request to navigate to MainPage because it detected the Uri was not changing.

Perhaps my understanding of this is flawed and there may be a better approach; in either event, I would love to hear about it. This was the main gotcha I ran into. For subsequent page navigation I went with the standard navigation approach I have used in the past - see this bitbucket code for an example.

Hitting the back button after a successful login will take the user back to the welcome page and hitting it again will exit the app. This provides the expected behavior for certification purposes, though you might be able to get away with calling NavigationService.RemoveBackEntry() later in MainPage.xaml if the previous page was WelcomePage.xaml and you did not want to navigate back to the welcome page. Subsequent runs of the app with valid credentials results in a direct navigation to MainPage.xaml where pressing the back button will exit the app.

The Rest of the Story

Hopefully what follows is more typical / obvious...

The user settings class that StartupNavigator uses is straightforward:
public class UserSettings
{
	private readonly ISettingsHelper _settingsHelper;

	public UserSettings(ISettingsHelper settingsHelper)
	{
		_settingsHelper = settingsHelper;
	}

	public string Username
	{
		get { return _settingsHelper.GetString("Username"); }
		set
		{
			_settingsHelper.SetSetting("Username", value);
		}
	}

	public string Password
	{
		get { return _settingsHelper.GetPrivateString("Password"); }
		set
		{
			_settingsHelper.SetPrivateString("Password", value);
		}
	}

	public bool? CredentialsValidated
	{
		get { return _settingsHelper.GetBool("CredentialsValidated"); }
		set
		{
			_settingsHelper.SetSetting("CredentialsValidated", value);
		}
	}

	public bool HasValidatedCredentials
	{
		get
		{
			return !string.IsNullOrEmpty(this.Username) 
				&& !string.IsNullOrEmpty(this.Password)
				&& true == this.CredentialsValidated;
		}
	}

	public void Save()
	{
		_settingsHelper.TrySave();
	}
}
In App.xaml.cs at the end of the constructor the startup navigator is initialized which sets up the UriMapper:
public App()
{
	// ... default App ctor initialization here	
	InitializeIoC();
    IoC.Get<IStartupNavigator>().Initialize();
}

private static void InitializeIoC()
{
	IoC.LoadModules(new MainModule());
}
When validated credentials were not found in settings, WelcomePage.xaml is navigated to which kicks off the WelcomeViewModel:
public class WelcomeViewModel : AppViewModelBase
{
	private readonly UserSettings _userSettings;
	private readonly IUserValidator _userValidator;
	private readonly IStartupNavigator _startupNavigator;

	public WelcomeViewModel(UserSettings userSettings, IUserValidator userValidator, 
		IStartupNavigator startupNavigator)
	{
		_userSettings = userSettings;
		_userValidator = userValidator;
		_startupNavigator = startupNavigator;
	}

	private string _username;
	public string Username
	{
		get { return _username; }
		set
		{
			if (_username != value)
			{
				_username = value;
				RaisePropertyChanged(()=> Username);
			}
		}
	}

	private string _password;
	public string Password
	{
		get { return _password; }
		set
		{
			if (_password != value)
			{
				_password = value;
				RaisePropertyChanged(()=> Password);
			}
		}
	}

	private void GetStarted()
	{
		// go ahead and save settings now. if incorrect and user comes back in 
		// another session, we want those values to stick
		_userSettings.Username = this.Username;
		_userSettings.Password = this.Password;
		_userSettings.Save();

		_userValidator.Validate(this.Username, this.Password, OnLoginSuccess);
	}

	public void Load()
	{
		this.Username = _userSettings.Username;
		this.Password = _userSettings.Password;
	}

	private void OnLoginSuccess(User user)
	{
		_userSettings.CredentialsValidated = true;
		_userSettings.Save();

		// TODO: do something with user result; persist somewhere so we don't have 
		// to fetch data again. Then on MainPage, elsewhere we can access later.
		Debug.WriteLine("Welcome " + user.Fullname);
		
		_startupNavigator.GoHome();
	}

	public ICommand GetStartedCommand
	{
		get {return new RelayCommand(GetStarted); }
	}
}
The user validation class simply creates a service client class that invokes a service method to validate the user credentials entered.
public class UserValidator : IUserValidator
{
	private readonly AppSettings _appSettings;
	private readonly IMessageBoxService _messageBoxService;

	public UserValidator(AppSettings appSettings, IMessageBoxService messageBoxService)
	{
		_appSettings = appSettings;
		_messageBoxService = messageBoxService;
	}

	public void Validate(string username, string password, Action<User> onSuccess)
	{
		if (string.IsNullOrEmpty(username) || string.IsNullOrEmpty(password))
		{
			_messageBoxService.ShowOKDispatch("Username and Password are required.", 
				"Required data");
			return;
		}

		var client = new DataClient(_appSettings.ApiKey, username, password);
		client.UserInfoComplete += (sender, args) =>
		{
			if (string.IsNullOrEmpty(args.Result.ErrorMessage))
				onSuccess(args.Result.Result);
			else
				_messageBoxService.ShowOKDispatch(args.Result.ErrorMessage, 
					"Login Failed");
		};

		client.FetchUserInfo();
	}
}

Sample Project

Download WinPhoneLoginRedirect.zip for a working sample project.

Wednesday
Jan252012

Windows Phone: App Config Settings - Thinking Outside the Box

File this post under the OCD, late night, crazy category. I just started a new Windows Phone application and have been working on a client for a service my app depends on. I wanted to test out the service interactions but with unit tests of my WP7 class library, not via building out a user interface.

Quickly there were a couple minor snags that I allowed myself to get bogged down in:
  • State of testing support - The last time I attempted unit testing with WP7 I was not real happy with the testing support. Is it better now? Is there another better approach? More on this in an upcoming post; I changed my mind and decided to follow the single responsibility principle for this post :).
  • Where to put service credentials, other test settings - The service API being tested requires a private API key, username and password. I thought the client and tests might go public later and I did not have a separate test account, only my own credentials. Where and how should these values be stored and passed to the tests so they are somewhat protected and configurable?

Config Settings Goals

In this context I am referring to settings as the rough equivalent of standard <appSettings>, not runtime settings for the app and user. My context is also currently one of a unit testing app project but some of this could be applicable to other projects as well.

There are a few options but I wanted one that addressed the below, some of which conflict. Goals:
  1. Private settings - Namely keeping the credentials out of source control and any public distribution. I need to keep this data out of the tip as well as all revision history. If I have to remember to remove personal settings prior to a commit or publish, it is only a matter of time before I forget.
  2. Configurable - Ideally these settings could be edited in a file w/o being manually typed into app code
  3. Isolation - Some way to keep the more private settings separated from everything else, maybe outside the solution / IDE
  4. Default settings - Exclusions and isolation implies the container for these settings might not exist (new source control pull etc.). However everything still needs to build and there should be a way to create empty/default settings when not found. It also needs to be obvious where/how people supply their own values for these settings.
  5. Runtime performance - Preferably there would not be any real runtime I/O for these settings so test performance does not take a hit. These "app settings" are not changing during the course of an app / test execution run but they may change between runs.

Hard-coding settings

Manually hard-coding the credentials to test with is the easiest option and what I started with but it does not address any of goals above with the exception of #5 Runtime performance.

App.config

There is not really a concept of app.config for windows phone projects. Someone created a modified WP7 version of the mobile configuration block that could be used but it felt a bit forced to me and has some overhead.

Isolated storage

Isolated storage is more suited for runtime user settings / options / preferences to me. IsolatedStorageSettings.ApplicationSettings is an option but I cannot easily create, view and edit app config type settings without doing something programmatically or using some kind of isolated storage browser. The data will not be there to start with and the initial values have to come from somewhere. Additionally changes to the settings will be lost anytime the emulator app is restarted. Even all that aside, isolated storage doesn't quite meet the runtime performance goal and there are various caveats and serialization issues I have run into in the past. If you are interested in runtime user settings however, the code in my Codestock post has an example (just search for settings).

App.xaml

A custom settings class can be created and instantiated in App.xaml resources. First a simple TestSettings class:
public class TestSettings
    {
        public string ApiKey { get; set; }
        public string Username { get; set; }
        public string Password { get; set; }

        private static TestSettings _default;

        public static TestSettings Default
        {
            get { return _default; }
            set
            {
                if (null == _default)
                    _default = value;
            }
        }
    }
Next TestSettings.xaml to instantiate and configure the class.
<ResourceDictionary 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:DataBoundApp1"
    >
    <local:TestSettings x:Key="Settings" 
        ApiKey=""
        Username=""
        Password=""
    />      
</ResourceDictionary>
Then in App.xaml the resource is merged in:
<Application 
    x:Class="DataBoundApp1.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"       
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone">

    <Application.Resources>
        <ResourceDictionary Source="TestSettings.xaml" />
    </Application.Resources>

	<!-- ... -->
</Application>
Now we can set default settings in App.xaml.cs, or refer to the App class elsewhere:
private void Application_Launching(object sender, LaunchingEventArgs e)
{
	TestSettings.Default = this.Settings;
}

public TestSettings Settings
{
	get { return (TestSettings)this.Resources["Settings"]; }
} 

/* or elsewhere:
//    var settings = ((App)Application.Current).Settings
*/
All of that is fine and good except it does not meet the goal on private settings. If I plug my private settings in TestSettings.xaml, I have to remember to later empty those out. I cannot just exclude the file from source control as it is required to compile the app.

One solution is to use pre and post build events to temporarily swap settings in and out automatically. We can create 2 new copies of TestSettings.xaml outside of Visual Studio to facilitate this. TestSettingsPrivate.xaml will contain the personal / private settings values that we do not want in the project or source control. TestSettingsDefault.xaml will contain the empty (or default) settings that we want to include in the project and source control for others as a starting point. TestSettings.xaml will be our "Main staging area" that will be replaced before and after; sort of like Towers of Hanoi or a shell game, except not. :)

In the pre-build event of the test project (all on one line):
if exist "$(ProjectDir)TestSettingsPrivate.xaml" xcopy /y "$(ProjectDir)TestSettingsPrivate.xaml" "$(ProjectDir)TestSettings.xaml"

and then in the post-build event (all on one line):
if exist "$(ProjectDir)TestSettingsDefault.xaml" xcopy /y "$(ProjectDir)TestSettingsDefault.xaml" "$(ProjectDir)TestSettings.xaml"

If the default and private settings do not exist, as in the case of a new source control pull, then the default/empty contents of TestSettings.xaml get used. In that case you might wonder why bother with TestSettingsDefault.xaml when TestSettings.xaml could be "backed up" and restored automatically. The main reason has to do with the way Visual Studio locks files during a build; trying to make a copy either did not work or generated an "exited with code 2" failure.

Just before the build the test settings file will get replaced by the private settings file and that will get compiled into the assembly. A moment later after the build the test settings file will get reset back to the defaults just as if nothing happened. I thought Visual Studio might pop-up a "this file has been modified outside the environment" type dialog but that was not the case.

If we peek into the assembly contents we can see the private settings were sucked into the DLL while the empty/default TestSettings.xaml remains without the private settings post-build.



Granted when distributing the project I need to be sure not to include the compiled DLL and the private settings file. This is not a problem if I exclude them from source control, only if I zip up the directory. If using Mercurial for source control my .hgignore file might look like the below:
	syntax: glob

	*.csproj.user
	obj/
	bin/
	*.ncb
	*.suo
	_ReSharper.*
	*.resharper.user
	MyApp.Tests/TestSettingsPrivate.xaml
Download DataBoundApp1.zip for an example project of this approach.

T4 and JSON Settings

Another option is T4. First I added a new text file TestSettings.txt to the project. Then I renamed .txt to .t4 (.tt works too) and set the file's Custom Tool to TextTemplatingFileGenerator. In the T4 file I first setup the generation of what will become TestSettings.generated.cs:



Next the T4 file looks for a TestSettings.json file (not included in the project) and if it does not exist it creates it by instantiating a new instance of TestSettings and serializing that to JSON (JSON Helper method shown later). One thing to note is the use of file I/O methods like File.CreateText; these are marked [SecurityCritical] and we cannot call them at runtime in a windows phone app but at "design time" in the IDE it works fine. Another thing to note is that Host.ResolvePath throws an exception if the file does not exist; the reference to App.xaml is just to get a fixed handle on some valid file so we can resolve the directory.



Why JSON for the settings? Well if you have just string properties you can get away with simple string.split, name/value pairs etc. With other data types JSON makes more sense and it is pretty readable and hand-editable (maybe with the exception of dates). Why create a custom format or go through more overhead with XML when JSON works fine? The next block of code reads the json file and builds a C# code block that will instantiate TestSettings in the generated code class.



Finally the T4 has a JSON helper method to serialize the settings object. I tried using JSONSerializer initially but it was throwing "could not find file or assembly ..." exceptions.

TestSettings.json will get created initially when it does not exist with empty values. It can then be hand-edited outside the IDE.
{
  "ApiKey": "SecretKey",
  "Username": "SecretUsername",
  "Password": "SecretPass!",
  "IntProperty": 0,
  "BoolProperty": false,
  "DateProperty": "\/Date(-62135578800000-0500)\/"
}
This T4 will produce a TestSettings.generated.cs that looks like below. Note that for this example I took the existing TestSettings.cs and made it a partial class and added some properties of other data types just for testing.
namespace MyApp.Tests
{
    // see also TestSettings.json outside ide in this folder for default values
	public partial class TestSettings //.generated.cs
	{
		private static readonly TestSettings _defaultInstance;

		public static TestSettings Default
		{
			get {return _defaultInstance;}
		}	

		static TestSettings()
		{
			_defaultInstance = new TestSettings
			{
				ApiKey = "SecretKey",
				Username = "SecretUsername",
				Password = "SecretPass!",
				IntProperty = 0,
				BoolProperty = false,
				DateProperty = System.DateTime.MinValue       
			};
		}
	}
}
At this point you may be thinking, "so what? you've just hard-coded the settings again but in a more elaborate way." That is true to an extent but this generated code class as well as the settings json file are both discardable now. As long as the t4 file is there it will take care of the rest. These can be excluded from source control just like the private XAML settings file. This approach has the advantage of only needing a single settings file and it is the least hit to performance at runtime as the work is already done and compiled by then just as if I hard-coded the settings by hand.

By default with this approach if I update the settings file I have to manually re-run the T4 transformation. However I can use something like Chirpy to automatically run the T4 on every build if desired.

Download: TestSettings.t4

Conclusion

This certainly isn't an exhaustive list of possibilities and some of this may be a bit crazy but at any rate it is food for thought.
Saturday
Feb122011

WP7 In-app Searching, Filtering Part II

In my first post on WP7 in-app searching / filtering I presented a quick, first pass solution to this task. Justin Angel left some good suggestions in his comments and I wanted to enhance this feature a bit now that I've finally had a little bit of time to return to Windows Phone development. This second pass includes enhancements such as:
  • Replacing ugly search form buttons with a contextual application bar
  • Animating search textbox visibility (fade-in / out)
  • Small moves towards "framework-ifying" search in separate class library
  • Customization of search application bar along with hide keyboard button
  • Smoother search switching from keypress to timer search trigger
  • Demo solution for download and hopefully reader contributions

The video to the right shows the search operation in action. The search works fine in landscape orientation as well as on my Samsung Focus phone, the video recording is just easier with the emulator.

I am only going to touch on changes made to the 1st pass of this functionality, so refer to the original post for any other background information.

Contextual App Bar

Removing the buttons beside the search textbox freed up space but more importantly it provides a much more polished look and is more consisent with Windows Phone usage patterns.

In the search control there is now support for specifying what application bar icons / features to use when the search control is active (focused). I originally did this because I had issues getting app bar icons working from within a class library and this allowed it to work with any images. In addition to the built-in commands of deleting, hiding the keyboard and closing search, a custom option allows executing an arbitrary command (not shown here).

<fwCtl:SearchControl x:Name="uxSearchControl" SearchCommand="{Binding SearchCommand}" Margin="0,0,0,0" Visibility="Collapsed">
	<fwCtl:SearchControl.AppBarItems>
		<fwCtl:SearchAppBarItem IconUri="/Images/appbar.delete.rest.png" Action="Delete" />
		<fwCtl:SearchAppBarItem IconUri="/Images/MB_0036_keyboard.png" Action="Keyboard" />
		<fwCtl:SearchAppBarItem IconUri="/Images/appbar.close.rest.png" Action="Close" />
	</fwCtl:SearchControl.AppBarItems>
</fwCtl:SearchControl>
When the search control loads up, it sets up the actions and resolves the page the search control is on. This is used later to backup the original application bar that is temporarily replaced when the search control is active.
private void Init()
	{
		this.Loaded += SearchControl_Loaded;
		this.Searcher = new Searcher();
		_actions = new Dictionary<SearchActions, Action<SearchAppBarItem>>
					   {
						   {SearchActions.Delete, (i) => Clear()},
						   {SearchActions.Close, (i) => Close()},
						   {SearchActions.Keyboard, (i) => ToggleKeyboard()},
						   {SearchActions.Custom, (i) =>
								{
									if (null == i.Command || !i.Command.CanExecute(null)) return;
									i.Command.Execute(null);
								}}
					   };

		uxSearchTextBlock.GotFocus += (s, e) => {SetContextAppBar(); HasSearchFocus = true; };
		uxSearchTextBlock.LostFocus += (s, e) => { RestoreAppBar(); HasSearchFocus = false; };
	}

	private PhoneApplicationPage Page { get; set; }

	private void SearchControl_Loaded(object sender, RoutedEventArgs e)
	{
		if (DesignerProperties.IsInDesignTool) return;
		LayoutRoot.Background = new SolidColorBrush(Colors.Transparent);
		
		this.Page = this.FindParent<PhoneApplicationPage>();

		this.Opacity = 0;
		this.Visibility = Visibility.Collapsed;
	}

	private Dictionary<SearchActions, Action<SearchAppBarItem>> _actions;
The context app bar is setup once and the page application bar simply gets swapped out as focus enters and leaves the search textbox.
private void SetContextAppBar()
{
	if (null != this.ContextAppBar)
	{
		this.Page.ApplicationBar = this.ContextAppBar;
		return;
	}
	
	this.OriginalAppBar = this.Page.ApplicationBar;

	// might want a setting for menu support, auto-create menu items for buttons
	var bar = new ApplicationBar {IsVisible = true, IsMenuEnabled = false, Opacity = 1};

	this.AppBarItems.ToList().ForEach(i =>
	{
		var btnText = (i.Action != SearchActions.Custom ? i.Action.ToString() : i.Text);
		var btn = new ApplicationBarIconButton { IconUri = i.IconUri, Text = btnText, IsEnabled = true };
		btn.Click += (s, e) => _actions[i.Action](i);
		bar.Buttons.Add(btn);
	});

	this.ContextAppBar = bar;
	this.Page.ApplicationBar = this.ContextAppBar;
}

private IApplicationBar OriginalAppBar { get; set; }
private IApplicationBar ContextAppBar { get; set; }

I am not sure what the best way is to go about swapping out application bars. Performance might be slightly better just using one application bar and removing and adding buttons. I did not notice a real performance problem though I did notice a slightly longer transition with the initial switch then on subsequent show/hide search operations.

Animating visibility transition

I started off using VisualStateManager in the search control's XAML but in the end it was not buying me much. I also switched from a sliding to a fade in/out animation and I found the later to be rather common so I went with a UIElement extension as opposed to repeating in XAML.
public static void FadeInAndShow(this UIElement target, double seconds, Action afterComplete)
{
	target.Opacity = 0;
	target.Visibility = Visibility.Visible;
	var da = new DoubleAnimation
	{
		From = 0.0,
		To = 1.0,
		Duration = TimeSpan.FromSeconds(seconds),
		AutoReverse = false
	};

	Storyboard.SetTargetProperty(da, new PropertyPath("Opacity"));
	Storyboard.SetTarget(da, target);

	var sb = new Storyboard();
	sb.Children.Add(da);

	if (null != afterComplete)
	{
		EventHandler eh = null;
		eh = (s, args) =>
				 {
					 //sb.Stop();
					 sb.Completed -= eh;
					 afterComplete();
				 };

		sb.Completed += eh;
	}

	sb.Begin();
}
On the fade-in an action is specified to automatically set focus into the search textbox to start typing once the animation has completed.
public void ShowHide()
{
	if (this.Visibility == Visibility.Collapsed)
		Show();
	else
		Close();
}

private void Show()
{
	this.FadeInAndShow(.8, () => uxSearchTextBlock.Focus());
}

private void Close()
{
	RestoreOriginalUI();
}

private void RestoreOriginalUI()
{
	button.Focus(); // how else to hide keyboard?
	RestoreAppBar();
	Clear();
	this.FadeOutAndCollapse(.5);
}

private void RestoreAppBar()
{
	this.Page.ApplicationBar = this.OriginalAppBar;
}

private void Clear()
{
	this.Searcher.Clear();
}

Timer-based Search

Searching immediately upon a keypress / property changed event was a bit overkill and introduced some lag on larger lists. It now simply toggles an invalidated property and a timer periodically inspects that and searches when needed. The interval might be a good target for a configurable property.
public class Searcher : NotifyPropertyChangedBase
{
	private DispatcherTimer _timer;

	private void EnsureTimerIsRunning()
	{
		if (null == _timer)
		{
			_timer = new DispatcherTimer() {Interval = TimeSpan.FromSeconds(.7)};
			_timer.Tick += (s, e) =>
							   {
								   if (Invalidated) ExecuteSearch();
							   };
		}

		if (!_timer.IsEnabled)
			_timer.Start();
	}

	private void ExecuteSearch()
	{
		if (null != this.SearchCommand && this.SearchCommand.CanExecute(null))
		{
			this.SearchCommand.Execute(this.SearchText);
			Invalidated = false;
		}
	}

	private string _searchText;
	public string SearchText
	{
		get { return _searchText; }
		set
		{
			if (_searchText != value)
			{
				EnsureTimerIsRunning();
				_searchText = value;
				Invalidated = true;
				OnPropertyChanged("SearchText");
			}
		}
	}

	private ICommand _searchCommand;
	public ICommand SearchCommand
	{
		get { return _searchCommand; }
		set
		{
			if (_searchCommand != value)
			{
				_searchCommand = value;
				OnPropertyChanged("SearchCommand");
			}
		}
	}

	private bool _invalidated;
	public bool Invalidated
	{
		get { return _invalidated; }
		set
		{
			if (_invalidated != value)
			{
				_invalidated = value;
				OnPropertyChanged("Invalidated");
			}
		}
	}

	// or Reset()
	public void Clear()
	{
		this.SearchText = string.Empty;

		// i.e. value cleared, full list
		if (this.Invalidated)
			ExecuteSearch();

		this.Invalidated = false;

		if (null != _timer && _timer.IsEnabled)
			_timer.Stop();
	}        
}

Demo Solution and Final Thoughts

Feel free to download and improve upon the demo solution. It's from a stripped down, earlier version of my app and there is plenty of room for improvement. I have only begun to cleanup the 1st pass and I haven't exercised the searching / filtering functionality outside of the single use case in my current app. The search feature is the only functionality hooked up in the demo.

Some things to consider for enhancing this:
  • Styling enhancements such as moving the search icon "inside the textbox"; this originally presented some oddities so I pulled it.
  • Additional dependency properties to allow changing more behavior characteristics
  • Watermark textbox; ignored here since I autofocus to search textbox
  • More generalization / "frameworkification" of searching / filtering
  • Looking at AutoCompleteBox perhaps; my current usage is more for filtering down a list then just for picking an item
  • Performance improvements and general code cleanup