WPF offers a whole application paradigm based on navigation: The Navigation Application, hosted in a NavigationWindow, Frame or WebBrowser; consisting of XAML pages which are independent of each other; keeping track of the navigation history and restoring pages and their values while going forwards and backwards are supported out of the box.
However, some things are lacking. Suppose you have a data object model. In your application, you want to be able to select an object from a list, then click on a link to open a new page and edit the details of the object. When you are done, you want to select another object, and when you have repeated this a couple of times, you want to be able to go backwards using the back button, returning to the objects you edited on each page.
What is the problem here? WPF offers no built-in way to pass an object from one page to the other using XAML only. This has consequences. If you use the approach suggested in the WPF documentation, you will have to instantiate a new page object, pass the object you want to edit to its constructor, and navigate to it using the NavigationService.Navigate(Object) overload. However, pages which are navigated to this way are not disposed when they are no longer displayed, but retained in memory as a whole, and this has some side effects which I already talked about in this post.
So, what can we do about it?
The GoToPage Sticky Command
A sticky command is a command binding that is attachable to any XAML element and adds a certain functionality to this element without changing its code.
The GoToPage navigation command was one of my first experiments with the WPFGlue programming style. Since then, I have learned a few things and changed it considerably. One of the changes being that now the command which is the navigation command is no longer hardcoded, but could be any routed command which is configured to use the Navigation command implementation. This is how you use it:
By setting the Navigation.Command attached property on the NavigationWindow to the WPF GoToPage command, you enable all pages that the NavigationWindow hosts to use this command in order to navigate to other pages and pass along objects as DataContext for the new page.
In the page, you would use the command like this:
This button uses the selected item of a ListView as its DataContext. If clicked, it invokes the GoToPage command (set to its Command property) The selected item is bound to the CommandParameter property, which means that it will be passed as parameter to the GoToPage command. Finally, the URL of the page that should be navigated to is configured through the Navigation.Uri attached property.
How Does It Work?
The Navigation.Command property is a sticky property: in its change handler, it attaches a CommandBinding with the code that calls the Navigation command to the element it is set on:
This code follows a pattern that is typical for Sticky Components; I want to introduce them in more detail later, but we are going to encounter their patterns continuously here, so I want to point it out:
A Sticky Component needs to be able to clean up after itself. So, there are two procedures, Attach and Detach. The Attach method connects the sticky component by setting up CommandBindings or event handlers, the Detach method removes all these references between the Sticky Component and its hosting element. So, the Detach procedure needs to be called in two cases: either if the Sticky Component is removed from the element, or if the element is unloaded. So, the common pattern for Sticky Components is to call Detach when a Sticky Component is replaced on an element, and to reset the attached property that controls the Sticky Component in the element’s Unloaded event.
Navigation Flow Control
This is the method that finally gets called when the GoToPage command is invoked:
It uses the NavigationService.Navigate(Uri,Object) overloaded method, which allows to pass additional data into the navigation process. This additional data is the object that the user selected, and that was passed to the GoToPage command as parameter. The NavigationService will hold on to this object while the pages are changed. When the new page is loaded, we want to set the pages DataContext to the object, so we register a handler for the NavigationService’s LoadCompleted event.
The handler looks like this:
Notice that the first thing this procedure does is to unregister itself from the LoadCompleted event. This is because there is no guarantee that all navigation in the application will use our command. This handler makes sense only if the ExtraData of the NavigationEventArgs really contains an object which should be set to the DataContext of the new page. Thus, we register it specifically for this case, and unregister it immediately after use. I call this design pattern a “One Shot Event”.
Then, we set the DataContext of the new page. By the time the event occurs, this page can be found in the Content property of the NavigationEventArgs. However, we cannot set its DataContext directly: WPF is quite particular about when exactly during the lifetime of a page the DataContext is set; some validation features will not work properly if it is set too early, so we define a special attached behaviour that waits until the new page’s Loaded event occurs and then sets the DataContext:
Notice that the handler for the Loaded event not only removes itself from the page, but also resets the attached property that held on to the DataContext so as to leave no references to this object in places where they are not expected.
We want to be able to return to the page and still see the same object as DataContext. So, we need to save the DataContext to the Journal when the page is about to be left. This is where it gets tricky (again). The method to add custom information to the Journal is to implement a class that inherits from CustomContentState and set it to the CustomContentState property of the NavigatingCancelEventArgs that are passed into the NavigationService.Navigating event when the user tries to navigate away from the current page. However, CustomContentState objects are not stored as object references, but in serialized format, being deserialized as they are needed. This means that our DataContext would be serialized as well, making it impossible to return to the same instance. In order to work around this, we save the DataContext to a shared Session object in the background, and retain only an integer index, which can be serialized easily, while allowing us to retrieve the object later:
Since we don’t want to keep the DataContext object alive longer than its object model supposes it is alive, the Session object uses WeakReferences for storing the DataContext.
When the user navigates back to the page, the CustomContentState’s Replay method is called. In this method, the DataContext is retrieved from the Session object and put into the new page’s DataContext property, using the same method as before. Since we cannot use a CustomContentState more than once, we also have to set up the handling of the Navigating event again, so that the DataContext is saved again when the page is left.
Handling Expired Content
But what if the object that was the DataContext has be freed since the user last visited the page?
Handling this case gracefully almost drove me crazy. What I wanted to do was to navigate backwards one step and to clear the forward navigation stack so that the user couldn’t navigate to the page again. But I found no way of doing this that would work with all cases I wanted to cover: the API of the Journal is just too narrow. So, what I ended up doing was simply disabling the page and displaying a big fat Adorner on top of it, telling the user to go away and not come back… The Adorner can be styled using a ControlTemplate, a little bit like the Validation.ErrorTemplate, so you can make it less obnoxious; if anyone can tell me how to achieve what I originally wanted to do, I’ll be forever grateful.
Disabling the GoToPage Command
In the example, it makes no sense to try to go to the details page if no object is selected in the list. In cases like this, it is possible to disable the GoToPage command by setting the Navigation.CanNavigate property on the element that invokes the command. This can be done through a trigger, like in the example:
Or it could be done by binding this property to a property in a ViewModel.
Blocking Navigation Completely
Sometimes, it might be necessary to block navigation completely. On the details page, there is a ValidationRule that demands that the Name property contains a value. By binding the Navigation.BlockNavigation property to Validation.HasError on the Page element, one can disable all navigation away from the page until this property is filled. In order to support this behaviour, the following event handler is attached to the NavigationService.Navigating event:
Testing the Component
You will find the example application NavigationExample in the WPFGluePublished solution on the Downloads page. In this example, each page contains a “GC” button which forces the .Net garbage collection. By running the example in the debugger and following the debug output, you can see the lifetime events of the pages, and by forcing the garbage collection you can verify that the page objects get finalized when they are no longer needed, thus proving that the Navigation.Command didn’t leave behind any dangling references and doesn’t cause any memory leaks.
By adding some customers, editing their details, removing them, and going back using the NavigationWindow’s Back button, you can test the behaviour for pages whose DataContext has expired.
This example shows how it is possible to pass objects from page to page using XAML only, and how one can handle forwards and backwards navigation using object references. However, there are still some limitations: I don’t really like displaying expired pages, and since the Session object uses weak references, it might not be suitable for partial trust scenarios where there is no permission to execute unmanaged code.
In posts to come, I want to explore the possibilities of defining a navigation topology as a central resource. However, for this I will need the complete Sticky Component Framework, about which I will write as soon as possible…
Let me explain why WPF navigation could do with a little glue:
WPFGlue is about connecting a business object model to a user interface written in WPF, or to be more precise, entirely in XAML. So, let’s imagine the business object model is already there. To take the classic example: you’d have a Customer class that has an Orders collection with a couple of Order objects in it. In the application, you’d probably want to display a list of Customers, click on one to go to a new page that displays its details, including a link to this customers orders, which displays a List of Orders page, which leads to an Order Detail page etc. So, when you navigate from one page to the next, you need two bits of information: the URL of the page you want to go to, and the object or collection that the page should display.
The Object Selection Problem
The WPF documentation suggests passing objects to pages through constructors. This is safe but very unsticky, since it requires code behind. Moreover, pages that have been instantiated as objects and have not been called through a URL will not be freed when the user navigates away, but will be stuck in memory until the application shuts down. This makes great sense, because only by staying alive itself and holding on to its references to the business objects the page can be sure that the business objects still will be there when the user navigates back to it. However, it costs memory, and keeping business objects alive is a side effect that might not be appreciated. After all, the business object thinks it is responsible for its objects and collections, and finding an object still alive while the business object model doesn’t know it any more might have unwelcome effects.
So, this problem calls for two solutions: how to pass a selected object from one page to another while still using an URL, and how to handle object references while the user navigates back and forth through the journal.
The idea for solving the first problem is to create a combination of Sticky Properties, Sticky Behaviours and a Sticky CommandBinding. The CommandBinding would handle the NavigationCommands.GoToPage command, look for an URL and an object reference in Sticky Properties on the element that originated the command, and use the NavigationService.Navigate(URI,Object) method to navigate to the next page. The Sticky Behaviours would attach themselves to the Navigating and LoadCompleted events of the NavigationService and set the DataContext of the new page to the object that would be passed forward.
The Backward Navigation Problem
The idea for solving the second problem is to have a backup storage for object references, which can be accessed by index and restored when the user navigates backwards or forwards.
The mechanism for storing custom data in the Journal is a class called CustomContentState. By deriving from this class, one can add information to the journal that will be restored automatically when the user navigates forwards or backwards. Now, if one tries to add object references to a CustomContentState implementation, one finds out that these objects need to be serializable. What CustomContentState does is that it serializes itself, stores itself in the journal in serialized form, and is deserialized before the page is displayed again.
It is understandable why this is so: By serializing the data, one avoids having lots of unresolved object references in the journal, keeping objects from being freed and creating the same kind of side effect that is created by keeping pages alive. So, what can one do?
I decided to use WeakReferences to solve this problem. The WeakReferences are stored in a dictionary with an auto-incrementing number as index. When the user navigates away from a page, the system stores the DataContext in the dictionary and saves the index to this reference in the CustomContentState, which is retained by the Journal. When the user returns to the page, the CustomContentState tries to retrieve the DataContext using the index and the WeakReference to the object. If at this point the object has already been garbage collected, the WeakReference will show this. In this case, the CustomContentState will trigger a navigation further backwards, since the data of the page obviously has expired. If the data on all the preceding pages has expired, the application will end up on the start page, which must be able to create its own DataContext anyway (if any).
However, there is one drawback to WeakReferences: they require full trust, so they will probably not work in XBAP applications. I want to research that at some stage in the future.
The Navigation Topology Problem
It’s possible to use a hyperlink and to specify the URL of the page immediately in XAML. However, doing this means that the relationships between the pages are hardcoded in the pages themselves, and the sequence of pages and their links between each other, i.e. the navigation topology of the application, are distributed throughout all the pages. This is not very maintenance friendly, and it makes it more difficult to reuse pages in other places in an application.
The first solution to this would be to avoid URLs in the pages, and instead use a global navigation menu that is defined in a central location. The WPFGlue pattern for this would be a ViewModelKit, providing classes for Menus and MenuItems that can be configured in a resource dictionary. The View for the menu would then use this definition as ViewModel, and use it to create hyperlinks or navigation buttons. These in turn would rely on URLs set on the menu items in the resource dictionary.
I’d like to classify WPFGlue components according to what they do in the application. So far, the following categories came out:
The WPF navigation framework is just great. Especially the journal: you get the complete forwards and backwards navigation for free, the journal remembers the user input on the page, and this works even when pages are freed in order to save memory.
However, WPF navigation stops just short of being really sticky. Selecting an object on one page and passing it forward to another page is supposed to be done through code behind, and the journal serializes objects instead of hold references to them, which is in itself a wise thing to do in order to not keep these objects from being freed, but makes it difficult to return to the same object instance if one goes back to a page. Also, I don’t like the suggestion in the WPF documentation that the navigation topology should be defined through pages referencing each other through hyperlinks. In my opinion, the pages should work stand-alone as much as possible, and there should be a central definition for the navigation topology, defining the structure of the application and mapping pages to the appropriate places in the object model.
WPFGlue supports navigation through a sticky GoToPage CommandBinding which takes an object parameter and passes it to the DataContext of the new page, a sticky Session property which can hold WeakReferences to business objects while the journal stores pointers to these references, and a ViewModelKit for defining a navigation menu.
The need for localization is immediately obvious for every programmer whose mother tongue is not English. Surprisingly, in WPF localization seems to have been added more or less as an afterthought. While Visual Studio supports localization very nicely for Windows Forms applications, getting at resources contained in satellite assemblies is not straight forward in WPF, and even something as basic as detecting the system language and making it the default culture for display and formatting in the application requires extra work. I could imagine that in the beginning the creators of WPF thought that people would just write different XAML pages for different languages, as is done in HTML, and that the need for localizing XAML only arose after the power of XAML as a programming language became more apparent, and programming elements became more predominant on XAML pages than clear text.
In the Localization category, WPFGlue comes with some sticky MarkupExtensions which make it easier to localize an application. These MarkupExtensions get their values from standard .Net localized resources, so no need for LocBAML or third party tools there. Other MarkupExtensions can be used to set WPF elements’ Language property to the CurrentCulture or CurrentUICulture.
The commanding support in WPF is ingenious. It allows to implement some functionality once and to attach it to all the places where it is applicable, through RoutedCommands and CommandBindings. At the same time, commands decouple the traditional menu and toolbar from the application’s object model, making for great reusable code. Fabulously sticky stuff!
Commands are also the way ViewModels in the MVVM pattern expose their functionality to the user interface. The only unsticky thing about them is that CommandBindings support adding handler routines only through code, either code behind or explicitly. Also, there is no native general way of wrapping a method call into a command.
In the Commanding category, WPFGlue should support mapping commands to method calls, and also direct commands (ICommand implementations that are exposed by a ViewModel) to routed commands which can be handled centrally. There should be a way to set up a CommandSet and to connect it to a page, thus being able to define the available commands and their handlers in a central location. Also, the Commanding category contains a CommandGroup, which executes a series of commands in one go.
MVVM developers seem to avoid the validation features of WPF in favour of validation through the ViewModel or business model, exposed through the IDataErrorInfo interface. I don’t really understand why.
First of all, providing error messages to a user is not the job of a business object. The business object shouldn’t know whether it is used by an interactive user, a background service, or a batch job. In addition to that, in order to be able to provide meaningful error messages, the business object model would have to localize its error messages, and I wouldn’t want to burden my business objects with a job like that.
Second, while the business model knows what itself can do, it has no idea about what the developer of an application that reuses it may want to do. It would be perfectly justified to forbid certain legal property values because they are outside the scope of the current application. In this case, the ViewModel would have to constrain the values it allows for a certain property before it passes them on to the business object model.
So why not let the ViewModel do the job? I agree, the ViewModel is responsible. However, I wouldn’t use IDataErrorInfo, because that forces me to re-implement a lot of functionality that is already present in the WPF validation model. For example, resetting the values of an object to their pre-edit state before they are committed while still being able to provide instant validation feedback is really easy with ValidationRules and a BindingGroup, but requires a lot of effort, including ongoing maintenance effort, when done in a ViewModel specialized for a certain business model.
So, what I’d do instead is create a ViewModelKit that allows one to define a group of ValidationRules, which may or may not be dependent on validation functions in the business object model, and to allow setting these ValidationRules to a BindingGroup using a sticky property.
In addition to that, one would find workarounds for some minor problems with Validation.ErrorTemplate and ways to inform the ViewModel of validation results in the Validation category of WPFGlue.
Application services would be things like forwarding application lifetime events to the ViewModel or providing services that are available in the operating system environment without creating a dependency from the ViewModel to the View.
Examples for this are a MessageBox that is invoked through sticky properties, a sticky StartupCommand property, a markup extension that allows to include application settings in the user interface, or context sensitive help through sticky properties.
Common tasks would be jobs that recur in user interfaces, so that it makes sense to implement them in sticky ViewModels.
Examples would be a FileManager that provides support for the usual File menu commands for any type of document, a ListEditor that has commands for moving, adding and deleting items in collections implementing the standard collection interfaces, a ListPager that divides a collection into pages of a given length, and the like.
This is only a tentative list. The only category that will definitely survive is Common Tasks, since the others hopefully will be replaced by native support through WPF as the framework develops and the gaps between business object model and user interface vanish, so that there is no more need to fill them with glue.