Question

So I am currently working on a UI written in WPF. One thing I really like about WPF is the way it leads you to write more decoupled, isolated UI components. One pain point for me in WPF is that it leads you to write more decoupled, isolated UI components that sometimes need to communicate with one another :). This is probably due to my relative lack of UI experience, especially in WPF (I’m not a novice, but most of my work is far more low level than UI design).

Anyway, here is the situation:

At any one time, the central area of the UI displays one of three views implemented as UserControls, let’s call them Views A, B, and C.

The user will be switching between these views at various times, and there is more than one way to switch views (this works well for the customer, causes some pain in code design currently).

Right now each view switching mechanism does its own thing to transition to another view. A certain singleton class takes care of storing data and communicating between the views. I don’t like this, it’s messy, error prone, and the singleton class knows way too much about the details of the UI. I want to eliminate it as much as is possible.

I ran into a bug today that had to do with the timing of switching between views. To make it simple, one view needs to perform some cleanup when it is unloaded, but that cleanup erases some data that is needed for another view. If the cleanup runs after the other view is loaded, problems ensure. See what I mean? Messy.

I am trying to take a step back and imagine a different way to get these views loaded with the data they need to do their job. Some of you more experience UI / WPF people out there must have come across a similar issue. I have a couple of ideas, but I am hoping someone will present a cleaner approach to me here. I don’t like depending upon order of operations (at a high level) for my code to work properly. Thanks in advance for any help you may be able to offer.

Answer 1

I would recommend some kind of parent ViewModel that handles the CurrentView. I wrote an example here a while back if you’re interested.

Basically the parent view will have a List<ViewModelBase> AvailablePages, a ViewModelBase CurrentPage, and an ICommand ChangePageCommand

How you choose to display these is up to you. My preferred method is a ContentControl with it’s Content bound to the CurrentPage, and using DataTemplates to determine which View should be displayed based on the ViewModel stored in CurrentPage