views:

397

answers:

2

I am working on a WPF app and the UI is getting a bit complex to manage. I am looking for advice on how to maintain it as it grows.

The layout looks something like this

<Grid>
   <List of Objects View/>
   <Objects Relationship View/>
   <Object Details View />
   <Multiple Objects Details View/>
   <View 5 />
   <View 6 />
     :
     :
</Grid>

Each view gets created (visibility hidden) and bound to some complex data, when the window is constructed. I want only one view visible, to the user at a time. I do this by manipulating visibility.

But the problem is the transition between views doesn't involve just fliping Visibility. It involves rebinding with currentdata, stoping background threads/timers and starting new ones (and possibly some binding again) that support the newly selected view. So what's happening is with every new view I add, I am adding a whole bunch of code to take care of all the possible transitions.

Is there some pattern I can use to deal with this kind of scenario?

Also is there some way I can avoid creating and hiding everything at app load and using visibilty as a controller?

Any help is greatly appreciated. Thanks!

+2  A: 

May I ask how you are allowing the user to switch back and forth between the views? Is it a key combo? Mouseclick?

Not that it's answering your question per se, but my suggestion is that this sounds like a perfect scenario for a tab control. And with WPF, it doesn't necessarily have to look anything like a tab control.

If you use a TabControl, it opens up the possibility of using the SelectionChanged event coming off of the TabControl to allow you to tell background threads to stop and you can unload anything that you need to unload.

Depending on how you use the TabControl, the UI can be somewhat virtualized. What that means is that whenever a tab is unselected all of the UI for that tab is destroyed and recreated the next time it's selected. It will behave this way if you use the MVVM or PresentationModel pattern and load ViewModels as the items for your TabControl and use DataTemplates for the views. If you just put TabItems into the TabControl with controls inside of them, it will not behave this way, however.

As far as patterns are concerned, I'd definitely recommend MVVM. It may take a bit of time to catch up to it and understand it, but I'd never do WPF without it. If you need anymore resources or examples, let me know.

edit:

I reread your question and noticed that you may be in need of another type of navigation. If you've got views that are needing to make transitions to other views based on user actions and you don't want all of the views to be presented to the user so that they can select which one they want to look at (like the TabControl will do), you may want to look at WPF Navigation. Navigation is basically something that MS added in with WPF to allow browser style navigation in a WPF app. This MSDN article should be a good resource on that kind of thing.

dustyburwell
On a side note, using the TabControl would mean you don't have to deal with changing the pesky Visibility property on all of those views. Yuck.
dustyburwell
Thanks ascalonx! This is helpful. Do you have any links to code samples? I need to look at the tabcontrol again (did a while ago and but didn't purse it). Are you saying the transition logic goes inside the SelectionChanged handler? Also could you please clarify why putting "TabItems into the TabControl with controls inside of them" doesnt work? Currently user transition between the views through a combination of menuitem clicks or button clicks within the view itself.
Klerk
Yuck is right! Sick of flipping those values all over the place.
Klerk
+1 a TabControl was my first thought too.
Bryan Anderson
I just mean that adding TabItems into a TabControl directly via xaml will not give you the UI virtualization. Only using an analog to ViewModels with DataTemplates will give you that behavior.Regarding code samples for the TabControl, a Google search for WPF TabControl will yield results just as good as anything I could give you. This is pretty good:http://www.switchonthecode.com/tutorials/the-wpf-tab-control-inside-and-out
dustyburwell
Yes, you could use the SelectionChanged event handler to handle your transitions; stopping background threads and whatnot. The TabControl can handle any of the transitions between views that you were handling with menuitem clicks. The ones where the user clicks a button in a view and it switches the view will be harder because you'll need to continue doing what you're currently doing or handle those button clicks and change the selected tab in code.
dustyburwell
A: 

This sounds like a problem well suited to Composite WPF (Prism). You can define your main area as a region, and use a SingleActiveRegion to show one view at a time. If you create your own region adapter, you can do all the maintenance when the active view changes.

Also, adding a new view won't involve changing the hosting view's code. This will allow you to deploy additional views in the future in separate assemblies...

Abe Heidebrecht