CODEWITHSUNDEEP
c#wpfuser-interface
Sharun
Sharun

Reputation: 2018

WPF: UI Composition

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!

Upvotes: 1

Views: 1708

Answers (2)

Abe Heidebrecht
Abe Heidebrecht

Reputation: 30498

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...

Upvotes: 1

dustyburwell
dustyburwell

Reputation: 5813

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.

Upvotes: 2

Related Questions